From nobody Sun Oct 1 05:47:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9813493C for ; Sun, 1 Oct 2017 05:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 acwRUiE26Ri3 for ; Sun, 1 Oct 2017 05:47:48 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 1E81A13493A for ; Sun, 1 Oct 2017 05:47:47 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1506862067; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=I aEO5ynqH/iauyM4rdaAM4CVCaNAch4tR2FmnYkRgi o=; b=WTc5Zrrp5EjeBFSrgfY85Ty2y2gq6Qk4U2aFr1fie1BN W16e125d0Q8WEh3sEO6/396vyPWbCs4zvp6kX9i5eWejKLuK+6 ls6FATH03HglyzltOw6lN/xL67ySiXu7QyMXQdI3dWEXmiVeVv 22zYsGv1bTZUCFtrW44y6fVbsrs= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 179c_ee61_15e1b9b2_9986_4e71_9545_e16412028fb3; Sun, 01 Oct 2017 07:47:46 -0500 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 1 Oct 2017 08:47:45 -0400 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 1 Oct 2017 08:47:44 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Sun, 1 Oct 2017 08:47:44 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 1 Oct 2017 08:47:43 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sun, 1 Oct 2017 12:47:42 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.016; Sun, 1 Oct 2017 12:47:41 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Coding and Interoperability Challenges Thread-Index: AQJWDLbdGWgIliMeta88DlSb7Xyh6wERxjbqobjAfoCAAAa5EIAC3pRAgAOJAgCAABbGQA== Date: Sun, 1 Oct 2017 12:47:41 +0000 Message-ID: References: <062f01d336b7$966e9160$c34bb420$@jpshallow.com> <034b01d339eb$37251030$a56f3090$@jpshallow.com> In-Reply-To: <034b01d339eb$37251030$a56f3090$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.172.220.42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:AfyabHX4XHhWMZYRbn4ceIfyMkNPRgD09fuMAUQE4k5wCTVanhnm9XEeEGfsLTQsa8y0t8kxsGULKfwv0PKa04rAnPaMZKx2TCACipdot5Vwfp6vNiHiaQuhhYsyz1hObnfNBDo0OvUIOr665H6ApJ2LxE+eHnLES8FMaaR153B5sAYPi4Ez6mZGpT2y/ex56k8bfjLGSUykAiMu9Xrnm/otcLk8dyUDT++zW0owpkbqy0aTTzLTD6wkC+4rox5F8oSs422SHMgMGonnpFwjXYb3l3DPToEfl/8xZt8eIMEKdo7hwxdmUaIOA+reLpu+V598nNBjvmyk9dN6gqD+Lg==; 5:9Gom/GxgnYwXNbD1ajKieBCXur/4oeBtNVipgarQ5TzxN54CeRtsjZMDzZLfvAg6bj4V/OcTppdmcu4vlaHNWT5sc9/S2rPhLouTO2LWfaiDLDnH5E7hjraJTcDDyR2er5DFnyoKY4/cnXDLcYYveA==; 24:yGW0zi2JAlWmEHmKOp9MBsnW4qc3kVNMVTamDSrfkPXj0OSI3d1DX47Ly/Fmsgll2OTh8eSqE6R5n++ZFSqyBqdTrL0RSFuenb0VpbKrdAA=; 7:uY7FDMbr7moHdZZvuE2v0HkHfpbyjU3gAzXvqiuZiP/mQNG4iXCnhb+FQrMXX6VN7GV+hQPOvX9xsu4ovk6j6DccjtrT/1esQDm1xvG1Gn3YVlcvAY5UBGE5WgUcLgc5ikOuESBLIopnU4V2EoDKx7N6Ca/pJLo8UHX/05K3u5kGTj4k8yTwVmmv2Iv1dQnmxXt9O7+ZicS8PwiJITlfFqfoRz+gol5dEVHMsIOc6lo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 15db8441-fe1c-4b0b-9b36-08d508ca9b03 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(32952001)(13464003)(377454003)(189002)(199003)(51694002)(81156014)(6116002)(50986999)(2906002)(3846002)(105586002)(81166006)(106356001)(8676002)(7736002)(8936002)(9686003)(101416001)(6246003)(66066001)(53936002)(102836003)(72206003)(80792005)(55016002)(478600001)(6306002)(25786009)(99286003)(229853002)(966005)(33656002)(2501003)(3280700002)(3660700001)(97736004)(6436002)(68736007)(189998001)(54356999)(6506006)(76176999)(14454004)(2900100001)(7696004)(86362001)(110136005)(316002)(53546010)(2950100002)(305945005)(74316002)(5660300001)(77096006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2017 12:47:41.8195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6127> : inlines <6104> : uri <2509532> Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 12:47:50 -0000 > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Saturday, September 30, 2017 6:24 PM > To: Konda, Tirumaleswar Reddy > ; dots@ietf.org > Subject: RE: [Dots] Coding and Interoperability Challenges >=20 > Hi Tiru, >=20 > I will look at the updated draft later. However, in response to some of = your > comments >=20 > >> If the DOTS client receives 3 responses of 4.22 in a row on the same > session, > >> the DOTS client MUST stop trying to configure the session to prevent > >> a continuous retry loop." >=20 > > I don't see why the client would pick unacceptable values after > > getting > the min/max parameters from the DOTS server. >=20 > I just wanted to prevent a continuous retry in case there is some buggy > software out there / faulty hardware based on certain bit patterns etc. > This is the only place in the spec where the client retries sending again= when > a failure message is returned from the server. The server has to defend itself from attackers and compromised DOTS clients= , it can return 4.29 (Too many requests). >=20 > >> "heartbeat-refresh": {"MinValue": 2, "MaxValue" : 60}, > >> heartbeat-refresh: Heartbeat refresh rate in seconds. This is an > optional > >> attribute. >=20 > > Added heartbeat-interval (e.g. {"CurrentValue": 90, "MinValue": 60, > "MaxValue" : 240}). >=20 > A lot of firewalls I have worked with in the past have a default of 30 se= c for > UDP session timeouts. Therefore the minimum value should be less than > 30 - say 10 or 15 secs to prevent firewall session expiry. The Min/Max values are examples, the draft only recommends default values. = Further, 10 to 15 seconds is too small in a network congested due to volume= tric DDoS attacks. If default transmission parameters defined in RFC7252 ar= e used then the maximum transmission span for a single "CoAP ping" confirma= ble message itself is 91 seconds (see MAX-TRANSMIT-SPAN in https://tools.ie= tf.org/html/rfc7252#section-4.8.2). The firewall I had worked on had a defa= ult timeout of 120 seconds for UDP protocol (with minimum duration of 60 se= conds), even https://tools.ietf.org/html/rfc4787 mandates that NAT UDP mapp= ing timer must not expire in less than two minutes. -Tiru >=20 > Regards >=20 > Jon >=20 From nobody Sun Oct 1 08:52:43 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769AC132F65 for ; Sun, 1 Oct 2017 08:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhPXLi-37MOI for ; Sun, 1 Oct 2017 08:52:40 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 D672E132026 for ; Sun, 1 Oct 2017 08:52:39 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dygXl-0001qa-7p; Sun, 01 Oct 2017 16:52:37 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <062f01d336b7$966e9160$c34bb420$@jpshallow.com> <034b01d339eb$37251030$a56f3090$@jpshallow.com> In-Reply-To: Date: Sun, 1 Oct 2017 16:52:37 +0100 Message-ID: <041401d33acd$4df6e850$e9e4b8f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGXUeWhTAMFfttcvwbk/5Yp4wSxYgDqKWj6AunTJYABwsRMNaMaOUbA Content-Language: en-gb Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 15:52:41 -0000 Hi Tiru, Thanks for the responses >> >> I just wanted to prevent a continuous retry in case there is some >> buggy software out there / faulty hardware based on certain bit patterns etc. >> This is the only place in the spec where the client retries sending >> again when a failure message is returned from the server. > The server has to defend itself from attackers and compromised DOTS clients, it can return 4.29 (Too many requests). Good point - I will make sure that that kind of defensive logic is in the appropriate places in the DOTS server. >> >> A lot of firewalls I have worked with in the past have a default of 30 >> sec for UDP session timeouts. Therefore the minimum value should be >> less than >> 30 - say 10 or 15 secs to prevent firewall session expiry. > The Min/Max values are examples, the draft only recommends default values. Further, 10 to 15 > seconds is too small in a network congested due to volumetric DDoS attacks. If default > transmission parameters defined in RFC7252 are used then the maximum transmission span for a > single "CoAP ping" confirmable message itself is 91 seconds (see MAX-TRANSMIT-SPAN in > https://tools.ietf.org/html/rfc7252#section-4.8.2). The firewall I had worked on had a default > timeout of 120 seconds for UDP protocol (with minimum duration of 60 seconds), even > https://tools.ietf.org/html/rfc4787 mandates that NAT UDP mapping timer must not expire in > less than two minutes. I guess I am showing my age - I did not know about RFC4787 which came out some 17 years after I started work with firewalls! Regards Jon From nobody Sun Oct 1 21:53:46 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5804213430A for ; Sun, 1 Oct 2017 21:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gN3URf7aBE1 for ; Sun, 1 Oct 2017 21:53:42 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 7754313306F for ; Sun, 1 Oct 2017 21:53:42 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 5DE0325F68D; Mon, 2 Oct 2017 13:53:40 +0900 (JST) Received: from SR2-nishizuka.lv4.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 0BC4D75909F; Mon, 2 Oct 2017 13:53:39 +0900 (JST) To: "Konda, Tirumaleswar Reddy" , "Xialiang (Frank)" , "Dots@ietf.org" References: <2acd7300-6684-1491-4f98-7029d0b7c1b0@nttv6.jp> From: kaname nishizuka Message-ID: Date: Mon, 2 Oct 2017 13:53:44 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------337B8FC5FF85C7D91FC8BDAA" Content-Language: en-US Archived-At: Subject: Re: [Dots] =?utf-8?b?YW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RT?= =?utf-8?q?_protocol_support_IP_whitelist_for_DOTS_client=27s_AA=3F?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 04:53:45 -0000 This is a multi-part message in MIME format. --------------337B8FC5FF85C7D91FC8BDAA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit OK! The reason why I need the clarification is that the line in Section 9 "Also, DOTS gateway and DOTS server MUST perform mutual authentication using certificates." is confusing. I feel it is needed to be clarified in the signal channel draft or the new draft that in which case the certificates are mandatory. I think that is the case DOTS agents are in the different domain. thanks, kaname On 2017/09/29 13:22, Konda, Tirumaleswar Reddy wrote: > > The signal channel draft does not mandate certificates for mutual authentication (Using an AAA server is only an example deployment). DOTS agents in the same domain can use other mechanisms like TLS-PSK and SPKI. Andrew and I am planning put up a draft on DOTS provisioning. > > -Tiru > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *kaname nishizuka > *Sent:* Friday, September 29, 2017 6:02 AM > *To:* Konda, Tirumaleswar Reddy ; Xialiang (Frank) ; Dots@ietf.org > *Subject:* Re: [Dots] another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA? > > Hi Tiru, > > in section 9 of signal-channel draft, AAA server exists. > Let me clarify the text. > > Mutual authentication between a DOTS client and a DOTS gateway MUST use (client) certificates? > Between them (in the same domain), a mutual authentication without certificates (i.e. choices other than EAP-TLS) would be a good option, if it meets the mutual authentication and encryption requirement. > > TLS-PSK mode and Subject Public Key Info (SPKI)  looks good to me. > > I hope those options would be discussed in WGmeeting. > > > On 2017/08/07 19:19, Konda, Tirumaleswar Reddy wrote: > > You may want to look into https://tools.ietf.org/html/rfc6959#section-7 > > > >    Even if every Internet-connected network implements source address > > validation at the ultimate network ingress, and assurances exist that > > intermediate devices are to never modify datagram source addresses, > > source addresses cannot be used as an authentication mechanism. > > -Tiru > > *From:*Xialiang (Frank) [mailto:frank.xialiang@huawei.com] > *Sent:* Monday, August 7, 2017 3:28 PM > *To:* Konda, Tirumaleswar Reddy ; Dots@ietf.org > *Subject:* 答复: another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA? > > Hi Tiru, > > Thanks for your analysis. It makes sense to me~~ > > To be accurate, IP whitelist does not relax the mutual authentication requirement, but indeed lose the encryption benefits. > > B.R. > > Frank > > *发件人**:*Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > *发送时间:* 2017年8月7日 17:51 > *收件人:* Xialiang (Frank); Dots@ietf.org > *主题:* RE: another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA? > > TLS supports pre-shared key based authentication. The other mechanisms are Subject Public Key Info (SPKI) Fingerprint pin set for mutual authentication (self-signed certificates or raw public keys) without having to deal with CA. > > I don’t think DOTS should relax the mutual authentication and encryption requirements. > > -TIru > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Xialiang (Frank) > *Sent:* Monday, August 7, 2017 6:25 AM > *To:* Dots@ietf.org > *Subject:* [Dots] another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA? > > In addition to IP whitelist and certificate, pre-share key can also be an option. > > Right? > > *发件人**:*Dots [mailto:dots-bounces@ietf.org] *代表 *Xialiang (Frank) > *发送时间:* 2017年8月7日 8:52 > *收件人:* Dots@ietf.org > *主题:* [Dots] Can DOTS protocol support IP whitelist for DOTS client's AA? > > Hi, > > I think the direct use of IP whitelist on the DOTS server to authenticate and authorize the DOTS client is a simple and effect method, at least in some special use cases, like: DOTS client does not support certificate, an ISP which detects the spoofed source address, etc. > > So, should we support this as an optional way for the DOTS client’s AA and add it into the DOTS protocol drafts? > > B.R. > > Frank > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > --------------337B8FC5FF85C7D91FC8BDAA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit OK!

The reason why I need the clarification is that the line in Section 9 "Also, DOTS gateway and DOTS server MUST perform mutual authentication using certificates." is confusing.
I feel it is needed to be clarified in the signal channel draft or the new draft that in which case the certificates are mandatory.
I think that is the case DOTS agents are in the different domain.

thanks,
kaname


On 2017/09/29 13:22, Konda, Tirumaleswar Reddy wrote:

The signal channel draft does not mandate certificates for mutual authentication (Using an AAA server is only an example deployment). DOTS agents in the same domain can use other mechanisms like TLS-PSK and SPKI. Andrew and I am planning put up a draft on DOTS provisioning.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of kaname nishizuka
Sent: Friday, September 29, 2017 6:02 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Xialiang (Frank) <frank.xialiang@huawei.com>; Dots@ietf.org
Subject: Re: [Dots] another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA?

 

Hi Tiru,

in section 9 of signal-channel draft, AAA server exists.
Let me clarify the text.

Mutual authentication between a DOTS client and a DOTS gateway MUST use (client) certificates?
Between them (in the same domain), a mutual authentication without certificates (i.e. choices other than EAP-TLS) would be a good option, if it meets the mutual authentication and encryption requirement.

TLS-PSK mode and Subject Public Key Info (SPKI)  looks good to me.

I hope those options would be discussed in WGmeeting.


On 2017/08/07 19:19, Konda, Tirumaleswar Reddy wrote:

You may want to look into https://tools.ietf.org/html/rfc6959#section-7

<snip>

   Even if every Internet-connected network implements source address

   validation at the ultimate network ingress, and assurances exist that

   intermediate devices are to never modify datagram source addresses,

   source addresses cannot be used as an authentication mechanism.

 

-Tiru

 

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Monday, August 7, 2017 3:28 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Dots@ietf.org
Subject: 答复: another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA?

 

Hi Tiru,

Thanks for your analysis. It makes sense to me~~

 

To be accurate, IP whitelist does not relax the mutual authentication requirement, but indeed lose the encryption benefits.

 

B.R.

Frank

 

发件人: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
发送时间: 2017年8月7日 17:51
收件人: Xialiang (Frank); Dots@ietf.org
主题: RE: another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA?

 

TLS supports pre-shared key based authentication. The other mechanisms are Subject Public Key Info (SPKI) Fingerprint pin set for mutual authentication (self-signed certificates or raw public keys) without having to deal with CA.  

 

I don’t think DOTS should relax the mutual authentication and encryption requirements.

 

-TIru

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Xialiang (Frank)
Sent: Monday, August 7, 2017 6:25 AM
To: Dots@ietf.org
Subject: [Dots] another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA?

 

In addition to IP whitelist and certificate, pre-share key can also be an option.

Right?

 

发件人: Dots [mailto:dots-bounces@ietf.org] 代表 Xialiang (Frank)
发送时间: 2017年8月7日 8:52
收件人: Dots@ietf.org
主题: [Dots] Can DOTS protocol support IP whitelist for DOTS client's AA?

 

Hi,

I think the direct use of IP whitelist on the DOTS server to authenticate and authorize the DOTS client is a simple and effect method, at least in some special use cases, like: DOTS client does not support certificate, an ISP which detects the spoofed source address, etc.

 

So, should we support this as an optional way for the DOTS client’s AA and add it into the DOTS protocol drafts?

 

B.R.

Frank




_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

 


--------------337B8FC5FF85C7D91FC8BDAA-- From nobody Mon Oct 2 03:38:58 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ED913458B for ; Mon, 2 Oct 2017 03:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 f2JOFYh3t87a for ; Mon, 2 Oct 2017 03:38:55 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 93BA3126BF0 for ; Mon, 2 Oct 2017 03:38:53 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id q190so2599645vkd.13 for ; Mon, 02 Oct 2017 03:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=M7KuJdKfL63Bibgz3aSk/TkzWrmxepKA6YNn1e6Sxas=; b=LvHXELQHkFDhCUc0Xur7WSMv95i2AooJ1f6w3YWWRG2FoCWnvEZYO5D0G5q3SwuY7H 4W9xrxIFC9qElZHg/73m/cqTK44bIWb4xt63omgwivU9tCOTelJ55OGiMNfdL2jSjCG0 bh/z53aRAm0UFZdMKpIOFK2u54mRuBQRqOC4imf26Y0Hsh09dIEaErZq9fhSL1mgoGbk f4zDJClUCr4wMfyHTUoZstZljsJ2A4KDdP11c8cTZp02+AnQUyrcU5QBBSFTkVMM7Jro Wgj2wotJuzzyUOWsz1Gde5GxfmOELoGKyz04ETLLq8VDkgV7YePeAJi9XiE5LE00Q5m3 fIRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=M7KuJdKfL63Bibgz3aSk/TkzWrmxepKA6YNn1e6Sxas=; b=Gm4aI79FEViKQe94QkfUZWganRm8gBekbcZeaciS/nOmgpLpxuT2X490R+3+/aJLRR NN9j4yKLmDvbe0wiNJjV6ZD9f+Yd4fTUOgPsPSmPhj04x2HydzsVOc+vvQex0iOmtzjx Zb86UUGdh3RI8TB1GLnvzoQ28zlyVoXdaFzgCXPppcy0WD0KpLzjiIBMmAyJakunoHND zHA2MiYQM3JhyHs6EWRl5XVE14rNMx1QhNJMmzIhRqU3HPXiu+LiGSGv6qoFyfb4l5PZ iTMLtWrGmUXETsARFQOvhXL0mn9yZ4/t6OYJyWoRiHtDIQiHZlamnJqcccZeBkCjjYni E/CA== X-Gm-Message-State: AMCzsaVKv7mQnlEDDeNVvTnW98k52rVY2xlyuKF+65vdvPdPf9v43HRw hwTtdKwcksOJJ7qcDJLL95+MusOph7oWHYN79WrlbfK9 X-Google-Smtp-Source: AOwi7QDj9Ee6NFTIpyWNKHPaIttUcWJSoNN7huBHZpecbldgjYda9Y30xIgw1iYbldnyvLRReJiTMGzzKv4fHM79ahQ= X-Received: by 10.31.57.134 with SMTP id g128mr7822771vka.82.1506940732129; Mon, 02 Oct 2017 03:38:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.83.194 with HTTP; Mon, 2 Oct 2017 03:38:31 -0700 (PDT) From: Artyom Gavrichenkov Date: Mon, 2 Oct 2017 13:38:31 +0300 Message-ID: To: dots@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Dots] A few suggestions for draft-ietf-dots-use-cases-07 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 10:38:57 -0000 Hi! Here's the subj. I believe, some of the issues I'm raising were discussed already, but I'm not able to find the relevant e-mail threads. Sorry for that. == 3.1.1. - Paragraph 3: "is performed" -> "are performed". - I propose changing the use case title: "End-customer with a single upstream transit provider offering DDoS mitigation services" -> "End-customer with a single upstream transit provider offering DDoS mitigation services on demand" - I propose adding two new paragraphs after paragraph 7, as follows: It is understood that the upstream transit provider may be unable to end the mitigation in case the DOTS client has requested for the DDoS mitigation services to be terminated, but the attack is still ongoing. For example, the upstream transit provider may use Flow Specification Rules within its Border Gateway Protocol sessions [RFC5575] to filter the attack traffic by the means of indicating that some traffic patterns shouldn't be allowed to reach its border routers. Therefore, the upstream transit provider may not be able to end the mitigation at the request, because its own network will be then flooded with malicious traffic, rendering it unusable for the enterprise as well as for nearly all other customers of the provider. In such case, the DOTS server responds to the termination request with a message indicating that the request has been acknowledged, but cannot be currently fulfilled and will be addressed as soon as it is possible. The DOTS client may still request the mitigation status information, statistics and other related information beyond this point. The DOTS client may cancel the termination request by issuing the mitigation request again. Another issue with Flow Specification Rules and other similar mechanisms is that the upstream transit provider may be unable to provide any reasonable information on the status of the attack, as this information is not available to the upstream transit provider itself. In this case, in response to any request for mitigation status information, statistics and other related information the upstream transit provider must clearly indicate that it employs tools which can affect the quality of the provided information. The DOTS client should then treat the statistics returned as a rough estimate at best, and should make his decision to request the mitigation termination based on other information available, for example, on the data received from other upstream transit providers (see 3.1.2) or from the local CSIRT (see 3.1.10). == 3.1.2. I propose a new paragraph (IPaNP), after 2. The motivation: this is what already happens now, ad-hoc, via phone or instant messaging, without DOTS and/or any mutual agreements between ISPs. Therefore, it makes sense to cover this case in the process of designing a DDoS mitigation control protocol: In case there's no such agreement between the upstream transit providers, the DOTS client may still decide to share the information and statistics obtained from one or more of the upstream transit providers to others by unicasting or broadcasting the status messages. An upstream transit provider receiving this kind of data may then plan the allocation of its mitigation facilities with accordance to the current risk level, as seen by other upstream transit providers or the enterprise itself. == 3.1.4. IPaNP, after 5: The MSSP receiving a request to end the mitigation may be unable to act accordingly due to reasons similar to what is discussed in 3.1.1. In such case, the enterprise may react with diversion of Internet traffic destined for its network back from the MSSP network facilities, or may wait for MSSP to effectively stop the mitigation. == 3.1.5. I propose changing the paragraph 2 to the following: The DOTS client built into the Web server has been configured to request DDoS mitigation services from an upstream transit provider or overlay MSSP once specific attack traffic thresholds have been reached, or certain network traffic conditions prevail, or the Web application behind the Web server becomes unable to successfully handle all the incoming HTTP requests on time due to the limited CPU power or RAM amount and there's a pattern in some those HTTP requests which is qualified as typical for a DDoS attack by the Web application. Once the specified conditions have been met, the DOTS communications dialogue and subsequent DDoS mitigation initiation and termination actions described above take place. == 3.1.6. I propose a change to the paragraph 1: "router, layer-3 switch, firewall, or load-balance" -> "router, layer 3 switch, firewall, IDS, IPS, Web application firewall, or load balancer". == 3.1.8. IPaNP, after 3: Note that only the messages directly related to the DDoS attack and mitigation status should be passed between the DDoS MSSPs via DOTS, both in the request for an assistance and during the course of the attack. The exchange of the rest of the information that may be of use in this scenario, which includes interconnection metadata, logging, authorization rules, geo-blocking restriction policies, and similar data, falls out of scope for this document and must be implemented by the means of other protocols and interfaces, such as Content Delivery Network Interconnection (CDNI) Logging interface [RFC7937] or CDNI Metadata interface [RFC8006]. == I propose adding two more use cases, as follows: 3.1.9. End-customer with an upstream transit provider or MSSP offering DDoS mitigation services on the permanent basis This scenario shares almost all characteristics with 3.1.1, except that due to the lack of a capable local IDMS solution, strict uptime requirements, or other reasons the enterprise has previously requested its hosting provider, upstream transit provider or MSSP in its place to provide the DDoS mitigation services permanently, without a need to detect and explicitly turn the mitigation on in case a DDoS attack has started. In this case, when an attack is in place, the DOTS server on the upstream transit provider network immediately notifies the DOTS client on the enterprise network about the attack and periodically signals the DOTS client in order to provide mitigation status information and related information. The enterprise security and network operations departments may then use this information to take care of the network status, to plan maintenance windows and routing policies, and to share it with CSIRT if applicable (see 3.1.10). 3.1.10. Community member notifying CSIRT about the attack A Computer Security Incident Response Team (CSIRT) [RFC2350] is responsible for assisting members of a community within its constituency in implementing proactive measures to reduce the risks of computer security incidents, and to assist the community in responding to such incidents when they occur. The community may consist of sites, networks or organizations, such as enterprises operating in one industry, regional transit providers or DDoS mitigation MSSPs. Typically, a Computer Security Incident Response Team would need an information about ongoing DDoS attack on a member of the community as soon as possible to act accordingly, issuing notifications, recommendations and policies for the rest of its community. A member of the community implements a DOTS client while the corresponding CSIRT implements a DOTS server. The DOTS client signals the DOTS server on the CSIRT network that an attack had started. During the course of the attack, the DOTS client frequently updates the information about the status of mitigation, provided by the DDoS mitigation solution deployed by the member as well as its upstream transit providers or MSSPs. In turn, the DOTS server on the CSIRT side periodically signals the DOTS client in order to provide information about similar attacks currently ongoing on other community members, so that the DOTS client could make an informed decision to whether maintain or terminate the mitigation via other means. == Also, please consider updating the Github repo for the Use Cases draft. It's now on the version 05 while the most recent one is 07. | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 From nobody Mon Oct 2 03:43:22 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE14813458E for ; Mon, 2 Oct 2017 03:43:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO3SMp0COan3 for ; Mon, 2 Oct 2017 03:43:18 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 AD947134592 for ; Mon, 2 Oct 2017 03:43:18 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id h191so2625308vke.6 for ; Mon, 02 Oct 2017 03:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=w/n3EnPb3eGOJy6V22rEWd9EF68iJpLG2nE6vAWcFfg=; b=HkPH1Fh3Vb+3yS10ZKtpNQIoX10NV13EY31Nw+Dx1pv0+SRstVPPuE4HyxaTERHyOE u1mwRdfthN6NdGYmxdvMGqYQK4gO4Jz2wgRFmLaoXt3Eqgl0JLGRsK4GQjyA298gdETM /f9p4/0/ZLJjcCt/vKTvdzRQEQP+3sPNdhNgGL/WANoE5NBhGmVAlf8okRvDvMYkazVs dJKYqRDYDYz27BES5Nu7m5lDMg5Ko71V/T3A31X/dsHOkqDv7NJcRW14Y6vMeQQ/4iR7 HhVbG68QmfVHapvcf7ACU+9iiEfl21PlDkr6kehY4DceOYgFmuU/By7qMVjTSYsqNBj+ 7X6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=w/n3EnPb3eGOJy6V22rEWd9EF68iJpLG2nE6vAWcFfg=; b=jgB7AGwLtDkB+JdTGqHg7tZYufBAa//Jc4g4oiwDq0Tq3XjZaoqO5I0ezx6OStGIkv 77G2plqZ0KE768LhV8HPT6JXnqdXMs1SEFR9VeMfIJmoLlTvAFLPAKMBJ2BTw+Vo7uRs rjAPe8kypaYQnj7GxXZUWEgLn3hHbhYlXextJY1OordMT1DzxYTWtSy4pri/qBgjYgNI Ig7C8ON2Uha/miS33/IW0CHuyVzbkSOheO+WnUPsrVHZK3JN9dZ6px7oYR43AdkmK8wT VR9oPmfVnVy3IBVq8yq6dTOkgcSoK0x+zNSYZKWmbqZ9D6he7VC+HXIbMPIa4+lptFY+ 3W6A== X-Gm-Message-State: AHPjjUjm9waCB+47AqO9f/0I6aHbxRbAmQQFgdfwYM7zV1tFWfP2KnQ1 BYWfLXUMCg2gh2ZOL9HyhbFRcEeGCn1fPPkJUVgThE5t X-Google-Smtp-Source: AOwi7QB4pACr48W2EveDp9N320jYQKt/WmY+/eNP5x0hCzgQ4HWUVdZmSjlnmuYSnHCP26OGc+DRn7WeHFpkMVB6c/M= X-Received: by 10.31.183.136 with SMTP id h130mr8118939vkf.36.1506940997472; Mon, 02 Oct 2017 03:43:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.83.194 with HTTP; Mon, 2 Oct 2017 03:42:57 -0700 (PDT) From: Artyom Gavrichenkov Date: Mon, 2 Oct 2017 13:42:57 +0300 Message-ID: To: dots@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Dots] A few suggestions for draft-ietf-dots-requirements-06 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 10:43:21 -0000 Hi! Here are my two cents for the current draft. == 2.2, SIG-005. There's a concern my concern about limiting the size of the active-but-terminating period. To quote my suggestions for the use case document: > It is understood that the upstream transit provider may be unable to > end the mitigation in case the DOTS client has requested for the DDoS > mitigation services to be terminated, but the attack is still ongoing. > For example, the upstream transit provider may use Flow Specification > Rules within its Border Gateway Protocol sessions [RFC5575] to filter > the attack traffic by the means of indicating that some traffic > patterns shouldn't be allowed to reach its border routers. Therefore, > the upstream transit provider may not be able to end the mitigation at > the request, because its own network will be then flooded with > malicious traffic, rendering it unusable for the enterprise as well as > for nearly all other customers of the provider. In such case, the > DOTS server responds to the termination request with a message > indicating that the request has been acknowledged, but cannot be > currently fulfilled and will be addressed as soon as it is possible. > The DOTS client may still request the mitigation status information, > statistics and other related information beyond this point. The DOTS > client may cancel the termination request by issuing the mitigation > request again. > > Another issue with Flow Specification Rules and other similar > mechanisms is that the upstream transit provider may be unable to > provide any reasonable information on the status of the attack, as > this information is not available to the upstream transit provider > itself. In this case, in response to any request for mitigation > status information, statistics and other related information the > upstream transit provider should clearly indicate that it employs > tools which can affect the quality of the provided information. The > DOTS client should then treat the statistics returned as a rough > estimate at best, and should make his decision to request the > mitigation termination based on other information available, for > example, on the data received from other upstream transit providers > (see 3.1.2) or from the local CSIRT (see 3.1.10). What's important here are the consequences for a DOTS client which decides to withdraw the mitigation request while an attack is still ongoing. If the active-but-terminating period is initially 30 seconds tops, then after 30 seconds the mitigator will either continue filtering, yet making the DOTS client unable to track the mitigation status, or it may just use a black hole community to drop the traffic towards the victim completely, so the result is complete downtime for the victim. But if the active-but-terminating period is unlimited, then the client will still have full control on the situation. And, if it's really eager to stop the mitigation no matter what, it may just kill the BGP session towards the mitigator. At least, it seems to be important to split those cases: 1) a DOTS client requests the DOTS server to end the mitigation, where the server may acknowledge the request but refuse to comply for an unlimited period of time; 2) a DOTS client requests the DOTS server to end the mitigation completely (due to excessive costs, for instance), where the server MUST comply but may start to drop the traffic completely. I'll be happy to provide detailed requirements for both scenarios if you want me to. A side note: I can't find this in the mailing list, but why the initial window is 30 seconds? What can a mitigation provider actually do within this period? It's not enough even for BGP announcement to propagate globally. I've seen a BGP announcement propagation taking up to 2 minutes, for example. A brief RIPE Labs study ( https://labs.ripe.net/Members/vastur/the-shape-of-a-bgp-update ) showed that full visibility of an announcement took about 38 seconds, while a subsequent withdrawal took more than 2 minutes to propagate. Moreover, the architecture document even features the concept of gateway and chaining. A request to end the mitigation may propagate through the gateway, acting as a sort of proxy, towards the upper level mitigation provider, which may take time on a saturated network link. Then, this upper level provider is left with, like, 20 seconds to comply. So I'd consider changing the MUST in the last paragraph of SIG-005 to SHOULD. == 2.2, SIG-007. Under certain conditions, a DOTS client may be an awful decision maker. Imagine a 80 Gbps DDoS attack with combined SYN flood, WP Pingback and HTTPS flood towards a typical 200 Mbps link. The congestion on the last mile will render any network service, including the CPE with DOTS client in it, unable to come up with any sane mitigation scope. Thus, I propose changing the first MUST in SIG-007 to SHOULD. == 2.2, SIG-009. "Conflicting" or complementing? Note that different DOTS clients in an enterprise network infrastructure may have different visibility scopes, either per some subsets of IP addresses (which may of may not form one continuous prefix range) or per OSI level. Using the previous example, one DOTS client on an IDS/IPS will see a SYN flood while another DOTS client on a Web server will see an HTTPS flood towards the same network resource. The IDS (like Snort) will be unable to track down HTTPS requests while the Web server wouldn't see the SYN flood mostly mitigated on the IDS. One may argue that in this case there must be a DOTS gateway at the edge of the network, acting as a proxy and a decision maker, yet again, in practical datacenter conditions it may be hard to set up and maintain one. == 2.3, DATA-004 It is unclear what should happen if a DOTS client adds an entry both to the blacklist and to the whitelist. Either one of the lists should be given priority over the other, or, say, adding an entry to the blacklist should automatically force the deletion of the corresponding entry from the whitelist (which may add computational complexity). Leaving this up to the implementation may cause harm to inter-operability of different clients and servers. I'd consider adding a paragraph like that: A DOTS client MUST assume complete responsibility for maintaining all the entries it adds both to the blacklist and to the whitelist. In case of a collision (i. e. when an entry is added to the blacklist which is already present in the whitelist, or vice versa) the behaviour is undefined. == 1.2. It's not that important really, but I'd consider reviewing the definition of DDoS attack. Currently, DDoS is defined as "a distributed denial-of-service attack, in which traffic originating from multiple sources are directed at a target on a network". This lacks the definition of "source". Is it a source IP address? Then, a SYN flood with a fixed spoofed IP source doesn't qualify to be called DDoS, which is odd. Or, is it a network source, like, a physical machine? Do virtual instances count then? And, again, a SYN flood generated on a single server somewhere on DEC-IX (which is actually what we faced once) is not a DDoS attack? I'd consider changing the definition towards the perceived effect and the goal of an attacker. Something on the lines of: DoS: an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work by rendering the victim unavailable, unresponsible, or unreachable. DDoS: a DoS attack which achieves the goal of rendering the victim unavailable, unresponsible, or unreachable by the means of exhausting the finite resources of a network connected entity, which may or may not be the victim itself. Denial-of-service considerations are discussed in detail in [RFC4732]. Or one can simply take the definition from one of Roland's presentations, like that: http://mirror.die.net/misc/defending-ddos/stateofdanger.pdf , slide 3. | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 From nobody Mon Oct 2 04:59:24 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E02F13209C for ; Mon, 2 Oct 2017 04:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 dfjqQkCJc64v for ; Mon, 2 Oct 2017 04:59:18 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 52C1913219B for ; Mon, 2 Oct 2017 04:59:17 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1506945556; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=d l1vboexYgN9YEcXsKiIwOyxIvjecpUT7NqIw2aJlM A=; b=VLwWFLKvRDfFbbgkbBkoJRqgSapdEtW6O2/Z1blIvRiQ rqk5vp/ENJWLFub1l02K37wRerqTk32rGGOVhV/CvDICsu7Zlo iOmnqaPJOJT/k+viKdm6kixaRbqq/NFlKgmicfjMscMKxrBTX5 rOYPuSHm+L5ki4QO1iiLhfzkP68= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 50b5_453b_ef7477a9_9b87_46b0_be2a_a1f0abf9d0ce; Mon, 02 Oct 2017 06:59:15 -0500 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 05:59:14 -0600 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 05:59:13 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 2 Oct 2017 05:59:13 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 05:59:07 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 2 Oct 2017 11:59:06 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.016; Mon, 2 Oct 2017 11:59:05 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Coding and Interoperability Challenges Thread-Index: AdMouv44Udo0NFExSCOHW+HXkRNTEQERxjbqAVIVJZ8CskQHRqGgxiVwoaSKVGA= Date: Mon, 2 Oct 2017 11:59:05 +0000 Message-ID: References: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> <00a101d32d46$b2f30cf0$18d926d0$@jpshallow.com> <037c01d33a2c$ed764700$c862d500$@jpshallow.com> <040401d33ac9$85542c80$8ffc8580$@jpshallow.com> In-Reply-To: <040401d33ac9$85542c80$8ffc8580$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.220.42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:dCHp9/PiffgoWj7j4JK8OzsH1AUUGQ/6qaayOxheVMOU/5W9gr07rZb6xH6RxavrJUw8P3GYzg309vbt+isGYfnew5C5JjGzRSK2emQp7ARfKETX1K7YPJ0NKAWcokofx2c9EM28PJT23Hg4N6g3Xfeyj/y/NyoTmnxPOHQHIhDWtLWt/jbBGlyVwaWTgYrMg9euaLPS1cNMevPDltzrsMx0nmckO9IKZka4WzNTWleQ4cW6umuOp9Oog5wdR5HBSKFOXPWFzMgFIGp+WAPAmPR1QhBDBZ3WxdD/Grgg9YzdUM9J0NnvawClOZYE6MlMZ8PPrVUc9bijlrcu8uZNdg==; 5:oxv26KpC4fgS6Bwq26IOedJavW3mokGp6JLZcBG8cgXviehw0bxZwnFyncGhwAbHHoC1gfi4cYkERmeI4KZGg5hDLzu2PY4vfbCVoD+q8fZW2iNsfxhOzGmHnllQ+l1JLD/FwaIJgeQ0m6oz2PV42mIfRYxIFSjvpiqmf4zWhZ8=; 24:RQXTdeoBwJ1G44lrwnEJoMMHuatX90BbYOuex8SeqBKs9p7CcGDcueyBZqZeGlTD1xukXfaQwR4fGZNIIgDsFjwp6axCT/NgLS3ZOgNX74o=; 7:/6NTJjXq1uwFzRpsebVB/OyAV8+EJu4xVY31TkD2/1VCnbk7zVC3H2mwqScfQL+45n2F5JlVWxbkrm8b2VuHLW6WIZ6chnn9YgHirygKeApSlx4itQtakvnNBsmn1peDaGidL9QQVH+C08dcu0kUxM0wUSo6Hjfc9wEsBmuLqqDixc2s3JuW7EX+BGqdj79mY0zwT4BZNg7H5f2uOhqYXwV7giW/lZs+AAKmUYOprk8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2b4f25ad-3666-4fcc-63d0-08d5098cfb54 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(21748063052155)(211171220733660); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(199003)(32952001)(189002)(51694002)(377424004)(316002)(93886005)(229853002)(2900100001)(101416001)(53936002)(54356999)(76176999)(6246003)(2501003)(80792005)(50986999)(97736004)(106356001)(105586002)(68736007)(7736002)(33656002)(74316002)(81166006)(8676002)(236005)(66066001)(8936002)(9686003)(54896002)(6306002)(5660300001)(966005)(86362001)(81156014)(2906002)(6506006)(72206003)(6436002)(53546010)(606006)(189998001)(3846002)(55016002)(99286003)(19609705001)(7696004)(790700001)(25786009)(6116002)(3660700001)(102836003)(3280700002)(110136005)(77096006)(14454004)(2950100002)(53946003)(478600001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C05C0C2B03968C68AA5CEA7D0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 11:59:05.8226 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6127> : inlines <6104> : streams <1765535> : uri <2510017> Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 11:59:22 -0000 --_000_DM5PR16MB1788C05C0C2B03968C68AA5CEA7D0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Jon for the comments, Please see inline [TR] for response. I have posted updated DOTS signal and data channel drafts to https://github= .com/tireddy2/DOTS From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: 30 September 2017 21:45 To: 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: RE: [Dots] Coding and Interoperability Challenges Hi Tiru, Thanks for your updates and feedback - much appreciated. As per https://github.com/tireddy2/DOTS/ (pre draft-ietf-dots-signal-channe= l-04) dated 30 Sep, along with responses to my emails of Sep 8, Sep 14 and = Sep 26, I have the following additional feedback / comments and suggestions= . [I see that alias is now alias-name - a clearer definition, but also needs = to be the same in the data channel spec] https://github.com/tireddy2/DOTS/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D 5.1 Overview "DOTS agents MUST support GET, PUT, POST, and DELETE CoAP methods." No examples are given for POST usage, so should POST be a MUST? [TR] No, removed POST from the above line. Thanks. 5.3.1. Requesting mitigation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D We need to clarify what is overlapping - is it just a common IP address / f= qdn / uri and not common protocol "Orig: ... DOTS client is determined by comparing their respective mitigati= on-id values. If two mitigation requests have overlapping mitigation scope= s the mitigation request with higher numeric mitigation-id value will overr= ide the mitigation request with a lower numeric mitigation-id value. The o= verlapped lower numeric mitigation-id is automatically deleted and no longe= r available at the DOTS server. New: Overlapping is true if there is a common IP, IP Prefix, FQDN, URI or = alias-name between the two mitigation-ids. Orig: The Uri-Path option carries ....." [TR] Looks good, updated draft. 5.3.3. Retrieving a DOTS Signal (1) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Bps-dropped and pps-dropped as now defined can easily be computed from the = mitigation start time and the total number dropped. Over the life of a mit= igation it would be good to report higher numbers at peak mitigation times.= The last 1 second average, or the average since the last GET request, or = last 5 minute average could be alternative methods of definition, but appre= ciate that methods of measurement and reporting make it difficult to be pre= cise what easily can be reported here. Suggested replacements (included a grammar change from 'a optional' to 'an = optional') [TR] Fixed. Replacement: "bps-dropped: The average dropped bytes per second for the m= itigation request since the last status request. This is an optional attribute." Replacement: "pps-dropped: The average dropped packets per second for the mitigation request since the last status request. This is an optional attribute." [TR] GET request/response used to retrieve the status of the mitigation req= uest are marked as non-confirmable messages, the DOTS server does not know = if the DOTS client had successfully received response to the last status re= quest. 5.3.3. Retrieving a DOTS Signal (2) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Does it make sense to add in a "mitigation-start" : time as well as the byt= es dropped etc. in the status response? [TR] Yes, mitigation start time will be useful to the DOTS client; updated = draft. 5.3.3.1. Mitigation Status =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The 03 -> 04 replacement text can be better worded as below (with spelling = correction):- Orig: "A DOTS client retrieves the information about a DOTS signal at frequent intervals to determine the status of an attack. The DOTS client can send the GET request at frequent intervals without the Observe option to" Replacement: "retrieve the configuration and status data of the mitigation Request. The frequency of polling the DOTS server to get the mitigation sta= tus should follow the usage guidelines given in https://tools.ietf.org/html= /rfc8085#section-3.1.3." Orig: " If the DOTS server has been able to mitigate the attack and the attack has stopped, the DOTS server indicates as such in the status, and the DOTS client recalls the mitigation request" Addition: "by issuing a DELETE for the mitigation-id." [TR] Thanks, updated the first paragraph in Section 5.3.3.1 as follows: The DOTS client can send the GET request at frequent intervals without the Observe option to retrieve the configuration data of the mitigation request and non-configuration data (i.e., the attack status). The frequency of polling the DOTS server to get the mitigation status should follow the transmission guidelines given in Section 3.1.3 of [RFC8085]. If the DOTS server has been able to mitigate the attack and the attack has stopped, the DOTS server indicates as such in the status, and the DOTS client recalls the mitigation request by issuing a DELETE for the mitigation-id. 5.4.2. Convey DOTS Signal Channel Session Configuration =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D "missing-heartbeat-interval" should be "missing-hb-allowed" in Figure 16. [TR] Fixed. 5.3.1. Requesting mitigation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >From a previous email dialogue >> However, nowhere else does it state what should be in the body of the r= esponse (if anything) for a PUT or DELETE. There are hints in the COAP RFC= that suitable diagnostics can be added for failure response codes. >> Do we just echo back the request (with update lifetime possibly) for PUT= ? > [TR] No, only the updated lifetime is returned in the response. OK, the CBOR response (JSON format) is which of the 2 versions below? { "mitigation-scope": { "scope": [ { "mitigation-id": integer, "lifetime": integer } ] } } Or { "lifetime": integer } We need this clarified in the spec. [TR] The first version with mitigation-id and lifetime, updated draft. 5.3.2. Withdraw a DOTS Signal =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >From a previous email dialogue >> What body responses do we send back for a DELETE? > [TR] No body in DELETE for 2.xx responses. Spec needs to state this Orig: "The DOTS server immediately acknowledges a DOTS client's request to withdraw the DOTS signal using 2.02 (Deleted) response code." New: "There is no response payload." Orig: "A 2.02 (Deleted) Response Code is returned even if the mitigation-id= ..." [TR] Agreed, updated draft. Other (1) =3D=3D=3D=3D=3D >From a previous email dialogue >> Nttdots is expecting an additional path parameter in the POST/PUT etc pa= th (.wellknown), so instead of /v1/dots-signal/signal, it requires /.wellkn= own/v1/dots-signal/signal which is not stated anywhere in the draft-ietf-do= ts-signal-channel draft. If not present, it returns a 4.05 code. > [TR] The draft can be updated to use well-known URI with dots-signal as U= RI suffix, we can discuss in the interim WG meeting. I believe that doing a Discover (GET /.well-known/core) to determine the ac= tual configuration paths should be used (RFC6690). [TR] Discovery introduces additional overhead of request/response during an= DDoS attacks, well-known URI are used by many protocols (see EST https://t= ools.ietf.org/html/rfc7030 for example). Other (2) =3D=3D=3D=3D=3D >> If the DOTS client receives 3 responses of 4.22 in a row on the same session, >> the DOTS client MUST stop trying to configure the session to prevent >> a continuous retry loop." > I don't see why the client would pick unacceptable values after > getting the min/max parameters from the DOTS server. I just wanted to prevent a continuous retry in case there is some buggy sof= tware out there / faulty hardware based on certain bit patterns etc. This is the only place in the spec where the client retries sending again w= hen a failure message is returned from the server. Other (3) =3D=3D=3D=3D=3D >> "heartbeat-refresh": {"MinValue": 2, "MaxValue" : 60}, >> heartbeat-refresh: Heartbeat refresh rate in seconds. This is an optional >> attribute. > Added heartbeat-interval (e.g. {"CurrentValue": 90, "MinValue": 60, "MaxValue" : 240}). A lot of firewalls I have worked with in the past have a default of 30 sec = for UDP session timeouts. Therefore the minimum value should be less than 30 - say 10 or 15 secs to prevent firewall session expiry. Other (4) =3D=3D=3D=3D=3D >> New: "For mitigation to continue beyond the initial negotiated "lifetime= ", the >> DOTS client will need to refresh the current mitigation request by sendi= ng a >> new PUT request. The PUT request SHOULD use the same "mitigation-id", >> and SHOULD repeat all the other parameters as sent in the original mitig= ation >> request apart from a possible change to the "lifetime" >> parameter. > Any specific reason for "SHOULD" (I plan to use "MUST" instead of "SHOULD= ") ? MUST is fine by me [TR] Thanks, updated section. Other (5) =3D=3D=3D=3D=3D >> When "observe" is set to 0, should the DOTS server send back an unsolici= ted >> information / status update >> a) whenever there is a "status" parameter change >> b) when there is a change to one of the "*-dropped" parameters >> c) send a response at some regular time interval? >> - Figure 10 implies it is just on a "status" parameter change. > It is a), whenever there is a change to the "attack-status" parameter val= ue (https://tools.ietf.org/html/rfc7641 allows notification from the server only when the state changes). Actually, only "status" is returned in the GET request. "attack-status" is = used for efficacy updates. Perhaps "status" should be defined as "state-st= atus" for clarity. draft-ietf-dots-data-channel-03 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D 3.2.3. Retrieving Installed Identifiers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D The JSON examples do not always follow the YANG model Container(YANG) =3D object(JSON) (RFC7951- 5.2) List(YANG) =3D array(JSON) (RFC7951 - 5.4) "ietf-dots-data-channel-identifier:identifier" is a container, not a list, = and therefore cannot be an array. Figure 7. As "alias" is the array, all t= he aliases should be done at that level. [TR] Yup, fixed. 3.3.1 Install Filtering Rules Draft-ietf-netmod-acl-model-13 rev 2017-06-12 has changed the YANG definiti= on for "ietf-access-control-list:access-lists" "Added feature and identity statements for different types of rule matches.= Split the matching rules based on the feature statement and added a must s= tatement within each container." The feature containers (e.g. ipv4-acl) are missing from all examples for th= e filter rules. "acl-type" is now of form "ipv4-acl", not "ipv4". All references to ietf-access-control-list:access-lists need to be updated,= including the rate-limiting / fragment extensions. [TR] Yes, updated draft to address all above comments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon --_000_DM5PR16MB1788C05C0C2B03968C68AA5CEA7D0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Jo= n for the comments, Please see inline [TR] for response.

I have po= sted updated DOTS signal and data channel drafts to https://github.com/tireddy2/DO= TS

&nbs= p;

&nbs= p;

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: 30 September 2017 21:45
To: 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: RE: [Dots] Coding and Interoperability Challenges

 

Hi Tiru= ,

&n= bsp;

Thanks = for your updates and feedback – much appreciated.

&n= bsp;

As per = h= ttps://github.com/tireddy2/DOTS/ (pre draft= -ietf-dots-signal-channel-04) dated 30 Sep, along with responses to my emails of Sep 8, Sep 14 and Sep 26, I have the = following additional feedback / comments and suggestions.=

 

[I see that alias is now alias-= name – a clearer definition, but also needs to be the same in the dat= a channel spec]

 

https://github.com/tireddy2/DOTS/

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

 

5.1 Overview<= /p>

 

“DOTS agents MUST support GET, PUT, POST, and DELETE CoAP m= ethods.”

 

No examples are given for POST usage, so should POST be a MUST?

 

[TR]= No, removed POST from the above line. Thanks.

 

 

5.3.1.  Requesting mitigation

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 

We need to clarify what is over= lapping – is it just a common IP address / fqdn / uri and not common = protocol

 

“Orig: ... DOTS client is= determined by comparing their respective mitigation-id values.  If tw= o mitigation requests have overlapping mitigation scopes the mitigation req= uest with higher numeric mitigation-id value will override the mitigation request with a lower numeric mitigation-id value. =  The overlapped lower numeric mitigation-id is automatically deleted a= nd no longer available at the DOTS server.

New:  Overlapping is true = if there is a common IP, IP Prefix, FQDN, URI or alias-name between the two= mitigation-ids.

Orig:  The Uri-Path option= carries .....”

 

[TR] Looks good, updated draft.=

 

 

5.3.3.  Retrieving a DOTS Signal (1)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Bps-dropped and pps-dropped as = now defined can easily be computed from the mitigation start time and the t= otal number dropped.  Over the life of a mitigation it would be good t= o report higher numbers at peak mitigation times.  The last 1 second average, or the average since the last GET = request, or last 5 minute average could be alternative methods of definitio= n, but appreciate that methods of measurement and reporting make it difficu= lt to be precise what easily can be reported here.

 

Suggested replacements (include= d a grammar change from ‘a optional’ to ‘an optional̵= 7;)

 

[TR] Fixed. <= /p>

 

Replacement:  “bps-d= ropped:  The average dropped bytes per second for the mitigation<= /o:p>

request since the last status r= equest.  This is an

optional attribute.”=

 

Replacement: “pps-dropped= :  The average dropped packets per second for the

mitigation request since the la= st status request.  This

is an optional attribute.”= ;

 

[TR] GET request/response used = to retrieve the status of the mitigation request are marked as non-confirma= ble messages, the DOTS server does not know if the DOTS client had successf= ully received response to the last status request.

 

5.3.3.  Retrieving a DOTS Signal (2)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Does it make sense to add in a = “mitigation-start” : time as well as the bytes dropped etc. in = the status response?

 

[TR] Yes, mitigation start time= will be useful to the DOTS client; updated draft.

 

 

5.3.3.1.  Mitigation Statu= s

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

The 03 -> 04 replacement tex= t can be better worded as below (with spelling correction):-

 

Orig: “A DOTS client retr= ieves the information about a DOTS signal at

frequent intervals to determine= the status of an attack.  The DOTS

client can send the GET request= at frequent intervals without the

Observe option to” <= /o:p>

Replacement: “retrieve th= e configuration and status data of the mitigation

Request. The frequency of po= lling the DOTS server to get the mitigation status should follow the usage = guidelines given in https://tools.ietf.org/html/rfc8085#section-3.1.3= .”

Orig:  “ If the DOTS= server has been able to mitigate the attack and

the attack has stopped, the DOT= S server indicates as such in the

status, and the DOTS client rec= alls the mitigation request”

Addition:  “by issui= ng a DELETE for the mitigation-id.”

 

[TR] Thanks, updated the first = paragraph in Section 5.3.3.1 as follows:

 

   The DOTS client ca= n send the GET request at frequent intervals

   without the Observ= e option to retrieve the configuration data of the

   mitigation request= and non-configuration data (i.e., the attack

   status).  The= frequency of polling the DOTS server to get the

   mitigation status = should follow the transmission guidelines given in

   Section 3.1.3 of [= RFC8085].  If the DOTS server has been able to

   mitigate the attac= k and the attack has stopped, the DOTS server

   indicates as such = in the status, and the DOTS client recalls the

   mitigation request= by issuing a DELETE for the mitigation-id.

 

&n= bsp;

 

5.4.2.  Convey DOTS Signal Channel Session Configuration

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

"missing-heartbeat-interva= l" should be “missing-hb-allowed” in Figure 16.=

 

[TR] Fixed. <= /p>

&n= bsp;

&n= bsp;

5.3.1.  Requesting mitigation

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

From a = previous email dialogue

&n= bsp;

>>= ; However, nowhere else does it state what should be in the body of the &nb= sp;response (if anything) for a PUT or DELETE.  There are hints in the= COAP RFC that suitable diagnostics can be added for failure response codes.

>>= ; Do we just echo back the request (with update lifetime possibly) for PUT?=

 

> [TR] No, only the updated = lifetime is returned in the response.

 

OK, the CBOR response (JSON for= mat)  is which of the 2 versions below?

 

{

  "mitigation-scope&q= uot;: {

     "= scope": [

     &= nbsp;  {

     &= nbsp;    "mitigation-id": integer,

     &= nbsp;    "lifetime": integer

     &= nbsp;  }

      = ]

   }

}

 

Or

 

{

   "lifetime&quo= t;: integer

}

 

We need this clarified in the s= pec.

 

[TR] The first version with mit= igation-id and lifetime, updated draft.

 

 

5.3.2.  Withdraw a DOTS Signal

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

 

From a = previous email dialogue

 

>>= ; What body responses do we send back for a DELETE?

 

> [TR] No body in DELETE for= 2.xx responses.

 

Spec needs to state this

 

Orig: "The DOTS server imm= ediately acknowledges a DOTS client's request to

withdraw the DOTS signal using = 2.02 (Deleted) response code."

New: "There is no response= payload."

Orig: "A 2.02 (Deleted) Re= sponse Code is returned even if the mitigation-id ..."

 

[TR] Agreed, updated draft.

 

&n= bsp;

Other (= 1)

=3D=3D= =3D=3D=3D

&n= bsp;

From a = previous email dialogue

&n= bsp;

>>= ; Nttdots is expecting an additional path parameter in the POST/PUT etc pat= h (.wellknown), so instead of /v1/dots-signal/signal, it requires /.wellkno= wn/v1/dots-signal/signal which is not stated anywhere in the draft-ietf-dots-signal-channel draft.  If not present= , it returns a 4.05 code.

&n= bsp;

> [T= R] The draft can be updated to use well-known URI with dots-signal as URI s= uffix, we can discuss in the interim WG meeting.

&n= bsp;

I belie= ve that doing a Discover (GET /.well-known/core) to determine the actual co= nfiguration paths should be used (RFC6690). 

 

[TR] Discovery introduces addit= ional overhead of request/response during an DDoS attacks, well-known URI a= re used by many protocols (see EST https://tools.ietf.org/html/rfc7030 for ex= ample).

&n= bsp;

Other (= 2)

=3D=3D= =3D=3D=3D

&n= bsp;

>> If the DOTS client = receives 3 responses of 4.22 in a row on the same

session,

>> the DOTS client MUS= T stop trying to configure the session to prevent

>> a continuous retry = loop."

 

> I don't see why the cli= ent would pick unacceptable values after

> getting

the min/max parameters from = the DOTS server.

 

I just wanted to prevent a c= ontinuous retry in case there is some buggy software out there / faulty har= dware based on certain bit patterns etc.

This is the only place in th= e spec where the client retries sending again when a failure message is ret= urned from the server.

 

Other (= 3)

=3D=3D= =3D=3D=3D

 

 

>> "heartbeat-ref= resh": {"MinValue": 2, "MaxValue" : 60},

>> heartbeat-refresh:&= nbsp;  Heartbeat refresh rate in seconds.  This is an<= /span>

optional

>> attribute.

 

> Added heartbeat-interva= l (e.g. {"CurrentValue": 90, "MinValue": 60,=

"MaxValue" : 240})= .

 

A lot of firewalls I have wo= rked with in the past have a default of 30 sec for UDP session timeouts.&nb= sp; Therefore the minimum value should be less than

30 - say 10 or 15 secs to pr= event firewall session expiry.

 

Other (= 4)

=3D=3D= =3D=3D=3D

 

>> New: "For miti= gation to continue beyond the initial negotiated "lifetime", the<= o:p>

>> DOTS client will ne= ed to refresh the current mitigation request by sending a=

>> new PUT request.&nb= sp; The PUT request SHOULD use the same "mitigation-id",

>> and SHOULD repeat a= ll the other parameters as sent in the original mitigation

>> request apart from = a possible change to the "lifetime"

>> parameter. 

 

> Any specific reason for= "SHOULD" (I plan to use "MUST" instead of "SHOULD= ") ?

 

MUST is fine by me

 

[TR] Thanks, updated section= .

 

Other (= 5)

=3D=3D= =3D=3D=3D

 

>> When "observe&= quot; is set to 0, should the DOTS server send back an unsolicited

>> information / statu= s update

>> a) whenever there i= s a "status" parameter change

>> b) when there is a = change to one of the "*-dropped" parameters

>> c) send a response = at some regular time interval?

>> - Figure 10 implies= it is just on a "status" parameter change.

 

> It is a), whenever ther= e is a change to the "attack-status" parameter value (https://to= ols.ietf.org/html/rfc7641 allows notification from the server

only when the state changes)= .

 

Actually, only “status= ” is returned in the GET request. “attack-status” is used= for efficacy updates.  Perhaps “status” should be defined= as “state-status” for clarity.

 

draft-ietf-dots-data-channel= -03

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

3.2.3.  Retrieving Inst= alled Identifiers

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

The JSON examples do not alw= ays follow the YANG model

Container(YANG) =3D object(J= SON) (RFC7951- 5.2)

List(YANG) =3D array(JSON) (= RFC7951 - 5.4)

"iet= f-dots-data-channel-identifier:identifier" is a container, not a list,= and therefore cannot be an array. Figure 7.  As “alias” is the a= rray, all the aliases should be done at that level.

 

[TR] Yup, fixed.

 

3.3.1 Install Filtering Rules

<= span lang=3D"EN-GB" style=3D"color:black;mso-fareast-language:EN-GB">&= nbsp;

Draft-ietf-netmod-acl-model-13 rev 2017-06-12 has changed the YANG de=
finition for "ietf-access-control-list:access-lists"
&=
nbsp;

"Add= ed feature and identity statements for different types of rule matches. Spl= it the matching rules based on the feature statement and added a must statement within each container.”=

&nbs= p;

The featu= re containers (e.g. ipv4-acl) are missing from all examples for the filter = rules.

&nbs= p;

"acl= -type" is now of form "ipv4-acl", not "ipv4".=

&nbs= p;

All refer= ences to ietf-access-control-list:= access-lists need to be updated, including the rate-limiting / fragment ext= ensions.

 

[TR] Yes, updated dra= ft to address all above comments.

&nbs= p;

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

&nbs= p;

Regards

&nbs= p;

Jon<= /o:p>

&nbs= p;

 

 

&n= bsp;

--_000_DM5PR16MB1788C05C0C2B03968C68AA5CEA7D0DM5PR16MB1788namp_-- From nobody Mon Oct 2 05:44:29 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A701345EF for ; Mon, 2 Oct 2017 05:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 BUOuI7XXRL8Q for ; Mon, 2 Oct 2017 05:44:27 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 5B0AD1345F5 for ; Mon, 2 Oct 2017 05:44:27 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v92CiQdW028032 for ; Mon, 2 Oct 2017 08:44:26 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu v92CiQdW028032 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1506948266; bh=Yrk3aC7N9rtUyERs+zGQ4u6CTCskstARx1TzOXL6ig0=; h=From:To:Subject:Date:From; b=iXzhv43gniuTh+L5m7/BiCUFxJFTLdzhdSlwMEpj7wjLohOjS94pr6APu6y5Wpd+8 pEYZYCLtMJNUnNzTllfOqqb1OD+YvnJLHhliUgltnucOMqRb1tupcFbJYqbsgGn412 MiQw6NsgyBI5rLqiHx40zjaKbm6zksZibwB9lI9k= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v92CiJUX027527 for ; Mon, 2 Oct 2017 08:44:19 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Mon, 2 Oct 2017 08:44:19 -0400 From: Roman Danyliw To: "'dots@ietf.org'" Thread-Topic: Materials for Today's Virtual Interim Meeting Thread-Index: AdM7e+oqDNURsbieSC+/78ZYbV+k9A== Date: Mon, 2 Oct 2017 12:44:18 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104FE2C64@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Materials for Today's Virtual Interim Meeting X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 12:44:29 -0000 Hello! The materials (agenda and slides) for today's virtual interim meeting can b= e found here: https://datatracker.ietf.org/meeting/interim-2017-dots-03/session/dots As a reminder, the Webex/dial-in information is as follows: =3D=3D[ WebEx Information ]=3D=3D Meeting URL: https://ietf.webex.com/ietf/j.php?MTID=3Dm41f6db21f48c1e8462aecfcc768b02f9 Meeting number: 640 514 336 Meeting password: P9m9Ba8M =20 Dial-in Numbers: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 640 514 336=20 =3D=3D=3D=3D Roman From nobody Mon Oct 2 05:53:55 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED3A134606 for ; Mon, 2 Oct 2017 05:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=mcafee.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 HRxnB_Tldc7c for ; Mon, 2 Oct 2017 05:53:51 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 B5F00134605 for ; Mon, 2 Oct 2017 05:53:49 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1506948828; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=vyUl+AtYjOkcNV+doqFJ3jtEe465Hbr9VG9cUU HCXQk=; b=Up1kXUm9LcIow7YocLHmF0rxJRXOA7cuEo5O+GXD 30vInlHV+ERwamNB5SSqEOgOZpPdW073rWD1zFxZkUS6mL46lp /FgyWa3fywAp2Thm4MGVNapW5Noh+bfOXYaVf5Ak/Uw9JPstJc 2tiYcfvakVEgitmH/8HheRzjNE78Y30= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 50c5_9522_c834c160_023c_425b_8f05_0cad2b89ccfe; Mon, 02 Oct 2017 07:53:47 -0500 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 06:53:46 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 06:53:45 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 2 Oct 2017 06:53:45 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 06:53:43 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 2 Oct 2017 12:53:44 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.016; Mon, 2 Oct 2017 12:53:43 +0000 From: "Konda, Tirumaleswar Reddy" To: kaname nishizuka , "Xialiang (Frank)" , "Dots@ietf.org" Thread-Topic: =?utf-8?B?W0RvdHNdIGFub3RoZXIgb3B0aW9uOi8v562U5aSNOiBDYW4gRE9UUyBwcm90?= =?utf-8?B?b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQncyBB?= =?utf-8?Q?A=3F?= Thread-Index: AdMPF2QONmutCNOvSwe0CfD0yMkBTgAACUnwAA6poPAABEOgkAAAs7nQClUTPoAAB3H3QACYkqsAABC6pfA= Date: Mon, 2 Oct 2017 12:53:43 +0000 Message-ID: References: <2acd7300-6684-1491-4f98-7029d0b7c1b0@nttv6.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.220.42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:dHFMl+3WiUROSq57FlpOlbGZTWcIdjp7LSyMa/GWpuM5vadRasGp+raq/2kTJwxxHO5bLyEvPzOG1GHBVGV7ADYOz3EAH7d08jeT4j9QVdfw6AstsXo2dDH8PtnLbj1YpkNP7H1jA50zzSKY715eAa24EZyajkDJz8qYb5Wlqsc2T0UKuMF+Fo5Pz8vrFEi2IQF2hD8unRfsALReWfxFiVwyzPRGttbxmzo4qbOmLtZlmIrX/mXR0tuTH9EMErakgaxnJ/bhjt1byAeUGav27keG4goVZLUaTB0gE45PeKoNHUzdF/2kEzMPIrhu2gJ51O4IBp9S3TQ/9Sn/OGxJDA==; 5:tFhHGi/FR72gbmgOVj3CkrgDmdS4//QSkUPuwy+dcEqqGtDwxicFQfoIU7ngVqj5RVoQusANCTJ8XeEX+XU5D97JkkACMB2jeZtVbX3NX3pE5p1EAMVVe5pDgIVV2Ndqzwg0yLfxzk1HT3tzXImVA00NPGrPY6JevMV4QVB7vcs=; 24:ANWTT3ZJgCjVDLNAIOu6MvP0iIRgQDQQngCSuNPjghTNT/p7/6Y5xmvjOmC0h5kDxPlmMeRBcB+snSiYX90Byt8q5hom4dAODKeRVgvqtBQ=; 7:/jjiivbbGqsaQqvX9JyiEVPZo6fB/Zxk/yWniDmEk0RDQzhl31gvLHFUBkG82sRwlh/fpx12/xfNzf/vJm5g1TogN5n8ByBdPT1h8tEvSYHBWpk3lMUvZuG6HAaHKae3TH5FWBsWEAaMRt/G72DmW+q7+Bnk3KFBaP4aNM/uT1RHVN0yLBsNZ+pG13OUptA84niGndyk395tob1xHSpp4i5GIabn4Lcx08W7ksRR5Q4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1b7c5bac-586d-4c0e-6081-08d509949cf4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(50582790962513)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(24454002)(51444003)(377454003)(199003)(32952001)(189002)(55016002)(93886005)(6506006)(6436002)(6246003)(102836003)(790700001)(6116002)(2900100001)(33656002)(68736007)(25786009)(54356999)(478600001)(97736004)(76176999)(9686003)(2501003)(966005)(66066001)(50986999)(86362001)(5660300001)(72206003)(236005)(316002)(2906002)(80792005)(77096006)(3660700001)(3280700002)(189998001)(53936002)(54896002)(6306002)(99286003)(101416001)(110136005)(3846002)(53546010)(229853002)(2950100002)(81156014)(106356001)(7696004)(606006)(81166006)(74316002)(14454004)(105586002)(8936002)(224303003)(7736002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178859DFEEE4C31F5907FBF6EA7D0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 12:53:43.5395 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.5 X-NAI-Spam-Version: 2.3.0.9418 : core <6127> : inlines <6104> : streams <1765541> : uri <2510036> Archived-At: Subject: Re: [Dots] =?utf-8?b?YW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RT?= =?utf-8?q?_protocol_support_IP_whitelist_for_DOTS_client=27s_AA=3F?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 12:53:54 -0000 --_000_DM5PR16MB178859DFEEE4C31F5907FBF6EA7D0DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGth bmFtZSBuaXNoaXp1a2ENClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyLCAyMDE3IDEwOjI0IEFNDQpU bzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNB ZmVlLmNvbT47IFhpYWxpYW5nIChGcmFuaykgPGZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20+OyBE b3RzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RvdHNdIGFub3RoZXIgb3B0aW9uOi8v562U5aSN OiBDYW4gRE9UUyBwcm90b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQn cyBBQT8NCg0KT0shDQoNClRoZSByZWFzb24gd2h5IEkgbmVlZCB0aGUgY2xhcmlmaWNhdGlvbiBp cyB0aGF0IHRoZSBsaW5lIGluIFNlY3Rpb24gOSAiQWxzbywgRE9UUyBnYXRld2F5IGFuZCBET1RT IHNlcnZlciBNVVNUIHBlcmZvcm0gbXV0dWFsIGF1dGhlbnRpY2F0aW9uIHVzaW5nIGNlcnRpZmlj YXRlcy4iIGlzIGNvbmZ1c2luZy4NCkkgZmVlbCBpdCBpcyBuZWVkZWQgdG8gYmUgY2xhcmlmaWVk IGluIHRoZSBzaWduYWwgY2hhbm5lbCBkcmFmdCBvciB0aGUgbmV3IGRyYWZ0IHRoYXQgaW4gd2hp Y2ggY2FzZSB0aGUgY2VydGlmaWNhdGVzIGFyZSBtYW5kYXRvcnkuDQpJIHRoaW5rIHRoYXQgaXMg dGhlIGNhc2UgRE9UUyBhZ2VudHMgYXJlIGluIHRoZSBkaWZmZXJlbnQgZG9tYWluLg0KWWVzLCB1 cGRhdGVkIGFib3ZlIGxpbmUgdG8gc2F5IOKAnEFsc28sIERPVFMgZ2F0ZXdheSBhbmQgRE9UUyBz ZXJ2ZXIgbG9jYXRlZCBpbiBkaWZmZXJlbnQgZG9tYWlucyBNVVNUIHBlcmZvcm0gbXV0dWFsIGF1 dGhlbnRpY2F0aW9uIHVzaW5nIGNlcnRpZmljYXRlcy7igJ0NCi1UaXJ1DQoNCg0KdGhhbmtzLA0K a2FuYW1lDQoNCk9uIDIwMTcvMDkvMjkgMTM6MjIsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkg d3JvdGU6DQpUaGUgc2lnbmFsIGNoYW5uZWwgZHJhZnQgZG9lcyBub3QgbWFuZGF0ZSBjZXJ0aWZp Y2F0ZXMgZm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiAoVXNpbmcgYW4gQUFBIHNlcnZlciBpcyBv bmx5IGFuIGV4YW1wbGUgZGVwbG95bWVudCkuIERPVFMgYWdlbnRzIGluIHRoZSBzYW1lIGRvbWFp biBjYW4gdXNlIG90aGVyIG1lY2hhbmlzbXMgbGlrZSBUTFMtUFNLIGFuZCBTUEtJLiBBbmRyZXcg YW5kIEkgYW0gcGxhbm5pbmcgcHV0IHVwIGEgZHJhZnQgb24gRE9UUyBwcm92aXNpb25pbmcuDQoN Ci1UaXJ1DQoNCkZyb206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBrYW5hbWUgbmlzaGl6dWthDQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAyOSwgMjAx NyA2OjAyIEFNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbT48bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZl ZS5jb20+OyBYaWFsaWFuZyAoRnJhbmspIDxmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tPjxtYWls dG86ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbT47IERvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0RvdHNdIGFub3RoZXIgb3B0aW9uOi8v562U5aSNOiBD YW4gRE9UUyBwcm90b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQncyBB QT8NCg0KSGkgVGlydSwNCg0KaW4gc2VjdGlvbiA5IG9mIHNpZ25hbC1jaGFubmVsIGRyYWZ0LCBB QUEgc2VydmVyIGV4aXN0cy4NCkxldCBtZSBjbGFyaWZ5IHRoZSB0ZXh0Lg0KDQpNdXR1YWwgYXV0 aGVudGljYXRpb24gYmV0d2VlbiBhIERPVFMgY2xpZW50IGFuZCBhIERPVFMgZ2F0ZXdheSBNVVNU IHVzZSAoY2xpZW50KSBjZXJ0aWZpY2F0ZXM/DQpCZXR3ZWVuIHRoZW0gKGluIHRoZSBzYW1lIGRv bWFpbiksIGEgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIHdpdGhvdXQgY2VydGlmaWNhdGVzIChpLmUu IGNob2ljZXMgb3RoZXIgdGhhbiBFQVAtVExTKSB3b3VsZCBiZSBhIGdvb2Qgb3B0aW9uLCBpZiBp dCBtZWV0cyB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9uIHJlcXVpcmVt ZW50Lg0KDQpUTFMtUFNLIG1vZGUgYW5kIFN1YmplY3QgUHVibGljIEtleSBJbmZvIChTUEtJKSAg bG9va3MgZ29vZCB0byBtZS4NCg0KSSBob3BlIHRob3NlIG9wdGlvbnMgd291bGQgYmUgZGlzY3Vz c2VkIGluIFdHbWVldGluZy4NCg0KDQoNCk9uIDIwMTcvMDgvMDcgMTk6MTksIEtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkgd3JvdGU6DQpZb3UgbWF5IHdhbnQgdG8gbG9vayBpbnRvIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTU5I3NlY3Rpb24tNw0KPHNuaXA+DQogICBFdmVuIGlm IGV2ZXJ5IEludGVybmV0LWNvbm5lY3RlZCBuZXR3b3JrIGltcGxlbWVudHMgc291cmNlIGFkZHJl c3MNCiAgIHZhbGlkYXRpb24gYXQgdGhlIHVsdGltYXRlIG5ldHdvcmsgaW5ncmVzcywgYW5kIGFz c3VyYW5jZXMgZXhpc3QgdGhhdA0KICAgaW50ZXJtZWRpYXRlIGRldmljZXMgYXJlIHRvIG5ldmVy IG1vZGlmeSBkYXRhZ3JhbSBzb3VyY2UgYWRkcmVzc2VzLA0KICAgc291cmNlIGFkZHJlc3NlcyBj YW5ub3QgYmUgdXNlZCBhcyBhbiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20uDQoNCi1UaXJ1DQoN CkZyb206IFhpYWxpYW5nIChGcmFuaykgW21haWx0bzpmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29t XQ0KU2VudDogTW9uZGF5LCBBdWd1c3QgNywgMjAxNyAzOjI4IFBNDQpUbzogS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT48bWFpbHRv OlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyBEb3RzQGlldGYub3JnPG1haWx0 bzpEb3RzQGlldGYub3JnPg0KU3ViamVjdDog562U5aSNOiBhbm90aGVyIG9wdGlvbjovL+etlOWk jTogQ2FuIERPVFMgcHJvdG9jb2wgc3VwcG9ydCBJUCB3aGl0ZWxpc3QgZm9yIERPVFMgY2xpZW50 J3MgQUE/DQoNCkhpIFRpcnUsDQpUaGFua3MgZm9yIHlvdXIgYW5hbHlzaXMuIEl0IG1ha2VzIHNl bnNlIHRvIG1lfn4NCg0KVG8gYmUgYWNjdXJhdGUsIElQIHdoaXRlbGlzdCBkb2VzIG5vdCByZWxh eCB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50LCBidXQgaW5kZWVkIGxvc2Ug dGhlIGVuY3J5cHRpb24gYmVuZWZpdHMuDQoNCkIuUi4NCkZyYW5rDQoNCuWPkeS7tuS6ujogS29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeSBbbWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1j QWZlZS5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTflubQ45pyIN+aXpSAxNzo1MQ0K5pS25Lu25Lq6 OiBYaWFsaWFuZyAoRnJhbmspOyBEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGlldGYub3JnPg0K 5Li76aKYOiBSRTogYW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RTIHByb3RvY29sIHN1 cHBvcnQgSVAgd2hpdGVsaXN0IGZvciBET1RTIGNsaWVudCdzIEFBPw0KDQpUTFMgc3VwcG9ydHMg cHJlLXNoYXJlZCBrZXkgYmFzZWQgYXV0aGVudGljYXRpb24uIFRoZSBvdGhlciBtZWNoYW5pc21z IGFyZSBTdWJqZWN0IFB1YmxpYyBLZXkgSW5mbyAoU1BLSSkgRmluZ2VycHJpbnQgcGluIHNldCBm b3IgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIChzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZXMgb3IgcmF3 IHB1YmxpYyBrZXlzKSB3aXRob3V0IGhhdmluZyB0byBkZWFsIHdpdGggQ0EuDQoNCkkgZG9u4oCZ dCB0aGluayBET1RTIHNob3VsZCByZWxheCB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGFuZCBl bmNyeXB0aW9uIHJlcXVpcmVtZW50cy4NCg0KLVRJcnUNCg0KRnJvbTogRG90cyBbbWFpbHRvOmRv dHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFhpYWxpYW5nIChGcmFuaykNClNlbnQ6 IE1vbmRheSwgQXVndXN0IDcsIDIwMTcgNjoyNSBBTQ0KVG86IERvdHNAaWV0Zi5vcmc8bWFpbHRv OkRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRG90c10gYW5vdGhlciBvcHRpb246Ly/nrZTlpI06 IENhbiBET1RTIHByb3RvY29sIHN1cHBvcnQgSVAgd2hpdGVsaXN0IGZvciBET1RTIGNsaWVudCdz IEFBPw0KDQpJbiBhZGRpdGlvbiB0byBJUCB3aGl0ZWxpc3QgYW5kIGNlcnRpZmljYXRlLCBwcmUt c2hhcmUga2V5IGNhbiBhbHNvIGJlIGFuIG9wdGlvbi4NClJpZ2h0Pw0KDQrlj5Hku7bkuro6IERv dHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBYaWFsaWFuZyAoRnJhbmsp DQrlj5HpgIHml7bpl7Q6IDIwMTflubQ45pyIN+aXpSA4OjUyDQrmlLbku7bkuro6IERvdHNAaWV0 Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQrkuLvpopg6IFtEb3RzXSBDYW4gRE9UUyBwcm90 b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQncyBBQT8NCg0KSGksDQpJ IHRoaW5rIHRoZSBkaXJlY3QgdXNlIG9mIElQIHdoaXRlbGlzdCBvbiB0aGUgRE9UUyBzZXJ2ZXIg dG8gYXV0aGVudGljYXRlIGFuZCBhdXRob3JpemUgdGhlIERPVFMgY2xpZW50IGlzIGEgc2ltcGxl IGFuZCBlZmZlY3QgbWV0aG9kLCBhdCBsZWFzdCBpbiBzb21lIHNwZWNpYWwgdXNlIGNhc2VzLCBs aWtlOiBET1RTIGNsaWVudCBkb2VzIG5vdCBzdXBwb3J0IGNlcnRpZmljYXRlLCBhbiBJU1Agd2hp Y2ggZGV0ZWN0cyB0aGUgc3Bvb2ZlZCBzb3VyY2UgYWRkcmVzcywgZXRjLg0KDQpTbywgc2hvdWxk IHdlIHN1cHBvcnQgdGhpcyBhcyBhbiBvcHRpb25hbCB3YXkgZm9yIHRoZSBET1RTIGNsaWVudOKA mXMgQUEgYW5kIGFkZCBpdCBpbnRvIHRoZSBET1RTIHByb3RvY29sIGRyYWZ0cz8NCg0KQi5SLg0K RnJhbmsNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpEb3RzIG1haWxpbmcgbGlzdA0KDQpEb3RzQGlldGYub3JnPG1haWx0bzpEb3Rz QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMN Cg0KDQo= --_000_DM5PR16MB178859DFEEE4C31F5907FBF6EA7D0DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAy IDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTWljcm9zb2Z0IEpoZW5nSGVpIjsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQE1pY3Jvc29mdCBKaGVuZ0hlaSI7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBT aW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIFwsc2VyaWYiOw0KCXBhbm9zZS0xOjAgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJT ZWdvZSBVSSIsc2Fucy1zZXJpZjt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueaz qOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnAuYSwgbGkuYSwgZGl2LmENCgl7bXNvLXN0eWxlLW5hbWU65om55rOo5qGG5paH5pysOw0KCW1z by1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0K c3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFp bFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4y NWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4gRG90 cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+a2Fu YW1lIG5pc2hpenVrYTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMiwgMjAxNyAx MDoyNCBBTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7VGly dW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSZndDs7IFhpYWxpYW5nIChGcmFuaykgJmx0 O2ZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20mZ3Q7OyBEb3RzQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbRG90c10gYW5vdGhlciBvcHRpb246Ly88L3NwYW4+PHNwYW4gbGFuZz0i WkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29m dCBKaGVuZ0hlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPuetlOWkjTwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij46IENhbiBE T1RTIHByb3RvY29sIHN1cHBvcnQgSVAgd2hpdGVsaXN0IGZvcg0KIERPVFMgY2xpZW50J3MgQUE/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi IHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PSyE8YnI+DQo8YnI+DQpU aGUgcmVhc29uIHdoeSBJIG5lZWQgdGhlIGNsYXJpZmljYXRpb24gaXMgdGhhdCB0aGUgbGluZSBp biBTZWN0aW9uIDkgJnF1b3Q7QWxzbywgRE9UUyBnYXRld2F5IGFuZCBET1RTIHNlcnZlciBNVVNU IHBlcmZvcm0gbXV0dWFsIGF1dGhlbnRpY2F0aW9uIHVzaW5nIGNlcnRpZmljYXRlcy4mcXVvdDsg aXMgY29uZnVzaW5nLjxicj4NCkkgZmVlbCBpdCBpcyBuZWVkZWQgdG8gYmUgY2xhcmlmaWVkIGlu IHRoZSBzaWduYWwgY2hhbm5lbCBkcmFmdCBvciB0aGUgbmV3IGRyYWZ0IHRoYXQgaW4gd2hpY2gg Y2FzZSB0aGUgY2VydGlmaWNhdGVzIGFyZSBtYW5kYXRvcnkuPGJyPg0KSSB0aGluayB0aGF0IGlz IHRoZSBjYXNlIERPVFMgYWdlbnRzIGFyZSBpbiB0aGUgZGlmZmVyZW50IGRvbWFpbi48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5ZZXMsIHVwZGF0ZWQgYWJvdmUgbGluZSB0 byBzYXkg4oCcQWxzbywgRE9UUyBnYXRld2F5IGFuZCBET1RTIHNlcnZlciBsb2NhdGVkIGluIGRp ZmZlcmVudCBkb21haW5zIE1VU1QgcGVyZm9ybSBtdXR1YWwgYXV0aGVudGljYXRpb24gdXNpbmcg Y2VydGlmaWNhdGVzLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4N CnRoYW5rcyw8YnI+DQprYW5hbWU8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIDIwMTcvMDkvMjkgMTM6MjIsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+VGhlIHNpZ25hbCBjaGFubmVsIGRy YWZ0IGRvZXMgbm90IG1hbmRhdGUgY2VydGlmaWNhdGVzIGZvciBtdXR1YWwgYXV0aGVudGljYXRp b24gKFVzaW5nIGFuIEFBQSBzZXJ2ZXIgaXMgb25seSBhbiBleGFtcGxlIGRlcGxveW1lbnQpLiBE T1RTIGFnZW50cyBpbiB0aGUgc2FtZSBkb21haW4gY2FuIHVzZSBvdGhlciBtZWNoYW5pc21zDQog bGlrZSBUTFMtUFNLIGFuZCBTUEtJLiBBbmRyZXcgYW5kIEkgYW0gcGxhbm5pbmcgcHV0IHVwIGEg ZHJhZnQgb24gRE9UUyBwcm92aXNpb25pbmcuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5k b3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4tVGlydTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFs aWduOmxlZnQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3Rl eHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3 aW5kb3d0ZXh0Ij4gRG90cyBbPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+ bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPmth bmFtZSBuaXNoaXp1a2E8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBTZXB0ZW1iZXIgMjksIDIw MTcgNjowMiBBTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8YSBo cmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+DQombHQ7VGly dW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSZndDs8L2E+OyBYaWFsaWFuZyAoRnJhbmsp IDxhIGhyZWY9Im1haWx0bzpmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tIj4NCiZsdDtmcmFuay54 aWFsaWFuZ0BodWF3ZWkuY29tJmd0OzwvYT47IDxhIGhyZWY9Im1haWx0bzpEb3RzQGlldGYub3Jn Ij5Eb3RzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNdIGFub3Ro ZXIgb3B0aW9uOi8vPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpEZW5nWGlhbiI+562U5aSNPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPjogQ2FuIERPVFMgcHJvdG9jb2wgc3VwcG9y dCBJUCB3aGl0ZWxpc3QgZm9yIERPVFMgY2xpZW50J3MgQUE/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHls ZT0idGV4dC1hbGlnbjpsZWZ0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgVGlydSw8YnI+DQo8YnI+DQpp biBzZWN0aW9uIDkgb2Ygc2lnbmFsLWNoYW5uZWwgZHJhZnQsIEFBQSBzZXJ2ZXIgZXhpc3RzLjxi cj4NCkxldCBtZSBjbGFyaWZ5IHRoZSB0ZXh0Ljxicj4NCjxicj4NCk11dHVhbCBhdXRoZW50aWNh dGlvbiBiZXR3ZWVuIGEgRE9UUyBjbGllbnQgYW5kIGEgRE9UUyBnYXRld2F5IE1VU1QgdXNlIChj bGllbnQpIGNlcnRpZmljYXRlcz88YnI+DQpCZXR3ZWVuIHRoZW0gKGluIHRoZSBzYW1lIGRvbWFp biksIGEgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIHdpdGhvdXQgY2VydGlmaWNhdGVzIChpLmUuIGNo b2ljZXMgb3RoZXIgdGhhbiBFQVAtVExTKSB3b3VsZCBiZSBhIGdvb2Qgb3B0aW9uLCBpZiBpdCBt ZWV0cyB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9uIHJlcXVpcmVtZW50 Ljxicj4NCjxicj4NClRMUy1QU0sgbW9kZSBhbmQgU3ViamVjdCBQdWJsaWMgS2V5IEluZm8gKFNQ S0kpJm5ic3A7IGxvb2tzIGdvb2QgdG8gbWUuPGJyPg0KPGJyPg0KSSBob3BlIHRob3NlIG9wdGlv bnMgd291bGQgYmUgZGlzY3Vzc2VkIGluIFdHbWVldGluZy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMDE3LzA4 LzA3IDE5OjE5LCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5Zb3UgbWF5IHdhbnQgdG8gbG9vayBpbnRvIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM2OTU5I3NlY3Rpb24tNyI+DQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjk1OSNzZWN0aW9uLTc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZsdDtzbmlwJmd0 Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgRXZlbiBpZiBldmVyeSBJbnRlcm5ldC1j b25uZWN0ZWQgbmV0d29yayBpbXBsZW1lbnRzIHNvdXJjZSBhZGRyZXNzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOyZuYnNwOyB2YWxpZGF0aW9uIGF0IHRoZSB1bHRpbWF0ZSBuZXR3b3JrIGluZ3Jl c3MsIGFuZCBhc3N1cmFuY2VzIGV4aXN0IHRoYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i c3A7IGludGVybWVkaWF0ZSBkZXZpY2VzIGFyZSB0byBuZXZlciBtb2RpZnkgZGF0YWdyYW0gc291 cmNlIGFkZHJlc3Nlcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHNvdXJjZSBhZGRy ZXNzZXMgY2Fubm90IGJlIHVzZWQgYXMgYW4gYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LVRpcnU8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+IFhpYWxpYW5nIChGcmFuaykgWzxhIGhyZWY9Im1haWx0bzpmcmFuay54aWFsaWFuZ0Bo dWF3ZWkuY29tIj5tYWlsdG86ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgNywgMjAxNyAzOjI4IFBNPGJyPg0KPGI+VG86PC9i PiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tIj4NCiZsdDtUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0Fm ZWUuY29tJmd0OzwvYT47IDxhIGhyZWY9Im1haWx0bzpEb3RzQGlldGYub3JnIj5Eb3RzQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkRlbmdYaWFuIj7nrZTlpI08L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjogYW5vdGhlciBvcHRpb246Ly88L3NwYW4+ PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkRl bmdYaWFuIj7nrZTlpI08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjoNCiBD YW4gRE9UUyBwcm90b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQncyBB QT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkhpIFRpcnUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciBhbmFseXNpcy4gSXQgbWFr ZXMgc2Vuc2UgdG8gbWV+fjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VG8g YmUgYWNjdXJhdGUsIElQIHdoaXRlbGlzdCBkb2VzIG5vdCByZWxheCB0aGUgbXV0dWFsIGF1dGhl bnRpY2F0aW9uIHJlcXVpcmVtZW50LCBidXQgaW5kZWVkIGxvc2UgdGhlIGVuY3J5cHRpb24gYmVu ZWZpdHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CLlIuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkZyYW5rPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PHNwYW4gbGFuZz0iWkgtQ04i IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+5Y+R5Lu25Lq6PC9z cGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1T dW4iPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OlNpbVN1biI+IEtvbmRhLA0KIFRpcnVtYWxlc3dhciBSZWRkeSBbPGEgaHJlZj0ibWFpbHRvOlRp cnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPm1haWx0bzpUaXJ1bWFsZXN3YXJSZWRk eV9Lb25kYUBNY0FmZWUuY29tPC9hPl0NCjxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7lj5Hp gIHml7bpl7Q8L3NwYW4+OjwvYj4gMjAxNzxzcGFuIGxhbmc9IlpILUNOIj7lubQ8L3NwYW4+ODxz cGFuIGxhbmc9IlpILUNOIj7mnIg8L3NwYW4+NzxzcGFuIGxhbmc9IlpILUNOIj7ml6U8L3NwYW4+ IDE3OjUxPGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaUtuS7tuS6ujwvc3Bhbj46PC9iPiBY aWFsaWFuZyAoRnJhbmspOyA8YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyI+DQpEb3RzQGll dGYub3JnPC9hPjxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7kuLvpopg8L3NwYW4+OjwvYj4g UkU6IGFub3RoZXIgb3B0aW9uOi8vPHNwYW4gbGFuZz0iWkgtQ04iPuetlOWkjTwvc3Bhbj46IENh biBET1RTIHByb3RvY29sIHN1cHBvcnQgSVAgd2hpdGVsaXN0IGZvciBET1RTIGNsaWVudCdzIEFB Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+VExTIHN1cHBvcnRzIHByZS1zaGFyZWQga2V5IGJhc2VkIGF1dGhlbnRpY2F0aW9uLiBUaGUg b3RoZXIgbWVjaGFuaXNtcyBhcmUgU3ViamVjdCBQdWJsaWMgS2V5IEluZm8gKFNQS0kpIEZpbmdl cnByaW50IHBpbiBzZXQgZm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiAoc2VsZi1zaWduZWQgY2Vy dGlmaWNhdGVzIG9yIHJhdyBwdWJsaWMga2V5cykgd2l0aG91dA0KIGhhdmluZyB0byBkZWFsIHdp dGggQ0EuICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ SSBkb27igJl0IHRoaW5rIERPVFMgc2hvdWxkIHJlbGF4IHRoZSBtdXR1YWwgYXV0aGVudGljYXRp b24gYW5kIGVuY3J5cHRpb24gcmVxdWlyZW1lbnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+LVRJcnU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9 InRleHQtYWxpZ246bGVmdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IERvdHMgWzxhIGhyZWY9 Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5YaWFsaWFuZyAoRnJhbmspPGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgQXVndXN0IDcsIDIwMTcgNjoyNSBBTTxicj4NCjxiPlRvOjwvYj4gPGEg aHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPkRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFtEb3RzXSBhbm90aGVyIG9wdGlvbjovLzwvc3Bhbj48c3BhbiBsYW5nPSJaSC1D TiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj7nrZTlpI08L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjogQ2FuIERPVFMgcHJvdG9jb2wgc3Vw cG9ydCBJUCB3aGl0ZWxpc3QgZm9yIERPVFMgY2xpZW50J3MgQUE/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBz dHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JbiBhZGRpdGlvbiB0byBJUCB3 aGl0ZWxpc3QgYW5kIGNlcnRpZmljYXRlLCBwcmUtc2hhcmUga2V5IGNhbiBhbHNvIGJlIGFuIG9w dGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+UmlnaHQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PHNw YW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1 biI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpTaW1TdW4iPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+IERvdHMNCiBbPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPjxzcGFu IGxhbmc9IlpILUNOIj7ku6PooagNCjwvc3Bhbj48L2I+WGlhbGlhbmcgKEZyYW5rKTxicj4NCjxi PjxzcGFuIGxhbmc9IlpILUNOIj7lj5HpgIHml7bpl7Q8L3NwYW4+OjwvYj4gMjAxNzxzcGFuIGxh bmc9IlpILUNOIj7lubQ8L3NwYW4+ODxzcGFuIGxhbmc9IlpILUNOIj7mnIg8L3NwYW4+NzxzcGFu IGxhbmc9IlpILUNOIj7ml6U8L3NwYW4+IDg6NTI8YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1DTiI+ 5pS25Lu25Lq6PC9zcGFuPjo8L2I+IDxhIGhyZWY9Im1haWx0bzpEb3RzQGlldGYub3JnIj5Eb3Rz QGlldGYub3JnPC9hPjxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7kuLvpopg8L3NwYW4+Ojwv Yj4gW0RvdHNdIENhbiBET1RTIHByb3RvY29sIHN1cHBvcnQgSVAgd2hpdGVsaXN0IGZvciBET1RT IGNsaWVudCdzIEFBPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIGRpcmVjdCB1c2Ugb2YgSVAgd2hp dGVsaXN0IG9uIHRoZSBET1RTIHNlcnZlciB0byBhdXRoZW50aWNhdGUgYW5kIGF1dGhvcml6ZSB0 aGUgRE9UUyBjbGllbnQgaXMgYSBzaW1wbGUgYW5kIGVmZmVjdCBtZXRob2QsIGF0IGxlYXN0IGlu IHNvbWUgc3BlY2lhbCB1c2UgY2FzZXMsIGxpa2U6IERPVFMgY2xpZW50IGRvZXMgbm90IHN1cHBv cnQgY2VydGlmaWNhdGUsIGFuIElTUCB3aGljaCBkZXRlY3RzDQogdGhlIHNwb29mZWQgc291cmNl IGFkZHJlc3MsIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIHNob3VsZCB3ZSBzdXBw b3J0IHRoaXMgYXMgYW4gb3B0aW9uYWwgd2F5IGZvciB0aGUgRE9UUyBjbGllbnTigJlzIEFBIGFu ZCBhZGQgaXQgaW50byB0aGUgRE9UUyBwcm90b2NvbCBkcmFmdHM/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkIuUi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyYW5rPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiAsc2VyaWYmcXVvdDssc2VyaWYi Pjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5Eb3RzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy ZWY9Im1haWx0bzpEb3RzQGlldGYub3JnIj5Eb3RzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG90cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzPC9hPjxvOnA+ PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i bGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICxzZXJpZiZxdW90OyxzZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_DM5PR16MB178859DFEEE4C31F5907FBF6EA7D0DM5PR16MB1788namp_-- From nobody Mon Oct 2 05:57:34 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E4F134614; Mon, 2 Oct 2017 05:57:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150694905297.28721.1916467272896017142@ietfa.amsl.com> Date: Mon, 02 Oct 2017 05:57:33 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-04.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 12:57:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-04.txt Pages : 53 Date : 2017-10-02 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-04 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 2 06:04:13 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E538134616 for ; Mon, 2 Oct 2017 06:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 SZVS_eKdiz3p for ; Mon, 2 Oct 2017 06:04:08 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 2B2C613460D for ; Mon, 2 Oct 2017 06:03:47 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1506949426; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=v j0iWkD83iES4nLUhVSLMY2PlGUB1NzIT9qEYNU+lF 4=; b=ZfujIkqx+aE2SaSS1Vj20guQNiQBvI6u2+q7O77wYOUG KCxZV8rIkewdKFZ8ADxI5Ce2N6fPghVJPyAL9BKpEAjusDOCWN I+qa3NdIl5cdexq+akC5r0eEtxjrMK3wOiefpPvh0b6VUAbSUO JmPOnHI12c+GYWoxOsGORVBPBjU= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 50c5_ab2e_1f6368ee_6e65_478f_b507_2590f166266d; Mon, 02 Oct 2017 08:03:45 -0500 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 09:03:44 -0400 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 09:03:43 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 2 Oct 2017 09:03:43 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 09:03:41 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 2 Oct 2017 13:03:42 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.016; Mon, 2 Oct 2017 13:03:42 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-04.txt Thread-Index: AQHTO34QDz54PqTEEU+y5AF+lKKpPqLQhokQ Date: Mon, 2 Oct 2017 13:03:41 +0000 Message-ID: References: <150694905297.28721.1916467272896017142@ietfa.amsl.com> In-Reply-To: <150694905297.28721.1916467272896017142@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.220.42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:xEA6x+51YIN/uQ4D1vcNJtfxhLIk/vWhlA02BXyAAy4c8PAJ2U1PH4Qtl0Af/7I0BS6vcg74vIk8s/X2hpcQ68/mF5EGSPbIIul0mP6XJ/LarMjuSlwPnuHWoPGvW/BefLMLKUpZtIHviSU8Rp+kzUFf8OsLAd1vIUVDLHCF8PJrqy9/yvm4a3ibyOEEpS0yUZhvKGB746XUXPpil4UiYjbeBLXVYoR7Q22sjWgPfgf4F+gMadqmQJ4T66mVLnZLLF44wV6Lk1cJs95JSNfB9OTMwPrB699J5nMSu45u84EILSvmu/sgmsB1ngg4tS/ViQ3TQ+n5RLcelpattg+yuw==; 5:I/NV5gsys4I/HPexPCSbthWiZmki7NQ99KvYjfK2uJj+or8JO94KLxCmozVt+heF7ih/TMFLnVzCwZ3MmD2ZNZpD1S1I0G8WLYurjed6h4UbjmIygtioKQy+R/+wSUTEi7KNc3Bd9Q4weO2dX4PC3g==; 24:01l41+39O1vwadCPlIF0b65GjrAOhWBABiQyZhUdTmltvTySU3AyhlpVVypgsXLHApOO5PQnYmnxfCjr+d8bji32xDbI+TDMHflV9jfB0Vg=; 7:G6Pr+mKoPp/Ebu8SsPYHdPVUXc7eKYhVj/HK7pDC9zy/uaz87m49j72gX4OLxd1UaK6MBqLfO+aZzglI6+CeeoBqXBYKjIJ90f151AShRX/ZTvzdneMvkwq2gl8j0zPMllWyaT4aAVtdy1dWYsoLwNGWxnxauRQSnv//cZBoGZps241Nt1Bzz2JCxUNYt+oolaheB6ntmGGz0kqsom6K/MbuAbw0wvszbfYIvqy+zfY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6db4e424-e32d-4d15-0c78-08d5099601b1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(32952001)(189002)(377424004)(13464003)(377454003)(53936002)(6306002)(99286003)(101416001)(189998001)(3846002)(80792005)(316002)(2906002)(3280700002)(3660700001)(77096006)(14454004)(105586002)(74316002)(8676002)(7736002)(1730700003)(305945005)(8936002)(229853002)(6916009)(2950100002)(53546010)(81166006)(7696004)(106356001)(81156014)(102836003)(2900100001)(6116002)(230783001)(68736007)(25786009)(33656002)(6436002)(6246003)(55016002)(6506006)(66066001)(2501003)(966005)(72206003)(86362001)(50986999)(5660300001)(5640700003)(97736004)(478600001)(54356999)(2351001)(9686003)(76176999)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 13:03:41.9980 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6127> : inlines <6104> : streams <1765542> : uri <2510041> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-04.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 13:04:10 -0000 This revision https://tools.ietf.org/html/draft-ietf-dots-signal-channel-04= addresses various comments received from Jon.=20 -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, October 2, 2017 6:28 PM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-04.txt > Pages : 53 > Date : 2017-10-02 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. A companion > document defines the DOTS data channel, a separate reliable > communication layer for DOTS management and configuration. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-04 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Oct 2 06:04:23 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F981132320; Mon, 2 Oct 2017 06:04:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150694946014.28704.11331417256352977239@ietfa.amsl.com> Date: Mon, 02 Oct 2017 06:04:20 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-04.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 13:04:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Kaname Nishizuka Liang Xia Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-data-channel-04.txt Pages : 25 Date : 2017-10-02 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data not easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-04 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 2 06:06:41 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB126132320 for ; Mon, 2 Oct 2017 06:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 1D7hGSmzg_51 for ; Mon, 2 Oct 2017 06:06:37 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 0533113460D for ; Mon, 2 Oct 2017 06:06:35 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1506949595; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=1 WY3wwv5nx9ULqi2Oc4gexiNgnJxIQrMGUqaSTS9/F c=; b=i7Zl4kU5ru9plKcUjd69wKi9KntxKDn7cpOGQgrGPry1 oZUtHc+LczdZNu2X68OMUA944WqyaEEti4KLDz2aOPymsqbUmp gONWYOWWHr1r8Kik70IZZSg2eDcyLbmIuLrZMR1Zxs+0MBxWrl VPJ316Gsl/WUnrQ2gnrC9reNrBM= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 50c5_b233_f98bbe14_8309_4d9b_9fca_af027de18e6b; Mon, 02 Oct 2017 08:06:34 -0500 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 07:06:34 -0600 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 07:06:33 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 2 Oct 2017 07:06:33 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 2 Oct 2017 07:06:31 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 2 Oct 2017 13:06:32 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.016; Mon, 2 Oct 2017 13:06:31 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-04.txt Thread-Index: AQHTO38Jb4lRANCzXkiv4z6yEIhTeaLQhzUw Date: Mon, 2 Oct 2017 13:06:31 +0000 Message-ID: References: <150694946014.28704.11331417256352977239@ietfa.amsl.com> In-Reply-To: <150694946014.28704.11331417256352977239@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.220.42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:0BN2Ymuo4cHSABTqrQKDIF91aLEG9lxpqPa854x2xZmPQ7wKkvFheZOaojarwOQZ+lPZRmJLSWHUJd0QcN9tPgQpJTIJ+Xv9doWmT7DLTLwmpk9KmMn66ZEbu9oUe5z0OKQnUN6POdGmrj0F0vMgUof8LgRpGixAmaiCfOrT7T0qNmLOapltkrJvLrz3eyIYqsgOIWRKI3KXQ7CZFI0cOQyba1GRf1rd1uiKeZca445EvD4EzY4guxUCadyeIOF74DLRd5oaOj5LIJ1VLd8YZXKHxzayTryFqrj1kJH6C7dCz47SO+7zf724pkLwG935+grHqwfi4mxSJz+2mFFfBg==; 5:H7MotiWoAq2p7V12fIIGW96woSh7Mi60B11SdiCagehlJ74DocpeGfEcG47ghzBaK2lJYFRQ3tuv0SRuBg43+APBN9wspbXG1e5s6l2Hk4V+4T2HSbq7+LhT0yNYf4UbjjuaHfDGfSVcHalYlQXpZA==; 24:TbLi7cv7sKFPJvdwlDQlXV5JHJPWB0U43XVSscOVuV/ulfiqwFvRBr2bgqsIbdOf1lWj4fl+ErfZeOa2AjK9SEAB28X0tralrVDkESYFT14=; 7:kmLc0z6zadPhxZaBlD8T2CaGQvwigNp9Gpc3qOmAbxL8tZkKAENrSyY2Ya8+iOyC+MrA1Cnhg59rqvyU43eJUKlu9vxRb+7l24dObPtJ5P9zAm2zjxa6l6zL8n12Qr7OB1bOR9DSSXECxvUulWJCX49xtoQifEMainM+Hk+FpNdtmkT0XE+yPyVejmZ+gLXqI23zCneddPZLh0PNH2/mxnz/kh/4vU2t2ThsNs23vLw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: aec0795c-f332-488b-89e6-08d5099666d5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(376002)(346002)(199003)(32952001)(189002)(377424004)(13464003)(377454003)(53936002)(6306002)(99286003)(101416001)(189998001)(3846002)(80792005)(316002)(2906002)(3280700002)(3660700001)(77096006)(14454004)(105586002)(74316002)(8676002)(7736002)(1730700003)(305945005)(8936002)(229853002)(6916009)(2950100002)(53546010)(81166006)(7696004)(106356001)(81156014)(102836003)(2900100001)(6116002)(230783001)(68736007)(25786009)(33656002)(6436002)(6246003)(55016002)(6506006)(66066001)(2501003)(966005)(72206003)(86362001)(50986999)(5660300001)(5640700003)(97736004)(478600001)(54356999)(2351001)(9686003)(76176999)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 13:06:31.7339 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6127> : inlines <6104> : streams <1765542> : uri <2510043> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-04.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 13:06:40 -0000 This revision https://tools.ietf.org/html/draft-ietf-dots-data-channel-04 a= ddresses comments from Jon and aligns with the ACL YANG module updates in h= ttps://tools.ietf.org/html/draft-ietf-netmod-acl-model-13. -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, October 2, 2017 6:34 PM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Data Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Kaname Nishizuka > Liang Xia > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-data-channel-04.txt > Pages : 25 > Date : 2017-10-02 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data not > easily or appropriately communicated through the DOTS signal channel > under attack conditions. This is a companion document to the DOTS > signal channel specification. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-data-channel-04 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Oct 3 07:26:10 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47BF134CF6 for ; Tue, 3 Oct 2017 07:26:08 -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=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9IfDJB_LEoh for ; Tue, 3 Oct 2017 07:26:04 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 3A89C134DD0 for ; Tue, 3 Oct 2017 07:20:43 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dzO3s-0003SK-FT; Tue, 03 Oct 2017 15:20:40 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> <00a101d32d46$b2f30cf0$18d926d0$@jpshallow.com> <037c01d33a2c$ed764700$c862d500$@jpshallow.com> <040401d33ac9$85542c80$8ffc8580$@jpshallow.com> In-Reply-To: Date: Tue, 3 Oct 2017 15:20:40 +0100 Message-ID: <060201d33c52$ca5ca390$5f15eab0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJWDLbdGWgIliMeta88DlSb7Xyh6wERxjbqAVIVJZ8CskQHRgGAczJ7AlDJcXmhhCBDYA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 14:26:09 -0000 Hi Tiru, Several things 1) Missing target-prefix CBOR mapping in signal spec 2) mitigation-start representation in signal spec It does not appear in Fig 10. It is defined as being in seconds " mitigation-start: Mitigation start time is represented in seconds relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of [RFC7049])." But as a float representation | CurrentValue | 29 | 0 | | mitigation-start | 30 | 7 (floating-point) | \--------------------+------------------------+--------------------------/ Which is OK. A CBOR tag of 1 followed by a value of a floating point number. However, there is no direct JSON equivalent of this that I can find. So, should it be displayed (in JSON) as UTC, local timezone or simply seconds? Mitigation-start: 2017-10-03T10:15:30-05:00 Or Mitigation-start: 2017-10-03T15:15:30Z Or Mitigation-start: 1507040181.567890 Regards Jon From nobody Tue Oct 3 07:55:55 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F44134E1F for ; Tue, 3 Oct 2017 07:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 lJg2vAyEEqUU for ; Tue, 3 Oct 2017 07:55:52 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 EB18D134CF6 for ; Tue, 3 Oct 2017 07:51:26 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v93EpMMl029357 for ; Tue, 3 Oct 2017 10:51:23 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu v93EpMMl029357 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1507042283; bh=y228ovKg/HCwkAkSRF7XL0p+OBxwamcll1jcwroH3U4=; h=From:To:Subject:Date:From; b=cYUam60/Qdgobq6bKoAnegZTKYmYS6MPwxEwXplKtci1Dz12wIWc5qADMCQfcJAR6 W6+LCjt6h+CColHd+LUeqfscUSP82m2KzfHJ8hQaEsirDeZlq4TXOgujqSvDhO88Gb /Y4E1vZYSJ+6oLvXejRCVsCcm1IFwTUuZOoUZG1A= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v93EpIOM031949 for ; Tue, 3 Oct 2017 10:51:18 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Tue, 3 Oct 2017 10:51:18 -0400 From: Roman Danyliw To: "'dots@ietf.org'" Thread-Topic: Minutes from the October-02-2017 Virtual Interim Meeting Thread-Index: AdM8VrzmSj2Cd2oFQI2oXkHy1FYAHg== Date: Tue, 3 Oct 2017 14:51:17 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104FE35B8@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Minutes from the October-02-2017 Virtual Interim Meeting X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 14:55:53 -0000 Hello! Draft minutes from yesterday's (October 2, 2017) virtual interim meeting ca= n be found here: https://datatracker.ietf.org/meeting/interim-2017-dots-03/materials/minutes= -interim-2017-dots-03-201710021000/ Thank you to all who attended. If you have corrections to the minutes, ple= ase send them to the chairs. Regards, Roman From nobody Tue Oct 3 08:11:03 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF303134F57 for ; Tue, 3 Oct 2017 08:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tv8n8GKG_Wr6 for ; Tue, 3 Oct 2017 08:10:52 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE49134DD4 for ; Tue, 3 Oct 2017 08:04:06 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 6E28B120432 for ; Tue, 3 Oct 2017 17:04:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 52107180064 for ; Tue, 3 Oct 2017 17:04:04 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0361.001; Tue, 3 Oct 2017 17:04:04 +0200 From: To: "dots@ietf.org" Thread-Topic: Indefinite (-1) lifetime parameter value in a mitigation request Thread-Index: AdM8WNcDulXT2ZozSEqn/bTK8DUlxA== Date: Tue, 3 Oct 2017 15:04:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A04DB16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A04DB16OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Indefinite (-1) lifetime parameter value in a mitigation request X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 15:10:54 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A04DB16OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In reference to the comment raised by Flemming during the interim meeting a= bout the indefinite lifetime, I would like to remind that value was introdu= ced in the signal channel draft to adhere to this requirement from draft-ie= tf-dots-requirements: DOTS servers SHOULD support indefinite mitigation lifetimes, enabling architectures in which the mitigator is always in the traffic path to the resources for which the DOTS client is requesting protection. DOTS servers MAY refuse mitigations with indefinite lifetimes, for policy reasons. The reasons themselves are out of scope for this document, but MUST be included in the mitigation rejection message from the server, per SIG-005. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A04DB16OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 <= /p>

In reference to the comme= nt raised by Flemming during the interim meeting about the indefinite lifet= ime, I would like to remind that value was introduced in the signal channel draft to adhere to this requirement from draft-ietf-dots-re= quirements:

 <= /p>

&= nbsp;     DOTS servers SHOULD support indefinite mitiga= tion lifetimes,

&= nbsp;     enabling architectures in which the mitigator= is always in the

&= nbsp;     traffic path to the resources for which the D= OTS client is

&= nbsp;     requesting protection.  DOTS servers MAY= refuse mitigations with

&= nbsp;     indefinite lifetimes, for policy reasons.&nbs= p; The reasons themselves

&= nbsp;     are out of scope for this document, but MUST = be included in the

&= nbsp;     mitigation rejection message from the server,= per SIG-005.

 <= /p>

Cheers,=

Med

--_000_787AE7BB302AE849A7480A190F8B93300A04DB16OPEXCLILMA3corp_-- From nobody Wed Oct 4 01:34:57 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D63B13306A for ; Wed, 4 Oct 2017 01:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQvXN0T2GVXt for ; Wed, 4 Oct 2017 01:34:53 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53588133049 for ; Wed, 4 Oct 2017 01:34:53 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id DED37100520; Wed, 4 Oct 2017 10:34:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id BE5768007C; Wed, 4 Oct 2017 10:34:51 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0361.001; Wed, 4 Oct 2017 10:34:51 +0200 From: To: "dots@ietf.org" , "Jon Shallow (supjps-ietf@jpshallow.com)" Thread-Topic: Minimum heartbeat-interval Thread-Index: AdM866F1exiXOD0RS+2TvvngfvHPNA== Date: Wed, 4 Oct 2017 08:34:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A04DF59OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 08:34:55 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A04DF59OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A04DF59OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Jon made the following comment during the i= nterim meeting: “A: (Jon Shallow): The minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned wit= h RFC8085 which says the following:

 

   An application that needs to employ =
keep-alive messages to deliver
   useful service over UDP in the prese=
nce of middleboxes SHOULD NOT
        &=
nbsp;           &nbs=
p;            &=
nbsp;            ^^^=
^^^^^^^^^^^^^^^^^^^
   transmit them more frequently than o=
nce every 15 seconds and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   use longer intervals when possible.&=
nbsp;

 

I suggest to add this NEW text to the signa= l-channel draft to clarify the rationale for the recommended values:

 

NEW:

 &nbs= p;    Note: heartbeat-interval should be tweaked to also ass= ist DOTS

 &nbs= p;    messages for NAT traversal (SIG-010 of

 &nbs= p;    [I-D.ietf-dots-requirements]).  According to [RFC= 8085], keepalive

 &nbs= p;    messages must not be sent more frequently than once ev= ery 15

 &nbs= p;    seconds and should use longer intervals when possible.=

 &nbs= p;    Furthermore, [RFC4787] recommends NATs to use a state = timeout of 2

 &nbs= p;    minutes or longer.  From that standpoint, this sp= ecification

 &nbs= p;    recommends a minimum heartbeat-interval of 15 seconds = and a

 &nbs= p;    maximum heartbeat-interval of 240 seconds.  The r= ecommended value

 &nbs= p;    of 90 seconds is selected to anticipate the expiry of = NAT states,

 &nbs= p;    while avoiding overloading the network with frequent k= eepalives

 &nbs= p;    for NAT state maintenance purposes.  Note that th= is recommended

 &nbs= p;    value is close to the one recommended for MAX_TRANSMIT= _WAIT, whose

 &nbs= p;    value is derived from transmission parameters (Section= 4.8.2 of

      [RFC7252]).

 

Thoughts?

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A04DF59OPEXCLILMA3corp_-- From nobody Wed Oct 4 05:06:03 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D579E1332D4 for ; Wed, 4 Oct 2017 05:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSwP3EPPH_Dz for ; Wed, 4 Oct 2017 05:06:00 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 D3A97132355 for ; Wed, 4 Oct 2017 05:05:59 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dziR3-0004CX-6I; Wed, 04 Oct 2017 13:05:57 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 4 Oct 2017 13:05:57 +0100 Message-ID: <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06DC_01D33D11.84A6F930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFSg1IOmvyw/QR4DyHE01ic1cgMDKPU+61g Content-Language: en-gb Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 12:06:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06DC_01D33D11.84A6F930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was an off the cuff response, to handle the "broken" NAT timing implementations out there. The Heartbeat mechanism does raise a few questions in my mind which do need to be thought through. On a DOTS server, using a heartbeat interval of 15 secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4). Question 1 ========== Should the max-retransmit actually be 3, not 4 for CON requests so that we do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be in peace time) and heartbeats, not mitigation requests Question 2 ========= If the heartbeat interval is less than 91 seconds - say 60 seconds and the first heartbeat ping is still active, should a second heartbeat be fired off? - I think not, but the text then needs to get updated to state the interval is used whenever there is not a pending heartbeat response outstanding. Question 3 ========= Heartbeat checks are being initiated by the client. The client gets a heartbeat timeout on the session. The client subsequently needs to send a PUT mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 ========= Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 ========== When the heartbeats are initiated by the server, and the heartbeat times out, the session is "bad", but the current mitigation request continues until it expires. The client may have kicked off his heartbeats at a different time, and there likely will be a sending frequency drift over time, so the client may think the session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh the mitigation as it is about to expire or possibly another PUT for a different IP that has just started to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from the client's perspective) is an attack stopping traffic getting through and needs to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has heartbeat expired. The session contained all the negotiated PKI session keys etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace time. - I believe the session on the server needs to be kept hanging around for some time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer how to keep "bad" session hanging around] ========== Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the following: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the rationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med ------=_NextPart_000_06DC_01D33D11.84A6F930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mohamed,

 

In principal I agree = with your suggested updates – the minimum of 10s was an off the = cuff response, to handle the “broken” NAT timing = implementations out there. 

 

The Heartbeat mechanism = does raise a few questions in my mind which do need to be thought = through.  On a DOTS server, using a heartbeat interval of 15 secs, = with the client going away circa 10:54:30, I get

 

Oct 04 10:53:51 DEBG sending CoAP = ping:

Oct 04 = 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to retransmit queue = (2281ms)

Oct 04 = 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message = 29548

Oct 04 = 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending CoAP = ping:

Oct 04 = 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to retransmit queue = (2938ms)

Oct 04 = 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message = 29549

Oct 04 = 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending CoAP = ping:

Oct 04 = 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to retransmit queue = (2156ms)

Oct 04 = 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message = 29550

Oct 04 = 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending CoAP = ping:

Oct 04 = 10:54:39 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to retransmit queue = (2813ms)

Oct 04 = 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #1

Oct 04 10:54:42 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #2

Oct 04 10:54:48 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #3

Oct 04 10:55:00 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #4

Oct 04 10:55:23 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: give up after 4 attempts

 

Here we see the 91 = seconds (dependant on the max-retransmit value being 4) 10:56:09 – = 10:54:39.  There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 = before retry transmission #4).

 

Question = 1

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

Should the = max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON is only used for signal configuration = (infrequent, likely only to be in peace time) and heartbeats, not = mitigation requests

 

Question = 2

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

If the heartbeat = interval is less than 91 seconds – say 60 seconds and the first = heartbeat ping is still active, should a second heartbeat be fired = off?

- I think not, but the text then needs to get = updated to state the interval is used whenever there is not a pending = heartbeat response outstanding.

 

Question = 3

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

 

Heartbeat checks are = being initiated by the client.  The client gets a heartbeat timeout = on the session.  The client subsequently needs to send a PUT = mitigate request.

 

Does the client set up a = new session?

- Difficult as we are unlikely to be in peace = time

- PKI exchanges are likely to = fail

- the client just needs to send a = non-confirmable PUT.

 

Question = 4

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

 

Scenario as = Q3

 

Does the client re-use = the old session that the heartbeats are failing = on?

- The server may have sent a session close, but = it never got through

 

Question = 4

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

When the heartbeats are = initiated by the server, and the heartbeat times out, the session is = “bad”, but the current mitigation request continues until it = expires.

The client may have kicked off his heartbeats at = a different time, and there likely will be a sending frequency drift = over time, so the client may think the session is still active, the = server not, and the client decides it is time to send a non-confirmable = PUT to refresh the mitigation as it is about to expire or possibly = another PUT for a different IP that has just started to get hammered = – hence heartbeat failures. 

Alternatively the client = decides that the reason for “bad” session (from the = client’s perspective) is an attack stopping traffic getting = through and needs to do a PUT on the existing = session.

 

So server receives a PUT = (refresh or for a new IP) on a session that has heartbeat expired.  = The session contained all the negotiated PKI session keys etc.  = What should happen here?

- as the heartbeats are failing, it is safe to = assume we are not in peace time.

- I believe the session = on the server needs to be kept hanging around for some time post = heartbeat time-out. For how long?

- the server may be = seeing the client heartbeat messages [this may answer how to keep = “bad” session hanging around]

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On = Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: = 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow = (supjps-ietf@jpshallow.com)
Subject: [Dots] Minimum = heartbeat-interval

 

Dear all, =

 

Jon = made the following comment during the interim meeting: = “A: (Jon Shallow): The minimum for the = heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with RFC8085 which says = the following:

 

   =
An application that needs to employ keep-alive messages to =
deliver
   =
useful service over UDP in the presence of middleboxes SHOULD =
NOT
          =
            &=
nbsp;           &n=
bsp;           =
^^^^^^^^^^^^^^^^^^^^^^
   transmit them more frequently than once every =
15 seconds and SHOULD
 =
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^
   use =
longer intervals when possible. 

 

I = suggest to add this NEW text to the signal-channel draft to clarify the = rationale for the recommended values:

 

NEW:

      Note: heartbeat-interval should = be tweaked to also assist DOTS

      messages for NAT traversal = (SIG-010 of

      = [I-D.ietf-dots-requirements]).  According to [RFC8085], = keepalive

      messages must not be sent more = frequently than once every 15

      seconds and should use longer = intervals when possible.

      Furthermore, [RFC4787] = recommends NATs to use a state timeout of 2

      minutes or longer.  From = that standpoint, this specification

      recommends a minimum = heartbeat-interval of 15 seconds and a

      maximum heartbeat-interval of = 240 seconds.  The recommended value

      of 90 seconds is selected to = anticipate the expiry of NAT states,

      while avoiding overloading the = network with frequent keepalives

      for NAT state maintenance = purposes.  Note that this recommended

      value is close to the one = recommended for MAX_TRANSMIT_WAIT, whose

      value is derived from = transmission parameters (Section 4.8.2 of

      [RFC7252]).

 

Thoughts?

 

Cheers,

Med

------=_NextPart_000_06DC_01D33D11.84A6F930-- From nobody Wed Oct 4 14:21:14 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167311344CC for ; Wed, 4 Oct 2017 14:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT4HgIrkFQuS for ; Wed, 4 Oct 2017 14:21:09 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 87BD01344C9 for ; Wed, 4 Oct 2017 14:21:09 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dzr6J-0004Rw-0r for ietf-supjps-dots@ietf.org; Wed, 04 Oct 2017 22:21:07 +0100 From: "Jon Shallow" To: Date: Wed, 4 Oct 2017 22:21:06 +0100 Message-ID: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0725_01D33D5F.12A691D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1w== Content-Language: en-gb Archived-At: Subject: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 21:21:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0725_01D33D5F.12A691D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am having trouble with the DOTS Gateway implementation when primarily thinking about alias-names and filters. +----+ | c1 |\ +----+ \ +---+ \-----UDP-----| D |------UDP------+---+ +----+ | O | | | | c2 |--------UDP-----| T |------UDP------| S | +----+ | S | | | /-----UDP-----| G |------UDP------+---+ +----+ / +---+ | c3 |/ +----+ Non aggregated Question 1 ========= Does DOTSGW user a common PKI certificate for all 3 connections to S? If so, what happens when C1 POST an acl filter called filter-1. How does S know that it came from (is associated with) C1 as opposed to C2 or C3? Question 2 ========= What happens when C2 POST an acl filter called filter-1 - but it has a different definition to C1's version. How should DOTSGW (who knows it is associated with C2) and S handle this? Question 3 ========== C1 POSTs a filter filter-1. C2 POSTs a filter filter-2. C1 signals a mitigation request. How does S know whether to invoke filter-1 or filter-2 or both for this mitigation request? +----+ | c1 |\ +----+ \ +---+ \-----UDP-----| D | +---+ +----+ | O | | | | c2 |--------UDP-----| T |------UDP------| S | +----+ | S | | | /-----UDP-----| G | +---+ +----+ / +---+ | c3 |/ +----+ Aggregated. DOSTGW has to use a singular PKI Certificate for the DOSTGW to S session, so there cannot (easily) be 3 different certificates. The same 3 questions as the non-aggregated still stand. S somehow needs to know which Client is issuing the information. There potentially needs to be some sort of NAT translation equivalent taking place as information is sent from the Clients to the Server and untranslated on the way back. So for example, an alias definition alias-1 from C1 perhaps needs to be prefixed with c1- by DOTSGW (i.e. c1-alias-1) before passing it on to S and then a signal mitigation request from C1 referring to alias-1 needs to be changed to c1-alias-1 - and when a GET mitigation status is done the S response with c1-alias-1 needs to be changed back to alias-1 by DOTSGW before sending it on to C1. If there are a large number of DOTSGW in the chain, the NAT'd name can get large - especially if the pre-pended text is the certificate common name / altSubjectName. This is not really scalable. Another suggestion is that as well as the PKI mutual authentication taking place, there is support for an additional client identifier in the protocol that the DOTSGW can use to add into the DOTSGW to S session. For the signal channel, it could be at the mitigation-id or session-id level - e.g. "client-id" : "string". It could also be "client-id" : "string" at the alias-name level in the data channel for "ietf-dots-data-channel-identifier:identifier". For the data channel access-control-list, draft-ietf-netmod-acl-model-14 (just released) has just introduced a new container "interfaces" sitting at the same level as list "acl" under container "access-lists". Interfaces have a list of (sortable) ACLs (taken from 'list acl') associated with them (which separately is a way of working around the ACL sorting issue raised at the virtual meeting) . The interface-name could be the "client-id" string and so S has a list of interfaces, one per actual client. The use of a client-id would help in the directing of any traffic from S to the appropriate Cn. There is a possibility of client-id name clashes though with more than one DOTSGW in the C -> S chain. Suggestion / Ideas / Solutions welcome. Regards Jon ------=_NextPart_000_0725_01D33D5F.12A691D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am = having trouble with the DOTS Gateway implementation when primarily = thinking about alias-names and filters.

 

   =
 +----+
  =
  | c1 |\
 =
   +----+ =
\            =
  +---+
 =
           \-----U=
DP-----| D |------UDP------+---+
   =
 +----+          &=
nbsp;     | O =
|            =
   |   |
    | c2 |--------UDP-----| T =
|------UDP------| S |
   =
 +----+          &=
nbsp;     | S =
|            =
   |   |
  =
          /-----UDP----=
-| G |------UDP------+---+
    +----+ =
/            =
  +---+
    | c3 =
|/
   =
 +----+

 

Non = aggregated

 

Question 1

=3D=3D=3D=3D=3D=3D=3D=3D=3D

Does DOTSGW user a common PKI certificate for all 3 = connections to S?

 

If so, what = happens when C1 POST an acl filter called filter-1.  How does S = know that it came from (is associated with) C1 as opposed to C2 or = C3?

 

Question 2

=3D=3D=3D=3D=3D=3D=3D=3D=3D

What happens when C2 POST an acl filter called = filter-1 – but it has a different definition to C1’s = version.  How should DOTSGW (who knows it is associated with C2) = and S handle this?

 

Question = 3

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

C1 POSTs a filter filter-1.  C2 POSTs a filter = filter-2.  C1 signals a mitigation request.  How does S know = whether to invoke filter-1 or filter-2 or both for this mitigation = request?

 

 

 

    &nbs= p;   +----+

    &nbs= p;   | c1 |\

    &nbs= p;   +----+ = \            =   +---+

    &nbs= p;           = \-----UDP-----| D = |            =    +---+

    &nbs= p;   = +----+           &= nbsp;    | O = |            =    |   |

    &nbs= p;   | c2 |--------UDP-----| T |------UDP------| S = |

    &nbs= p;   = +----+           &= nbsp;    | S |        =        |   = |

    &nbs= p;           = /-----UDP-----| G = |            =    +---+

    &nbs= p;   +----+ = /            =   +---+

    &nbs= p;   | c3 |/

    &nbs= p;   +----+

 

Aggregated.

 

DOSTGW has = to use a singular PKI Certificate for the DOSTGW to S session, so there = cannot (easily) be 3 different certificates.

 

The same 3 = questions as the non-aggregated still stand.  S somehow needs to = know which Client is issuing the information.

 

There = potentially needs to be some sort of NAT translation equivalent taking = place as information is sent from the Clients to the Server and = untranslated on the way back.

 

So for = example, an alias definition alias-1 from C1 perhaps needs to be = prefixed with c1- by DOTSGW (i.e. c1-alias-1) before passing it on to S = and then a signal mitigation request from C1 referring to alias-1 needs = to be changed to c1-alias-1 – and when a GET mitigation status is = done the S response with c1-alias-1 needs to be changed back to alias-1 = by DOTSGW before sending it on to C1.

 

If there are = a large number of DOTSGW in the chain, the NAT’d name can get = large – especially if the pre-pended text is the certificate = common name / altSubjectName.  This is not really = scalable.

 

Another suggestion is that as well as the PKI mutual = authentication taking place, there is support for an additional client = identifier in the protocol that the DOTSGW can use to add into the = DOTSGW to S session.  For the signal channel, it could be at the = mitigation-id or session-id level – e.g. “client-id” : = “string”.  It could also be “client-id” : = “string” at the alias-name level in the data channel for = "ietf-dots-data-channel-identifier:identifier".  For the = data channel access-control-list, draft-ietf-netmod-acl-model-14 (just = released) has just introduced a new container “interfaces” = sitting at the same level as list “acl” under container = “access-lists”.  Interfaces have a list of (sortable) = ACLs (taken from ‘list acl’) associated with them (which = separately is a way of working around the ACL sorting issue raised at = the virtual meeting) .  The interface-name could be the = “client-id” string and so S has a list of interfaces, one = per actual client. 

 

The use of a = client-id would help in the directing of any traffic from S to the = appropriate Cn.

 

There is a = possibility of client-id name clashes though with more than one DOTSGW = in the C -> S chain.

 

Suggestion / = Ideas / Solutions welcome.

 

Regards

 

Jon

------=_NextPart_000_0725_01D33D5F.12A691D0-- From nobody Wed Oct 4 14:37:19 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565F8133073 for ; Wed, 4 Oct 2017 14:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 btZ9CHv85drR for ; Wed, 4 Oct 2017 14:37:16 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0139.outbound.protection.outlook.com [104.47.36.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28AB1323B4 for ; Wed, 4 Oct 2017 14:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=arhDQy1GEMZIKx25FUynesTQq1FXKsNTuMcc036LQjo=; b=KHCu1fVn7hh9vRJWoQqgQkwi/0bEvOyMCzX+qNl9x8OMpRYOp/uzCsI9hX+2XJbf+kzzi9LzwI8KB/0Nh8krqnChO7DvIlseZ2MPs/eOBY3uAdCTR4x+GMjAg3ScKvYGtry+2U60lF3E2snKzIDQ8VZ7589n+FQkjx4an/+xkQE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.21.0.27] (205.185.192.236) by BN3PR0101MB1026.prod.exchangelabs.com (10.160.182.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 4 Oct 2017 21:37:12 +0000 From: "Roland Dobbins" To: dots@ietf.org Date: Thu, 05 Oct 2017 04:37:04 +0700 Message-ID: <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> In-Reply-To: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.7r5419) Content-Type: text/plain X-Originating-IP: [205.185.192.236] X-ClientProxiedBy: BN6PR14CA0016.namprd14.prod.outlook.com (10.173.157.154) To BN3PR0101MB1026.prod.exchangelabs.com (10.160.182.155) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 12c7d870-7a6e-4c6a-1afb-08d50b7013ca X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0101MB1026; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 3:l6K1jsm74ki4rmgddyDWmZF9i5rOJY0UBfhKGnxtgLtLEkXenOgDFfMsDXVwAklhimOjB0obV3NeagYldg+XZ11IcpxtBJN9c9Ml/bPBT3CjX1gIz/zlA3J/HHBjd6Pqq6UcYsww/+pjNapw9RJEi/CHpgSYNHOl/QPzPz/ye0uB/OxTqSiAm9Vrnk3bfeQ91HZSKPV7WIM59ogA5RcN/S8Csux67NKqEYFDMG/WVLKkNap8ZFNUzLXkfug11xVs; 25:48HpEvI24R86/qEiumf2S+PPMU0qFR1sEKP3q2BMtBR6Fx1ZsoAv+a7Qd55eQAUt7KiS0UcgJ4rdjbWbu5UI+2qS6Pn0K3KUishUQXXDlEKdFBsOTfRlEoEVJGwZAfvPAohUp40L5sds18uS5QD1nQHaSF3VFUqyYfx1P+dias6tx9Z9YRvWqXqzRPl024+ukyaZcFFvTqDTACXaJvbNSF2kqu6KY77YBd2ZvSbV785oPatDe+lk50UYe0QP9HJ8NktOYA7Bhi+BLCZrf6O7JKYtS8btPePlAUYHuMlcrcMLAItX1puzvfJaCqNpuAOMveLFS52Xcwfn3DANfKKbJw==; 31:tlt1mWZmXSELzdtVRIenY/9tNRuDwlvjNBdAWtakAZrb0mdt3sU/G1TasXtqPKMt19WPhGer7nDZl99aaSf9XqwQl033cbm9ddFxU4pqxGcaW8JD0ZFTx5jBNxvlL3vJ6hL39pPTqSStVbio0c51fKNUGGTUSe15y96lDYnw7x4zRRFMQFDJFuYGPeAWhSmxOCucZlGG8Wv+FBohlQOIRe2TfLx+QKlDVrpr/G1d1pU= X-MS-TrafficTypeDiagnostic: BN3PR0101MB1026: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 20:N6zKY0fKmvBJNCRVlJxeVKalsQe73LnfFF/ZKYkAitGByKI1OHcUCumcqoZwEOupWquTMRRomODQmwRtGIKbs9mQtJnY7OGEXQp03CR3J9v2ALZf1lOJM0Tv5q4L94HoF1aprRkwmoHTIQgUkmrQQugjUtRC1lLFBR39k+7HG+r16+KzO1M/5qRK/V36iUaUMcI8rnSHxO8YjoE9nrgwVBpi/YPD1YKF2Q90gZMViw6eI6KQrX3pd+bOFjaUSTymV++DOU13pm1O44PTedXkIrpVe8oyfdP9XyedChufiPK64738hFutoharlgbwxr+P5MTTCrDiuhtizSHZGIrMfDPxIUve8eHAwtcUTaq3OotD2hk7sv/ZMU7JJfd4drbpxE5/siIrx68cGfmdY78oFEAgB482geCx6QjNW6ZB8GTPOeKl0so24dsnyUMqMpSCAPWtLP+mmNN3pQdpaJHsVB0kADziqg4YDAQwOqK5DWlNVRXjXVyCyTh4YRWou82A; 4:vOEesCHZqNjE1rQk/OseEnph1XKod3cX7qv1COGTt55odGE3QcKRp0JMberKoWw49qamoB0ZuPoi6a/Ez9ZrwAHgAReVeYaPLL5bwoNfvljYDJ3HjNeZtKd1nQub92T/PsmGUlTB3thdoxObaf04KxH4aBeDxrWElDfSkhJhu2EG8j8xa+eXkdJCuubdsFfpC/EjrR/6dTFFkn6QjRNXAB7225c3TiAIkQX9QJ8s8hVbEUTGe5eiQeqX4yfWL6pb X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0101MB1026; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0101MB1026; X-Forefront-PRVS: 0450A714CB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(346002)(376002)(189002)(199003)(24454002)(189998001)(6916009)(105586002)(305945005)(86362001)(47776003)(53936002)(106356001)(8676002)(101416001)(5003940100001)(2351001)(81166006)(6666003)(81156014)(97736004)(7736002)(50226002)(83716003)(3846002)(33656002)(76176999)(50986999)(8936002)(2361001)(50466002)(5660300001)(66066001)(6246003)(36756003)(558084003)(478600001)(82746002)(2906002)(6486002)(25786009)(48376002)(16576012)(16586007)(6116002)(90366009)(53546010)(77096006)(2950100002)(316002)(229853002)(68736007)(16526018); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1026; H:[172.21.0.27]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0101MB1026; 23:e+nu1z6nKEnGkU/IrerlUt5iKkIxK5WGdqu9w2f?= =?us-ascii?Q?mrKQN5F+IzJ5ezKbUg6m4cmdrx9BHfKkYoPurlKmSekh2a5uFQmSZU3uq8gg?= =?us-ascii?Q?2nYyrdBoOI/ElBzwL0sqe3+q7KMBUbn+3rRn1l6zQYxjtsvmlAcgFbqsAtH/?= =?us-ascii?Q?vrNZl1qXzjQyYy18Hsn+j6Yn7SGVphifMB3WxVMEROW6wcfXgLK+7w1axe2L?= =?us-ascii?Q?IBZ8RfxHKylLHCZvMlaq6vB8M398HgypXukb6wU9VMilPVGv0/k0Dwn0aWAC?= =?us-ascii?Q?MArb//yrI60l+MBA+BfkYns7lJ9FZKSn37RSKZYwGJpL2kKFOCtpypZQSNAu?= =?us-ascii?Q?76ZMOhSPRZbPVe2R3CMfWuIUd/HAxOjSwbVGaPIhZWWFnp+MLRRDXdpRWVBD?= =?us-ascii?Q?bawrsor4tWixvod/n7wTcHkgnhoBGHA94RuhOeeCwCYIFnw02YmNZK68o3aK?= =?us-ascii?Q?JFVgQVztZplPK3UOzIc889GFMK8MS5uJubOvLdTny/zDV0zwdS02b+d/iIoZ?= =?us-ascii?Q?8jdOeZiQf2nXtt0Oi3sFAZaxjes0qRbi7GbTsnPvc2rgu8O/TwuVOIIyjZd7?= =?us-ascii?Q?ynNPg4mGcHfqgro6RiSS/Zih89qJYMtENA+nWUhuTdqzlmSa8WH8eFo9nR78?= =?us-ascii?Q?txwwZrw+1W6OHBlhHLOAY4bxTZ0xNVjw5OKepCHewpynYnYFTAKLCPwSYEkJ?= =?us-ascii?Q?iKoJ2eHLSgxYELd+ohmTjo5hHkwUK0kVavj/lhrrwAjZ1iSQ9KThRSwF8dJv?= =?us-ascii?Q?i/UOdiEWRCiDJCCDQWeLmt0eQpzvvu5gmVfpWGXYYt3aJz/q5C36JsCNEQ2J?= =?us-ascii?Q?/agJ15jVCUuTS1bcwU1LkogfMS/K5eR1pWuBE1YbWRZEt8hmlkhU7qmWYy9D?= =?us-ascii?Q?TkwRSOR+MtxPHV13CLwNbmAJa0r/fssC0tq3UKAUYDQvkufVOBlvhr8yr6GE?= =?us-ascii?Q?PfZso9GZQl9zvgUDhRTh9zb/vI2nj+Hr9JSFP/IQE8iXypPqmPPEEHFzWAQX?= =?us-ascii?Q?mUxU9SYqzWF1LvjbHEazVAAS9L2Hoxsi7OjQi1a4qBFaX70ZXRaqmfjY5RhS?= =?us-ascii?Q?NNDJW2uPo+y5K8bG/SNDyxHOFUjSxGEoCDGT4MIkQC1Tq+tgHriL4bjvtHVE?= =?us-ascii?Q?rr37rr5m1v2IazqFq9LuuDNr8A2UNmMvWJi49icKQLdnqXiiyYtdtc/bEvdy?= =?us-ascii?Q?rUa3jRx5LJlocoNqJJKymneueC+Y2YWmUFktSD7mTbkhkS0QymfrQ65XswDw?= =?us-ascii?Q?myF8+ACVitN1ixOAUgaNMi8tyC1sFVvQ2Hv2JtMJ6?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0101MB1026; 6:W1KApSYw6dHuPtNCejMfC5gnv4cbYzz78P2XUPEvEHQL1dYOZGKb9qVnsVi7GFQJ+YQxb9YAaRfgH7NWxvn87TE2wvgFPlp6L7KQ6Xlnp4F/xTsEwK9RClbx7fjPi5C5ug+jCIgM7un9o5JdQmWMk2RBLQOuSUqlMaJfWDRWsV15bTIIo/VWgglFVb63/pPlx0iftfBCz9oniiRQT7Xkpyf47gzY1yGz8C4WsnIHlI2TRye1LCTD0JoO+XrU6ajTsSbeXqorE1WQtTs8NdTnaViaYEj0ShVB8BhVm52X4Lc20vyQuocY7nFnI6Ugiou8W2N2XZT/fOnpafh474Pdtw==; 5:bkrT3eIqWFL7qiU8AXuTN7FXCfyENqByY8X1cVB1jDVozC/tN+GKdXeO6svXzLGvmSvyOiqCJGPLinkvTPSC0wUcnT6ch587vWIb8YhxwjGsbfHgFro8cj0cK9IVn7ynJk22XB0HdQWRU4BUzJ7W8A==; 24:tqzIK3DLx5GrAEktvTJ6fYfu8ftz+yJpvYiATJ2QuttyqRkTNDfyurjM/cKYl2GOY7dew/oP9am1iWH58an2Q/hQTSmkHt66GBfji9mi9Hc=; 7:Wnsk1xzVY0kOjdUxtLaNGUoGUNnojQm7uXSriHWebSbwIBD81g7UG4PMJuM9Kns8OFqlxVwAMxicX/ah5GxHeTty81MgeTxueoyrxCUaZwszFJQqblRIgiU9IMQJyWc0vDnMmKsSkafR08T9gWdocaxdu4e8Z7Fw2idgNhNhWJaWU6Lgp4Ea3Mvem56QRbTSiaDP11yS2FDwt5QBMsd9Tr1WN24pVRGYd/S/aXtNTvA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2017 21:37:12.7654 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1026 Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 21:37:17 -0000 On 5 Oct 2017, at 4:21, Jon Shallow wrote: > The use of a client-id would help in the directing of any traffic from S to > the appropriate Cn. This is already present, is it not? ----------------------------------- Roland Dobbins From nobody Thu Oct 5 00:58:20 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B47132331 for ; Thu, 5 Oct 2017 00:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOpoqMOeTMYm for ; Thu, 5 Oct 2017 00:58:16 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 3753B133070 for ; Thu, 5 Oct 2017 00:58:16 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e012r-0004qh-1Q; Thu, 05 Oct 2017 08:58:13 +0100 From: "Jon Shallow" To: "'Roland Dobbins'" , References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> In-Reply-To: <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> Date: Thu, 5 Oct 2017 08:58:13 +0100 Message-ID: <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_075F_01D33DB8.13BDD0C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuoyXw+SA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 07:58:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_075F_01D33DB8.13BDD0C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Roland, Perhaps "original-client-id" would be a better name - in a similar sort of way that the "X-Forwarding-For:" header provides the original IP making the HTTP request when passing through a load-balancer or SSL terminator. +----+ | c1 |\ +----+ \ +---+ \-----UDP-----| D | +---+ +----+ | O | | | | c2 |--------UDP-----| T |------UDP------| S | +----+ | S | | | /-----UDP-----| G | +---+ +----+ / +---+ | c3 |/ +----+ The DOTSGW'Server (G'S) does know the client-id of C1, but in the connection DOTSGW'Client (G'C) <-> S this is not (currently) passed on. When traffic from S when received at G'C (e.g. unsolicited Observe status change), this has to be looked up in DOTSGW to work out which Cn G'S is going to send it on to. Having the (original)-client-id in the G'C <-> S communication helps the lookup on G. For example, the lookup (for unsolicited Observe status change)is based on the COAP TAG in the message - but if both C1 and C2 have used the same TAG id in their GET with Observe set request then either the TAG has to be 'NAT' when forwarded on somehow to make sure the response goes back to the correct client, or the additional key is (original)-client-id. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roland Dobbins Sent: 04 October 2017 22:37 To: dots@ietf.org Subject: Re: [Dots] DOTS Gateways Challenges On 5 Oct 2017, at 4:21, Jon Shallow wrote: > The use of a client-id would help in the directing of any traffic from > S to the appropriate Cn. This is already present, is it not? ----------------------------------- Roland Dobbins < rdobbins@arbor.net> _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots ------=_NextPart_000_075F_01D33DB8.13BDD0C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Roland,

 

Perhaps "original-client-id" would be a = better name - in a similar sort of way that the = "X-Forwarding-For:" header provides the original IP making the = HTTP request when passing through a load-balancer or SSL = terminator.

 

        = +----+

        | c1 = |\

        +----+ = \            =   +---+

           &= nbsp;    \-----UDP-----| D = |            =    +---+

        = +----+           &= nbsp;    | O = |            =    |   |

        | c2 |--------UDP-----| = T |------UDP------| S |

        = +----+           &= nbsp;    | S = |            =    |   |

           &= nbsp;    /-----UDP-----| G = |            =    +---+

        +----+ = /            =   +---+

        | c3 = |/

        = +----+

 

The = DOTSGW'Server (G'S) does know the client-id of C1, but in the connection = DOTSGW’Client (G'C) <-> S this is not (currently) passed = on.

 

When traffic from S when received at G'C (e.g. = unsolicited Observe status change), this has to be looked up in DOTSGW = to work out which Cn G'S is going to send it on to.  Having the = (original)-client-id in the G'C <-> S communication helps the = lookup on G.

For example, =  the lookup (for unsolicited Observe status change)is based on the = COAP TAG in the message - but if both C1 and C2 have used the same TAG = id in their GET with Observe set request then either the TAG has to be = 'NAT' when forwarded on somehow to make sure the response goes back to = the correct client, or the additional key is = (original)-client-id.

 

Regards

 

Jon

 

-----Original = Message-----
From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Roland Dobbins
Sent: 04 October 2017 22:37
To: = dots@ietf.org
Subject: Re: [Dots] DOTS Gateways = Challenges

 

On 5 Oct 2017, at 4:21, Jon Shallow = wrote:

 

> The use of a client-id would help in the = directing of any traffic from

> S to the appropriate Cn.

 

This = is already present, is it not?

 

-----------------------------------

Roland Dobbins <rdobbins@arbor.net= >

 

_______________________________________________=

Dots mailing list

Dots@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/dots

------=_NextPart_000_075F_01D33DB8.13BDD0C0-- From nobody Thu Oct 5 02:43:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45B8134571 for ; Thu, 5 Oct 2017 02:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 lqL7w9rfWLTG for ; Thu, 5 Oct 2017 02:42:59 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0124.outbound.protection.outlook.com [104.47.41.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BCC134564 for ; Thu, 5 Oct 2017 02:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0sjIN9Qlfs9t3jKtByDdDcROBIIDUBsAzh/4+KsT3og=; b=ocvs2qmPiiXnz0kD4kfmDft+8jMCkSGu/429qqsrLduz8+nMJmIxc1PZ2Lw/Ktf5+sLHYI7xWvRxOEN/7zr4MUm4lPp7XWk1pEPj46ES1m9M0Bfp+0jd//lYSHzXH4pCZHoSTq6FTibT0yewwNXjXV0d39kdxt4h9Df0BhuhzlA= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1037.prod.exchangelabs.com (10.160.129.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 5 Oct 2017 09:42:10 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::f4d3:7c95:465c:e5b]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::f4d3:7c95:465c:e5b%15]) with mapi id 15.20.0077.018; Thu, 5 Oct 2017 09:42:10 +0000 From: "Dobbins, Roland" To: "dots@ietf.org" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAPOhQAAAcGbIAAA6FpPg== Date: Thu, 5 Oct 2017 09:42:10 +0000 Message-ID: <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> In-Reply-To: <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; x-originating-ip: [184.82.237.231] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1037; 6:ZQnm57eMZhcpOuiyo9AjARymV17/OW/eulAbqgNYH8K5H4+5CmhTkim2lL4FtsNO67Ql/dp3uZPuRIzISEtP7VX1s8gB9T0HDRz5c9gPAAo10cGo6OSRuDnlRQ2jXZvt1LGWEayOyIH6gm4uCw0Qqp0ePCUlowfO9ovwNUPJiAUgFZGwjt0tbYUMqNQG50f3pxPj2wi3svq9aUBmhhnG2RDnGumrlMJ5XMNx/f0g/XKebffD0TNS5LEDSm4j1oacpXInlYqKSLSRHz0wQMg6YwLtSvXQMaJvJhjrQFHTTEgwdDnUNl+YViy9dOcLpia3jwFPtaXiQEbviM0x58gMsQ==; 5:2t1uSN5WZbUu6xZ6cCps+5TD3qOlH+xui+IQ0YpwMF+7SLJGpLTN+Js9W6ueFhkxacXV5WMqs5RXSSFKfOPhBWlZmLADomazsfgk2IECshY9SRj1X/zi5cPbN6tvLE4NRjYICRtHh3PQLAtSceW3Xw==; 24:RIFVEXU+R2/bNo6recX/xkP6Gim67BU2Tn958vApVwKdQ96c9RbA+Vp/L4lBojKlCdeuHnLc8CdARDJRzqXGIwyKrBd+GVxkZiEm/9ocw+w=; 7:ABxgTuKPH714Zf+uHzlnaJjRZAP/4dhgTYW4b1LAN1aVvQOXwkTJPKW9PTBwTNtrMqnmlG3m9vHWUBa7Rs9jDTV1WcQhv8UQkhYCKLtrZ9i+w5I8DNMIXoNt9Jp//e2XjK5c9DfzrC5npqgBj9V6ZvZlD3X0paSj4QNuG+hUiNeQoKAUib/N4f8B/jKfl6s2Cg4LOXaqmabTs1IjwoqplKgXqFp58w3m1wWnQ448ZLQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9f69ba6f-5e64-439d-e7e1-08d50bd559ba x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR0101MB1037; x-ms-traffictypediagnostic: DM2PR0101MB1037: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; x-forefront-prvs: 04519BA941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(189002)(199003)(24454002)(25786009)(53546010)(2950100002)(33656002)(82746002)(6486002)(189998001)(8676002)(6506006)(236005)(5250100002)(99286003)(83716003)(229853002)(53936002)(6246003)(6512007)(2501003)(478600001)(3660700001)(86362001)(54896002)(2351001)(316002)(97736004)(2900100001)(14454004)(6916009)(5660300001)(8936002)(5640700003)(50986999)(68736007)(2906002)(101416001)(102836003)(7736002)(3280700002)(66066001)(6436002)(3846002)(6116002)(1730700003)(76176999)(81156014)(81166006)(106356001)(54356999)(36756003)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_4A4C5D6AB63F40B48772AD0B1E79F8D6arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2017 09:42:10.3513 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 09:43:02 -0000 --_000_4A4C5D6AB63F40B48772AD0B1E79F8D6arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIE9jdCA1LCAyMDE3LCBhdCAxNDo1OCwgSm9uIFNoYWxsb3cgPHN1cGpwcy1pZXRmQGpw c2hhbGxvdy5jb208bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20+PiB3cm90ZToNCg0K UGVyaGFwcyAib3JpZ2luYWwtY2xpZW50LWlkIiB3b3VsZCBiZSBhIGJldHRlciBuYW1lIC0gaW4g YSBzaW1pbGFyIHNvcnQgb2Ygd2F5IHRoYXQgdGhlICJYLUZvcndhcmRpbmctRm9yOiIgaGVhZGVy IHByb3ZpZGVzIHRoZSBvcmlnaW5hbCBJUCBtYWtpbmcgdGhlIEhUVFAgcmVxdWVzdCB3aGVuIHBh c3NpbmcgdGhyb3VnaCBhIGxvYWQtYmFsYW5jZXIgb3IgU1NMIHRlcm1pbmF0b3IuDQoNClRoaXMg aXMgaG93IGl0ICptdXN0KiB3b3JrLCBhZ3JlZWQ7IEkgcmVtZW1iZXIgZGlzY3Vzc2luZyB0aGlz IHRvcGljIGF0IG9uZSBvZiB0aGUgV0cgbWVldGluZ3MsIHNwZWNpZmljYWxseS4NCg0KSWYgaXQg c29tZWhvdyB3YXMgZHJvcHBlZCwgd2UgbmVlZCB0byBmaXggaXQuICBHYXRld2F5cyBhcmUgYSBu ZWNlc3NhcnkgaW5pdGlhbCBjYXBhYmlsaXR5LCBhcyBpcyBwcmVzZXJ2aW5nIERPVFMgY2xpZW50 IElEcyBhY3Jvc3MgdGhlbS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9y Lm5ldD4+DQo= --_000_4A4C5D6AB63F40B48772AD0B1E79F8D6arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gT2N0IDUsIDIwMTcs IGF0IDE0OjU4LCBKb24gU2hhbGxvdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpw c2hhbGxvdy5jb20iPnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj5QZXJoYXBzICZx dW90O29yaWdpbmFsLWNsaWVudC1pZCZxdW90OyB3b3VsZCBiZSBhIGJldHRlciBuYW1lIC0gaW4g YSBzaW1pbGFyIHNvcnQgb2Ygd2F5IHRoYXQgdGhlICZxdW90O1gtRm9yd2FyZGluZy1Gb3I6JnF1 b3Q7IGhlYWRlciBwcm92aWRlcyB0aGUgb3JpZ2luYWwgSVAgbWFraW5nIHRoZSBIVFRQIHJlcXVl c3Qgd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBsb2FkLWJhbGFuY2VyIG9yIFNTTCB0ZXJtaW5hdG9y LjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPGRpdj5UaGlzIGlzIGhvdyBpdCAqbXVzdCog d29yaywgYWdyZWVkOyBJIHJlbWVtYmVyIGRpc2N1c3NpbmcgdGhpcyB0b3BpYyBhdCBvbmUgb2Yg dGhlIFdHIG1lZXRpbmdzLCBzcGVjaWZpY2FsbHkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5JZiBpdCBzb21laG93IHdhcyBkcm9wcGVkLCB3ZSBuZWVkIHRvIGZpeCBpdC4gJm5ic3A7 R2F0ZXdheXMgYXJlIGEgbmVjZXNzYXJ5IGluaXRpYWwgY2FwYWJpbGl0eSwgYXMgaXMgcHJlc2Vy dmluZyBET1RTIGNsaWVudCBJRHMgYWNyb3NzIHRoZW0uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1 LCAwKTsiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQt dmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08L3NwYW4+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQt dmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyI+DQo8L3NwYW4+DQo8ZGl2IHN0eWxlPSJmb250LXZhcmlh bnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZv bnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+DQo8c3Bh biBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPlJvbGFu ZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmlu c0BhcmJvci5uZXQ8L2E+Jmd0Ozwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_4A4C5D6AB63F40B48772AD0B1E79F8D6arbornet_-- From nobody Thu Oct 5 03:54:28 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9352313214D for ; Thu, 5 Oct 2017 03:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 flh6ENqig8bL for ; Thu, 5 Oct 2017 03:54:24 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 7B7DF134226 for ; Thu, 5 Oct 2017 03:54:24 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507200863; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=7 CnJHCkLyBVff6mhTQ32P/zFf0jFHGgT8EPcAnwq84 E=; b=hLiJ96cxf0UtuFvbgY3b6Y0VmEPw2tlJFO8jYb5F3X4T LoYLkxHGq/PzVS0uxyiZ6jOoD5mZg7939gPgxYOCL3R9guPZ7O IMhspu9VU4OK45LeN0eiv75a4QZTLruEhOUtV1kewx/WTLRkkk l3TXipFvF0lr1nlO8FGqrzo38aI= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 0625_df56_80d6229a_4113_4b2d_9919_b74a146757e7; Thu, 05 Oct 2017 05:54:22 -0500 Received: from MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Oct 2017 06:54:19 -0400 Received: from MIVEX10N02.corpzone.internalzone.com (10.48.48.170) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 5 Oct 2017 06:54:19 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEX10N02.corpzone.internalzone.com (10.48.48.170) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 5 Oct 2017 06:54:19 -0400 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Oct 2017 06:54:18 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 5 Oct 2017 10:54:17 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.018; Thu, 5 Oct 2017 10:54:17 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AdM866F1exiXOD0RS+2TvvngfvHPNAAHYE+AAC3w14A= Date: Thu, 5 Oct 2017 10:54:17 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> In-Reply-To: <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:IB7uc3+v2eO9M+ilXesoquToMiQbfxYWubUoe+iLRUZX6EflMSm8zlYVM07gpJxiIUyhi1fSu78WjBtIfqB1AAfPyzpocSOzQJmA7pR0iGeLcorvQSpNcSFcu7G6eUPyFEPMOVsLKqNaNUNq8pdJil7Fs53YsrnXC3niyiZeu1CZeO6/mL1qVDSkeQHwfsv0S8GHE7e+Tfm+yAJeA2ykcn/FMf+BnDvGREi2WSI43hHn5+ijTb1FKQyRe47OOgBtghnPNdGipeyQiZF3uY8QpmEgh01QUX9TYvY8xLO9gvZL2+Dv1kwqAps/xMB1ytp449uP41wQf2BThzL3aSCWcQ==; 5:9xf1t/yIQBi6dIaUQv4I7HSWpZaa7W0kJVzTn+hQqzUxx6x4ZAELo+SbA9vueTdC1I99q0KEa4yaaKdIKTeHkdb1Pi2w24iyzeUl3cpY/uO3uedI2Potgzt0HN831Dj/U6jIEd6109XqKL8P/H/fnQ==; 24:5zOuTbDthp8WFj5sOxXEZk2xgfzUiiBHhRxjB3nKw053Klr1nOHq6eTqn4CplZbaLijEybngc7JKgO3uXtb/w3XjLpDqYt4SWuJimZUfLTg=; 7:K/zl4KlyvHyjh29suOgUWYqJ6YaEdpo8c5Gt2F6eTUtZeSpxQS4HyulwBVY0tznkgJiftMQo4cQODeKxEc2siVfj9jHpQcv6ispyHAqB5tHpYV+L/oqwiZUkKv6UwwCARP40tcuntEzHKeC9v2wbiVX7OndF1fdlQJYqIaElCoh9fiDMcHw7NP7Ukj8SDmezQc4BH/X+SIFv9GrWenDbcg15In4A1Vusetm8ZysJs1M= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 85899fe7-1b63-4582-d332-08d50bdf6d18 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 04519BA941 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(199003)(189002)(32952001)(377454003)(6246003)(101416001)(25786009)(2900100001)(2201001)(7736002)(33656002)(54896002)(189998001)(6306002)(6436002)(55016002)(229853002)(8936002)(81156014)(105586002)(99286003)(236005)(86362001)(74316002)(66066001)(81166006)(77096006)(6506006)(8676002)(53936002)(106356001)(19609705001)(2950100002)(5660300001)(478600001)(68736007)(966005)(110136005)(9686003)(102836003)(7696004)(80792005)(790700001)(14454004)(606006)(6116002)(2501003)(54356999)(3660700001)(53546010)(316002)(3280700002)(2906002)(97736004)(3846002)(72206003)(76176999)(50986999)(85282002)(562404015); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178840D669DC98700AC08731EA700DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2017 10:54:17.7499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6129> : inlines <6109> : uri <2511571> Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 10:54:27 -0000 --_000_DM5PR16MB178840D669DC98700AC08731EA700DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). 2) No, if the DOTS agent wants to change the default heartbeat interval the= n the other message transmission parameters will also have to be modified. 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med --_000_DM5PR16MB178840D669DC98700AC08731EA700DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html= /rfc7925 has tested NAT behavior with various routers and lists the tim= eout results. The majority of the devices (62%) have a timeout between 2 an= d 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is = 54 seconds.

 

Responses to the questions below

 

1) The max-retransmit parameter is negotiable and configurable,&nbs= p; DOTS agents can pick suitable values for max-retransmit parameter based = on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).

2) No, if the DOTS agent wants to change the default heartbeat inte= rval then the other message transmission parameters will also have to be mo= dified.

3) The client will have to assume the session is disconnected (see = the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The he= artbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 

Med – In the below text, recommended value should be 93 secon= ds instead of 90 seconds (see https://tools= .ietf.org/html/rfc7252#section-4.8.2).

 

-Tiru<= /span>

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

&n= bsp;

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

&n= bsp;

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

&n= bsp;

Oct 04 10:53:51 DEBG sending C= oAP ping:

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to re= transmit queue (2281ms)

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:53:51 ALRT got RST f= or message 29548

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending C= oAP ping:

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to re= transmit queue (2938ms)

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:07 ALRT got RST f= or message 29549

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending C= oAP ping:

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to re= transmit queue (2156ms)

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:23 ALRT got RST f= or message 29550

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending C= oAP ping:

Oct 04 10:54:39 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to re= transmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #1

Oct 04 10:54:42 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #2

Oct 04 10:54:48 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #3

Oct 04 10:55:00 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #4

Oct 04 10:55:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up af= ter 4 attempts

&n= bsp;

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

&n= bsp;

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

&n= bsp;

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

&n= bsp;

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

&n= bsp;

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Scenari= o as Q3

&n= bsp;

Does th= e client re-use the old session that the heartbeats are failing on?

- The s= erver may have sent a session close, but it never got through

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

&n= bsp;

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

&n= bsp;

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow = (supjps-ietf@jpshallow.com= )
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during the interim meeting:= “A: (Jon Shallow): The minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with RFC8085 which= says the following:

 

   An application that needs to employ keep-alive messages t=
o deliver
   useful service over UDP in the presence of middleboxes SH=
OULD NOT
           &nbs=
p;            &=
nbsp;           &nbs=
p;         ^^^^^^^^^^^^^^^^^^^^^^
   transmit them more frequently than once every 15 seconds =
and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^
   use longer intervals when possible.  

 


I suggest to add this NEW text to the signal-channel draft=
 to clarify the rationale for the recommended values:



 


NEW:


    &=
nbsp; Note: heartbeat-interval should be tweaked to also assist DOTS


    &=
nbsp; messages for NAT traversal (SIG-010 of


    &=
nbsp; [I-D.ietf-dots-requirements]).  According to [RFC8085], keepaliv=
e


    &=
nbsp; messages must not be sent more frequently than once every 15


    &=
nbsp; seconds and should use longer intervals when possible.


    &=
nbsp; Furthermore, [RFC4787] recommends NATs to use a state timeout of 2


    &=
nbsp; minutes or longer.  From that standpoint, this specification


    &=
nbsp; recommends a minimum heartbeat-interval of 15 seconds and a


    &=
nbsp; maximum heartbeat-interval of 240 seconds.  The recommended valu=
e


    &=
nbsp; of 90 seconds is selected to anticipate the expiry of NAT states,


    &=
nbsp; while avoiding overloading the network with frequent keepalives<=
/o:p>


    &=
nbsp; for NAT state maintenance purposes.  Note that this recommended<=
o:p>


    &=
nbsp; value is close to the one recommended for MAX_TRANSMIT_WAIT, whose


    &=
nbsp; value is derived from transmission parameters (Section 4.8.2 of<=
/o:p>


     
[RFC7252]).


 


Thoughts?



 


Cheers,


Med
--_000_DM5PR16MB178840D669DC98700AC08731EA700DM5PR16MB1788namp_-- From nobody Thu Oct 5 04:35:31 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDCD1342CF for ; Thu, 5 Oct 2017 04:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7210t3rPTHn6 for ; Thu, 5 Oct 2017 04:35:27 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 C7DF71342C2 for ; Thu, 5 Oct 2017 04:35:26 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e04R3-0004yb-2o; Thu, 05 Oct 2017 12:35:25 +0100 From: "Jon Shallow" To: "'Dobbins, Roland'" , References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> In-Reply-To: <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> Date: Thu, 5 Oct 2017 12:35:25 +0100 Message-ID: <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07E3_01D33DD6.6B5EB1A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwaMGjngA Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 11:35:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07E3_01D33DD6.6B5EB1A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As the use of =E2=80=9Coriginal-client-id=E2=80=9D is a *must*, then I = propose the following changes. It is defined as an array should there = be a client-id name clash and a second (or more) entry needs to be added = by a DOTS Gateway in a long chain. In normal use, it is expected that = there will only be one entry, even though several DOTS Gateways have = been passed through. =20 The following YANG changes need to be made to the signal spec and = associated references updated =20 This document defines the YANG module "ietf-dots-signal", which has the following tree structure: =20 module: ietf-dots-signal +--rw mitigation-scope +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw original-client-id* string +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port inet:port-number +--rw target-protocol* uint8 +--rw fqdn* inet:domain-name +--rw uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 =20 ---- container mitigation-scope { description "Top level container for a mitigation request."; =20 list scope { key mitigation-id; description "Identifier for the mitigation request."; leaf mitigation-id { type int32; description "Mitigation request identifier."; } list original-client-id { type string; description "Original Client ID requesting the = mitigation, REQUIRED and added when passing through a DOTS Gateway."; } leaf-list target-ip { type inet:ip-address; description "IPv4 or IPv6 address identifying the target."; } ---- signal-config +--rw session-id? int32 +--rw original-client-id* string =20 +--rw heartbeat-interval? int16 +--rw missing-hb-allowed? int16 +--rw max-retransmit? int16 +--rw ack-timeout? int16 +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean --- container signal-config { description "Top level container for DOTS signal channel = session configuration."; =20 leaf session-id { type int32; description "An identifier for the DOTS signal channel session configuration data."; } =20 list original-client-id { type string; description "Original Client ID requesting the mitigation, = REQUIRED and added when passing through a DOTS Gateway."; } =20 leaf heartbeat-interval { =20 --- The following YANG changes need to be made to the data spec and = associated references updated =20 module: ietf-dots-data-channel-identifier +--rw identifier +--rw alias* [alias-name] +--rw alias-name string +--rw original-client-id* string +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port inet:port-number +--rw target-protocol* uint8 +--rw fqdn* inet:domain-name +--rw uri* --- container identifier { description "top level container for identifiers"; list alias { key alias-name; description "list of identifiers"; leaf alias-name { type string; description "alias name"; } list original-client-id { type string; description "Original Client ID requesting the = mitigation, REQUIRED and added when passing through a DOTS Gateway."; } leaf-list target-ip { --- The ietf-access-control-list:access-lists is more complicated. With the = introduction of =E2=80=98container interfaces=E2=80=99 in = draft-ietf-netmod-acl-model-14 the text in general in = draft-ietf-dots-data-channel needs updating. This change in = draft-ietf-netmod-acl-model-14 gives us the ability to attach a specific = set of sorted ACLs to an interface, but still does not easily associate = a set of ACL definitions with a particular client. =20 My suggestion is that we add in an additional JSON entry as follows, = with the YANG module module ietf-dots-access-control-list updated (my = YANG is not currently up to doing that) that defines what we are doing. =20 POST /restconf/data/ietf-access-control-list HTTP/1.1 Host: www.example.com Content-Format: "application/yang.api+json" { "original-client-id" : ["string" ],=20 "ietf-access-control-list:access-lists": { "acl": [ =20 [And should not we be posting to = /restconf/data/ietf-dots-access-control-list anyway?] =20 Regards =20 Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Dobbins, Roland Sent: 05 October 2017 10:42 To: dots@ietf.org Subject: Re: [Dots] DOTS Gateways Challenges =20 =20 On Oct 5, 2017, at 14:58, Jon Shallow wrote: Perhaps "original-client-id" would be a better name - in a similar sort = of way that the "X-Forwarding-For:" header provides the original IP = making the HTTP request when passing through a load-balancer or SSL = terminator. =20 This is how it *must* work, agreed; I remember discussing this topic at = one of the WG meetings, specifically. =20 If it somehow was dropped, we need to fix it. Gateways are a necessary = initial capability, as is preserving DOTS client IDs across them. =20 ----------------------------------- Roland Dobbins ------=_NextPart_000_07E3_01D33DD6.6B5EB1A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

As the use of =E2=80=9Coriginal-client-id=E2=80=9D is a = *must*, then I propose the following changes.=C2=A0 It is defined = as an array should there be a client-id name clash and a second (or = more) entry needs to be added by a DOTS Gateway in a long chain.=C2=A0 = In normal use, it is expected that there will only be one entry, even = though several DOTS Gateways have been passed = through.

 

The following YANG changes need to be made to the signal spec and = associated references updated

 

=C2=A0=C2=A0 This document defines the YANG module = "ietf-dots-signal", which has

=C2=A0=C2=A0 the following tree = structure:

 

=C2=A0=C2=A0 module: = ietf-dots-signal

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = mitigation-scope

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--rw scope* [mitigation-id]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw = mitigation-id=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = int32

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw original-client-id*=C2=A0=C2=A0 = string

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw = target-ip*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 inet:ip-address

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw = target-prefix*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = inet:ip-prefix

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0+--rw target-port-range* [lower-port = upper-port]

=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 +--rw lower-port=C2=A0=C2=A0=C2=A0 = inet:port-number

=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 +--rw upper-port=C2=A0=C2=A0=C2=A0 = inet:port-number

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw target-protocol*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = uint8

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw = fqdn*=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=C2=A0=C2=A0 inet:domain-name

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw = uri*=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=C2=A0=C2=A0=C2=A0 inet:uri

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw = alias-name*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = string

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw = lifetime?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 int32

 

----

=C2=A0=C2=A0=C2=A0=C2=A0 container mitigation-scope = {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= description

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "Top level container for a mitigation = request.";

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= list scope {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 key mitigation-id;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 description "Identifier for the mitigation = request.";

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 leaf mitigation-id {

=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=C2=A0 type int32;

=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=C2=A0 description "Mitigation = request identifier.";

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 list original-client-id {

=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=C2=A0 type = string;

=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=C2=A0 description "Original Client = ID requesting the mitigation, REQUIRED and added when passing through a = DOTS Gateway.";

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 leaf-list target-ip {

=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=C2=A0 type = inet:ip-address;

=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=C2=A0 description

=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=C2=A0=C2=A0=C2=A0=C2=A0 "IPv4 or = IPv6 address identifying the target.";

=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=C2=A0=C2=A0=C2=A0=C2=A0 = signal-config

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--rw = session-id?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = int32

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0+--rw original-client-id*=C2=A0=C2=A0 string=C2=A0 =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0+--rw heartbeat-interval?=C2=A0=C2=A0 = int16

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--rw missing-hb-allowed?=C2=A0=C2=A0 int16

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--rw max-retransmit?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = int16

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--rw = ack-timeout?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = int16

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--rw ack-random-factor?=C2=A0=C2=A0=C2=A0 = decimal64

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--rw trigger-mitigation?=C2=A0=C2=A0 Boolean

---

=C2=A0=C2=A0=C2=A0=C2=A0 container signal-config = {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= description "Top level container for DOTS signal channel = session

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 configuration.";

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= leaf session-id {

=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 type int32;

=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=A0descrip= tion "An identifier for the DOTS signal = channel

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 session configuration = data.";

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0list original-client-id {

=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 type string;

=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 description "Original Client ID requesting = the mitigation, REQUIRED and added when passing through a DOTS = Gateway.";

=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=C2=A0=C2=A0=C2=A0=C2=A0= leaf heartbeat-interval {

 

---

The following YANG changes need to be made to the data spec and = associated references updated

 

=C2=A0=C2=A0 module: = ietf-dots-data-channel-identifier

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = identifier

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--rw alias* [alias-name]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw = alias-name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = string

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw original-client-id*=C2=A0 = string

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw = target-ip*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = inet:ip-address

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw = target-prefix*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = inet:ip-prefix

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw target-port-range* [lower-port = upper-port]

=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 +--rw lower-port=C2=A0=C2=A0=C2=A0 = inet:port-number

=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 +--rw upper-port=C2=A0=C2=A0=C2=A0 = inet:port-number

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw target-protocol*=C2=A0=C2=A0=C2=A0=C2=A0 = uint8

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw = fqdn*=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=C2=A0 inet:domain-name

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw uri*

---

=C2=A0=C2=A0=C2=A0=C2=A0 container identifier = {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= description "top level container for = identifiers";

=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 list alias {

=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=C2=A0=C2=A0=C2=A0=C2=A0 key = alias-name;

=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=C2=A0=C2=A0=C2=A0=C2=A0 description = "list of identifiers";

=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=C2=A0=C2=A0=C2=A0=C2=A0 leaf alias-name = {

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = type string;

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = description "alias name";

=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 list = original-client-id {

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 type string;

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 description "Original Client ID requesting the mitigation, = REQUIRED and added when passing through a DOTS = Gateway.";

=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf-list = target-ip {

---

The ietf-access-control-list:access-lists is more complicated.=C2=A0 = With the introduction of =E2=80=98container interfaces=E2=80=99 in = draft-ietf-netmod-acl-model-14 the text in general in = draft-ietf-dots-data-channel needs updating.=C2=A0 This change in = draft-ietf-netmod-acl-model-14 gives us the ability to attach a specific = set of sorted ACLs to an interface, but still does not easily associate = a set of ACL definitions with a particular = client.

 

My suggestion is that we add in an additional JSON entry as follows, = with the YANG module module ietf-dots-access-control-list updated (my = YANG is not currently up to doing that) that defines what we are = doing.

 

=C2=A0 = POST /restconf/data/ietf-access-control-list = HTTP/1.1

=C2=A0 = Host: www.example.com

=C2=A0 = Content-Format: = "application/yang.api+json"

=C2=A0 {

=C2=A0=C2=A0 "original-client-id" : = ["string" ],

=C2=A0=C2=A0=C2=A0"ietf-access-control-list:acce= ss-lists": {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "acl": = [

 

[And should not we be posting to /restconf/data/ietf-d= ots-access-control-list anyway?]

 

Regards

 

Jon

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Dobbins, = Roland
Sent: 05 October 2017 10:42
To: = dots@ietf.org
Subject: Re: [Dots] DOTS Gateways = Challenges

 

 


On Oct 5, 2017, at 14:58, Jon Shallow = <supjps-ietf@jpshallow.com&g= t; wrote:

Perhaps "original-client-id" would be a = better name - in a similar sort of way that the = "X-Forwarding-For:" header provides the original IP making the = HTTP request when passing through a load-balancer or SSL = terminator.

 

This is = how it *must* work, agreed; I remember discussing this topic at one of = the WG meetings, specifically.

 

If it somehow was dropped, we need to fix it. =  Gateways are a necessary initial capability, as is preserving DOTS = client IDs across them.

 

-----------------------------------

Roland Dobbins <rdobbins@arbor.net><= /p>

------=_NextPart_000_07E3_01D33DD6.6B5EB1A0-- From nobody Thu Oct 5 22:19:03 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1997D13420F for ; Thu, 5 Oct 2017 22:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 Gn-eP3-CYO64 for ; Thu, 5 Oct 2017 22:19:00 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 ECDC0124B18 for ; Thu, 5 Oct 2017 22:18:59 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507267127; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=o2gcaJZ2GtcCfrOkml9mVzrwtjda+bYMgD3rxt JEfI4=; b=d9BNBmgWWMpAuWqAM8x3iKWFjw13CZ6WkK1/QxqI Nzk6+GQWVeK9zYlaohKh7kVkPxQxgciBzW2EvkakgV7CCgoUtF vWz4lQCVu/l5+a442PNDcZJnwpIwJ/AcrQOMeRzYaAkd4QEkl1 iXTanuei72dH9MhnmbBIQPBAqZMOIyI= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 58ca_3e5d_b9fa52b4_f64f_42dc_b84a_7a5d927399f4; Fri, 06 Oct 2017 00:18:47 -0500 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 01:18:45 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Oct 2017 01:18:45 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 01:18:45 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 6 Oct 2017 05:18:44 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.018; Fri, 6 Oct 2017 05:18:44 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Coding and Interoperability Challenges Thread-Index: AdMouv44Udo0NFExSCOHW+HXkRNTEQERxjbqAVIVJZ8CskQHRqGgxiVwoaSKVGC8uS4jAP/8yNew Date: Fri, 6 Oct 2017 05:18:44 +0000 Message-ID: References: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> <00a101d32d46$b2f30cf0$18d926d0$@jpshallow.com> <037c01d33a2c$ed764700$c862d500$@jpshallow.com> <040401d33ac9$85542c80$8ffc8580$@jpshallow.com> <060201d33c52$ca5ca390$5f15eab0$@jpshallow.com> In-Reply-To: <060201d33c52$ca5ca390$5f15eab0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.167.137.9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:bOqlq4NdDN8PRnY+2nzW59lMrMzeWQOkkf3F8BrilDsmzObUmdt9MJcUywsTRSCYbuCRHAK2PYH6Wc2QqL0k9O1VRPiHXc/NiMOMStIxAvvZ5/WiuIMOAxO3ALCgtWJ1k+8cnsgtms/q7KUxh2kvvsM+2GTwPtbU9+y9V5B5lMZcWPmpHDUn9yjtA+Q2sScICkFyLbmc0g5goFNVOYjkgX/N9k1CrIqUmnoOF65R2mB4X2dsw6qgcpoQnlznamok+XvBa2UzLoSXctL4l5iEs+43R4Vk//R1idjeq2I4EFPh3FsoiEB4+KWdbwHG4vf14ihOn+bl69FY1x5TIY5qoQ==; 5:ic/oC21pdDh1RtDsuE41ldozRs4V4wz1mFq8pzLwRIh3hK1YlSPsSvsu8PbNGMjsk+4cHmehSU4UWtpJ485JKejv9iuAKVGJxvSRMb45lQzxncwb5BLp/oRvYTh8DtWL+PE2+5xdFYqPbtURUfMVGw==; 24:5kv/jGct4NVU9HYzsRRMHULKxeAkVmI9AWtL1ZLOV23XrggAzKiEvGp4pmoPmYem4mS8s4OMv79+f4DS5UgM6omfDATkBIM9pkiTY85fJ+g=; 7:pukl5nJ3EuCLrKuDr4RpcQyKzw+Cp0b/Jcj4KSNlfYZsiZoznYmaBZbixztYXTL7rJMd4JimH9Vwaqv/4hA18yYsJ5zFM0GSUL6OntzAWe6QfzB/Vt8I78xo1Ct6TJgDlK2HQJrSInbl2HVJan24kRxatMZVM1g9f6TwHvM3dPX2/ElshkqYD6oBt92Yq3SsG3h7LuJRwE0zqyM3/odIA5IM4XMEZrUizdw7Of7Jla0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f4f7953f-067b-457c-1404-08d50c79b711 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0452022BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(32952001)(189002)(377454003)(13464003)(199003)(50986999)(101416001)(14454004)(6116002)(229853002)(5660300001)(9686003)(106356001)(54356999)(6506006)(86362001)(189998001)(76176999)(53546010)(2900100001)(102836003)(68736007)(2950100002)(55016002)(3846002)(105586002)(99286003)(77096006)(7696004)(6436002)(2501003)(93886005)(33656002)(7736002)(3280700002)(81166006)(316002)(81156014)(2906002)(25786009)(8676002)(305945005)(80792005)(97736004)(110136005)(53936002)(66066001)(3660700001)(6246003)(478600001)(72206003)(8936002)(74316002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2017 05:18:44.3312 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6130> : inlines <6109> : streams <1766046> : uri <2511993> Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 05:19:02 -0000 > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Tuesday, October 3, 2017 7:51 PM > To: Konda, Tirumaleswar Reddy ; > dots@ietf.org > Subject: RE: [Dots] Coding and Interoperability Challenges >=20 > Hi Tiru, >=20 > Several things >=20 > 1) Missing target-prefix CBOR mapping in signal spec Thanks, will fix in the next revision.=20 >=20 > 2) mitigation-start representation in signal spec >=20 > It does not appear in Fig 10. >=20 > It is defined as being in seconds > " mitigation-start: Mitigation start time is represented in seconds > relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of > [RFC7049])." > But as a float representation > | CurrentValue | 29 | 0 = | > | mitigation-start | 30 | 7 (floating-point) = | > \--------------------+------------------------+--------------------------= / > Which is OK. A CBOR tag of 1 followed by a value of a floating point num= ber. > However, there is no direct JSON equivalent of this that I can find. >=20 > So, should it be displayed (in JSON) as UTC, local timezone or simply sec= onds? >=20 > Mitigation-start: 2017-10-03T10:15:30-05:00 Or > Mitigation-start: 2017-10-03T15:15:30Z > Or > Mitigation-start: 1507040181.567890 Mitigation-start: 1507040181.567890 (represented in JSON number format).=20 -Tiru >=20 > Regards >=20 > Jon From nobody Fri Oct 6 00:09:41 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A083134475 for ; Fri, 6 Oct 2017 00:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55uXoSt_ClmD for ; Fri, 6 Oct 2017 00:09:36 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7309134468 for ; Fri, 6 Oct 2017 00:09:35 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 366D01003B8; Fri, 6 Oct 2017 09:09:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 0DF2D4006B; Fri, 6 Oct 2017 09:09:34 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0361.001; Fri, 6 Oct 2017 09:09:33 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AQHTPnIP7Kah/D4riES1np3zqLK3TA== Date: Fri, 6 Oct 2017 07:09:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A050387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A050387OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 07:09:39 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A050387OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, all, Please see inline. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 5 octobre 2017 12:54 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Minimum heartbeat-interval http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). [Med] You are right about the configurable aspect, but the question from Jo= n is a good one. I interpret it in another way: - Should we rely solely on the missing-hb-allowed to detect a session pr= oblem? - Should we get rid of missing-hb-allowed, but rely on the retransmissio= n to declare failure or not? - What is the advantage of cumulating both missing-hb-allowed and the re= transmission procedure to declare a channel out? 2) No, [Med] I agree that a heartbeat does not need to be fired when the first pin= g is still alive. We can clarify this in the draft. if the DOTS agent wants to change the default heartbeat interval then the o= ther message transmission parameters will also have to be modified. [Med] I disagree here that the other parameters need to be changed. I don't= see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree= that we need to tweak heartbeat-interval as a function of MAX_TRANSMIT_WAI= T). As you know, MAX_TRANSMIT_WAIT can be derived from other parameters (AC= K_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR)). This i= s why it does not make sense to provide a configuration for MAX_TRANSMIT_WA= IT if the other parameters are provided. 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A050387OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru, all,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mail= to:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 5 octobre 2017 12:54
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Minimum heartbeat-interval=

 

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf= referenced by https://tools.ietf.org/html= /rfc7925 has tested NAT behavior with various routers and lists the tim= eout results. The majority of the devices (62%) have a timeout between 2 an= d 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is = 54 seconds.

 

Responses to the questions below

 

1) The max-retransmit parameter is negotiable and co= nfigurable,  DOTS agents can pick suitable values for max-retransmit p= arameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).=

 

[Med= ] You are right about the configurable aspect, but the question from Jon is= a good one. I interpret it in another way:

-    Should we rely solely on the missing-hb-allowed to detect a session pro= blem?

-    Should we get rid of missing-hb-allowed, but rely on the retransmission= to declare failure or not?

-    What is the advantage of cumulating both missing-hb-allowed and the ret= ransmission procedure to declare a channel out?

 

2) No,=

[Med= ] I agree that a heartbeat does not need to be fired when the first ping is= still alive. We can clarify this in the draft.

 

if the DOTS agent wants to change the default heartb= eat interval then the other message transmission parameters will also have = to be modified.

[Med= ] I disagree here that the other parameters need to be changed. I don’= ;t see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree that we need to tweak heartbeat-interval as a function of= MAX_TRANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from oth= er parameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RA= NDOM_FACTOR)). This is why it does not make sense to provide a configuration for MAX_TRANSMIT_WAIT if the other p= arameters are provided.

 

3) The client will have to assume the session is dis= connected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will cl= ose the (D)TLS session, the client will have to initiate (D)TLS session res= umption. The heartbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 

Med – In the below text, recommended value sho= uld be 93 seconds instead of 90 seconds (see https://tools= .ietf.org/html/rfc7252#section-4.8.2).

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

&n= bsp;

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

&n= bsp;

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

&n= bsp;

Oct 04 10:53:51 DEBG sending C= oAP ping:

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to re= transmit queue (2281ms)

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:53:51 ALRT got RST f= or message 29548

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending C= oAP ping:

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to re= transmit queue (2938ms)

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:07 ALRT got RST f= or message 29549

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending C= oAP ping:

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to re= transmit queue (2156ms)

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:23 ALRT got RST f= or message 29550

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending C= oAP ping:

Oct 04 10:54:39 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to re= transmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #1

Oct 04 10:54:42 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #2

Oct 04 10:54:48 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #3

Oct 04 10:55:00 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #4

Oct 04 10:55:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up af= ter 4 attempts

&n= bsp;

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

&n= bsp;

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

&n= bsp;

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

&n= bsp;

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

&n= bsp;

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Scenari= o as Q3

&n= bsp;

Does th= e client re-use the old session that the heartbeats are failing on?

- The s= erver may have sent a session close, but it never got through

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

&n= bsp;

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

&n= bsp;

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto:ietf-sup= jps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow = (supjps-ietf@jpshallow.com= )
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during the i= nterim meeting: “A: (Jon Shallow): The minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned wit= h RFC8085 which says the following:

 

   An application that need=
s to employ keep-alive messages to deliver
   useful service over UDP =
in the presence of middleboxes SHOULD NOT
      &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;  ^^^^^^^^^^^^^^^^^^^^^^
   transmit them more frequ=
ently than once every 15 seconds and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   use longer intervals whe=
n possible. 

 

I suggest to add this NEW text to the signa= l-channel draft to clarify the rationale for the recommended values:

 

NEW:

 &nbs= p;    Note: heartbeat-interval should be tweaked to also ass= ist DOTS

 &nbs= p;    messages for NAT traversal (SIG-010 of

 &nbs= p;    [I-D.ietf-dots-requirements]).  According to [RFC= 8085], keepalive

 &nbs= p;    messages must not be sent more frequently than once ev= ery 15

 &nbs= p;    seconds and should use longer intervals when possible.=

 &nbs= p;    Furthermore, [RFC4787] recommends NATs to use a state = timeout of 2

 &nbs= p;    minutes or longer.  From that standpoint, this sp= ecification

 &nbs= p;    recommends a minimum heartbeat-interval of 15 seconds = and a

 &nbs= p;    maximum heartbeat-interval of 240 seconds.  The r= ecommended value

 &nbs= p;    of 90 seconds is selected to anticipate the expiry of = NAT states,

 &nbs= p;    while avoiding overloading the network with frequent k= eepalives

 &nbs= p;    for NAT state maintenance purposes.  Note that th= is recommended

 &nbs= p;    value is close to the one recommended for MAX_TRANSMIT= _WAIT, whose

 &nbs= p;    value is derived from transmission parameters (Section= 4.8.2 of

      [RFC7252]).

 

Thoughts?

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A050387OPEXCLILMA3corp_-- From nobody Fri Oct 6 00:20:37 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56DA134495 for ; Fri, 6 Oct 2017 00:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iK2cfB3eVRx7 for ; Fri, 6 Oct 2017 00:20:29 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0FD13447D for ; Fri, 6 Oct 2017 00:20:29 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 7424CA05DD; Fri, 6 Oct 2017 09:20:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 27DED1A007C; Fri, 6 Oct 2017 09:20:27 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0361.001; Fri, 6 Oct 2017 09:20:25 +0200 From: To: Jon Shallow , 'Roland Dobbins' , "dots@ietf.org" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuoyXw+SCAAYqasA== Date: Fri, 6 Oct 2017 07:20:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0503D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> In-Reply-To: <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0503D9OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 07:20:34 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0503D9OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : jeudi 5 octobre 2017 09:58 =C0 : 'Roland Dobbins'; dots@ietf.org Objet : Re: [Dots] DOTS Gateways Challenges Hi Roland, Perhaps "original-client-id" would be a better name - in a similar sort of = way that the "X-Forwarding-For:" header provides the original IP making the= HTTP request when passing through a load-balancer or SSL terminator. [Med] I would say: it depends whether the gateway is located in the client = domain (e.g., https://tools.ietf.org/html/draft-boucadair-dots-multihoming-= 01#section-4.2) or at the operator domain. If the DOTS gateway is at the cl= ient side, then the question to reveal the original client-id may be questi= oned. +----+ | c1 |\ +----+ \ +---+ \-----UDP-----| D | +---+ +----+ | O | | | | c2 |--------UDP-----| T |------UDP------| S | +----+ | S | | | /-----UDP-----| G | +---+ +----+ / +---+ | c3 |/ +----+ The DOTSGW'Server (G'S) does know the client-id of C1, but in the connectio= n DOTSGW'Client (G'C) <-> S this is not (currently) passed on. When traffic from S when received at G'C (e.g. unsolicited Observe status c= hange), this has to be looked up in DOTSGW to work out which Cn G'S is goin= g to send it on to. Having the (original)-client-id in the G'C <-> S commu= nication helps the lookup on G. For example, the lookup (for unsolicited Observe status change)is based on= the COAP TAG in the message - but if both C1 and C2 have used the same TAG= id in their GET with Observe set request then either the TAG has to be 'NA= T' when forwarded on somehow to make sure the response goes back to the cor= rect client, or the additional key is (original)-client-id. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Roland Dobbins Sent: 04 October 2017 22:37 To: dots@ietf.org Subject: Re: [Dots] DOTS Gateways Challenges On 5 Oct 2017, at 4:21, Jon Shallow wrote: > The use of a client-id would help in the directing of any traffic from > S to the appropriate Cn. This is already present, is it not? ----------------------------------- Roland Dobbins > _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_787AE7BB302AE849A7480A190F8B93300A0503D9OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Jon Shallow
Envoy=E9 : jeudi 5 octobre 2017 09:58
=C0 : 'Roland Dobbins'; dots@ietf.org
Objet : Re: [Dots] DOTS Gateways Challenges

 

Hi Roland,=

 

Perhaps "original-clien= t-id" would be a better name - in a similar sort of way that the "= ;X-Forwarding-For:" header provides the original IP making the HTTP re= quest when passing through a load-balancer or SSL terminator.

 

[Med] I would say: it depend= s whether the gateway is located in the client domain (e.g., https://tools.ietf.org/html/draft-boucadair-dots-multihoming-01#section-4.2= ) or at the operator domain. If the DOTS gateway is at the client side,= then the question to reveal the original client-id may be questioned. &nbs= p;

 

 

       = ; +----+

       = ; | c1 |\

       = ; +----+ \         &nb= sp;    +---+

       = ;         \-----UDP-----| D | =             &nb= sp; +---+

       = ; +----+          = ;      | O |      &n= bsp;        |   |

       = ; | c2 |--------UDP-----| T |------UDP------| S |

       = ; +----+          = ;      | S |      &n= bsp;        |   |

       = ;         /-----UDP-----| G | =             &nb= sp; +---+

       = ; +----+ /         &nb= sp;    +---+

       = ; | c3 |/

       = ; +----+

 

The DOTSGW'Server (G'S) does= know the client-id of C1, but in the connection DOTSGW’Client (G'C) = <-> S this is not (currently) passed on.

 

When traffic from S when rec= eived at G'C (e.g. unsolicited Observe status change), this has to be looke= d up in DOTSGW to work out which Cn G'S is going to send it on to.  Ha= ving the (original)-client-id in the G'C <-> S communication helps the lookup on G.

For example,  the looku= p (for unsolicited Observe status change)is based on the COAP TAG in the me= ssage - but if both C1 and C2 have used the same TAG id in their GET with O= bserve set request then either the TAG has to be 'NAT' when forwarded on somehow to make sure the response goes back = to the correct client, or the additional key is (original)-client-id.<= /o:p>

 

Regards

 

Jon

 

-----Original Message-----
From: Dots [mailto: dots-bounces@i= etf.org] On Behalf Of Roland Dobbins
Sent: 04 October 2017 22:37
To: dots@ietf.org
Subject: Re: [Dots] DOTS Gateways Challenges

 

On 5 Oct 2017, at 4:21, Jon = Shallow wrote:

 

> The use of a client-id = would help in the directing of any traffic from

> S to the appropriate Cn= .

 

This is already present, is = it not?

 

----------------------------= -------

Roland Dobbins <rdobbins@arbor.net>

 

____________________________= ___________________

Dots mailing list=

Dots@ietf.org

https://www.ietf.org/mailman/listinfo/dots

--_000_787AE7BB302AE849A7480A190F8B93300A0503D9OPEXCLILMA3corp_-- From nobody Fri Oct 6 00:37:11 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED871344E3 for ; Fri, 6 Oct 2017 00:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_rChjQIMEdZ for ; Fri, 6 Oct 2017 00:37:01 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2D71344DE for ; Fri, 6 Oct 2017 00:37:01 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 20DF8C085E; Fri, 6 Oct 2017 09:37:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id EC55480062; Fri, 6 Oct 2017 09:36:59 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0361.001; Fri, 6 Oct 2017 09:36:59 +0200 From: To: Jon Shallow , "'Dobbins, Roland'" , "dots@ietf.org" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwaMGjngAgAFgcKA= Date: Fri, 6 Oct 2017 07:36:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> In-Reply-To: <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0503FFOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 07:37:05 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0503FFOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpJIGRpc2FncmVlIHdpdGggdGhlIGZvbGxvd2luZyA6DQoNCiAgICAgICAgICAgICAg ICB0eXBlIHN0cmluZzsNCiAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiT3JpZ2luYWwgQ2xp ZW50IElEIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24sIFJFUVVJUkVEIGFuZCBhZGRlZCB3aGVu IHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR2F0ZXdheS4iOw0KICAgICAgICAgICAgIH0NCg0KQSBn YXRld2F5IG1heSBiZSBpbnN0cnVjdGVkIHRoZSByZXZlYWwgdGhlIG9yaWdpbmFsIGNsaWVudCBp ZGVudGl0eSBvbmx5IGluIHNvbWUgZGVwbG95bWVudHMgKG5vdCBhbGwpOyBvdGhlcndpc2UgaXQg aXMgdGhlIGdhdGV3YXkgaWRlbnRpZnkgdGhhdCBpcyB1c2VkIGJ5IHRoZSByZW1vdGUgc2VydmVy LiBUaGUgZ2F0ZXdheSBpZGVudGl0eSBpcyBleHRyYWN0ZWQgZnJvbSB0aGUgYXV0aGVudGljYXRp b24gY3JlZGVudGlhbHMuDQoNCkEgY29uZmlndXJhYmxlIHBhcmFtZXRlciB0byBlbmFibGUvZGlz YWJsZSB0aGF0IHRoZSBvcmlnaW5hbCBjbGllbnQgaWRlbnRpdHkgaXMgcGFzc2VkLCBtYXkgYmUg Y29uc2lkZXJlZCAoZGlzYWJsZWQgYnkgZGVmYXVsdCwgSU1PKS4gVGhlIG9yaWdpbmFsIGNsaWVu dCBpZGVudGl0eSBpcyB0aGVyZWZvcmUgb3B0aW9uYWwsIG5vdCBtYW5kYXRvcnkuDQoNCkJUVywg aXQgbWF5IGJlIHdvcnRoIHRvIGNvbnNpZGVyIGEgZGVkaWNhdGVkIFlBTkcgbW9kdWxlIGZvciBE T1RTIGdhdGV3YXlzLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBEb3RzIFttYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvbiBTaGFsbG93DQpFbnZvecOpIDogamV1 ZGkgNSBvY3RvYnJlIDIwMTcgMTM6MzUNCsOAIDogJ0RvYmJpbnMsIFJvbGFuZCc7IGRvdHNAaWV0 Zi5vcmcNCk9iamV0IDogUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KQXMg dGhlIHVzZSBvZiDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0gaXMgYSAqbXVzdCosIHRoZW4gSSBw cm9wb3NlIHRoZSBmb2xsb3dpbmcgY2hhbmdlcy4gIEl0IGlzIGRlZmluZWQgYXMgYW4gYXJyYXkg c2hvdWxkIHRoZXJlIGJlIGEgY2xpZW50LWlkIG5hbWUgY2xhc2ggYW5kIGEgc2Vjb25kIChvciBt b3JlKSBlbnRyeSBuZWVkcyB0byBiZSBhZGRlZCBieSBhIERPVFMgR2F0ZXdheSBpbiBhIGxvbmcg Y2hhaW4uICBJbiBub3JtYWwgdXNlLCBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZXJlIHdpbGwgb25s eSBiZSBvbmUgZW50cnksIGV2ZW4gdGhvdWdoIHNldmVyYWwgRE9UUyBHYXRld2F5cyBoYXZlIGJl ZW4gcGFzc2VkIHRocm91Z2guDQoNClRoZSBmb2xsb3dpbmcgWUFORyBjaGFuZ2VzIG5lZWQgdG8g YmUgbWFkZSB0byB0aGUgc2lnbmFsIHNwZWMgYW5kIGFzc29jaWF0ZWQgcmVmZXJlbmNlcyB1cGRh dGVkDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgWUFORyBtb2R1bGUgImlldGYtZG90 cy1zaWduYWwiLCB3aGljaCBoYXMNCiAgIHRoZSBmb2xsb3dpbmcgdHJlZSBzdHJ1Y3R1cmU6DQoN CiAgIG1vZHVsZTogaWV0Zi1kb3RzLXNpZ25hbA0KICAgICAgICstLXJ3IG1pdGlnYXRpb24tc2Nv cGUNCiAgICAgICAgICArLS1ydyBzY29wZSogW21pdGlnYXRpb24taWRdDQogICAgICAgICAgICAg Ky0tcncgbWl0aWdhdGlvbi1pZCAgICAgICAgIGludDMyDQogICAgICAgICAgICAgKy0tcncgb3Jp Z2luYWwtY2xpZW50LWlkKiAgIHN0cmluZw0KICAgICAgICAgICAgICstLXJ3IHRhcmdldC1pcCog ICAgICAgICAgICBpbmV0OmlwLWFkZHJlc3MNCiAgICAgICAgICAgICArLS1ydyB0YXJnZXQtcHJl Zml4KiAgICAgICAgaW5ldDppcC1wcmVmaXgNCiAgICAgICAgICAgICArLS1ydyB0YXJnZXQtcG9y dC1yYW5nZSogW2xvd2VyLXBvcnQgdXBwZXItcG9ydF0NCiAgICAgICAgICAgICB8ICArLS1ydyBs b3dlci1wb3J0ICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAgICAgICAgICB8ICArLS1ydyB1cHBl ci1wb3J0ICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAgICAgICAgICArLS1ydyB0YXJnZXQtcHJv dG9jb2wqICAgICAgdWludDgNCiAgICAgICAgICAgICArLS1ydyBmcWRuKiAgICAgICAgICAgICAg ICAgaW5ldDpkb21haW4tbmFtZQ0KICAgICAgICAgICAgICstLXJ3IHVyaSogICAgICAgICAgICAg ICAgICBpbmV0OnVyaQ0KICAgICAgICAgICAgICstLXJ3IGFsaWFzLW5hbWUqICAgICAgICAgICBz dHJpbmcNCiAgICAgICAgICAgICArLS1ydyBsaWZldGltZT8gICAgICAgICAgICAgaW50MzINCg0K LS0tLQ0KICAgICBjb250YWluZXIgbWl0aWdhdGlvbi1zY29wZSB7DQogICAgICAgICAgZGVzY3Jp cHRpb24NCiAgICAgICAgICAgICAiVG9wIGxldmVsIGNvbnRhaW5lciBmb3IgYSBtaXRpZ2F0aW9u IHJlcXVlc3QuIjsNCg0KICAgICAgICAgIGxpc3Qgc2NvcGUgew0KICAgICAgICAgICAgIGtleSBt aXRpZ2F0aW9uLWlkOw0KICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJJZGVudGlmaWVyIGZvciB0 aGUgbWl0aWdhdGlvbiByZXF1ZXN0LiI7DQogICAgICAgICAgICAgbGVhZiBtaXRpZ2F0aW9uLWlk IHsNCiAgICAgICAgICAgICAgICB0eXBlIGludDMyOw0KICAgICAgICAgICAgICAgIGRlc2NyaXB0 aW9uICJNaXRpZ2F0aW9uIHJlcXVlc3QgaWRlbnRpZmllci4iOw0KICAgICAgICAgICAgIH0NCiAg ICAgICAgICAgICBsaXN0IG9yaWdpbmFsLWNsaWVudC1pZCB7DQogICAgICAgICAgICAgICAgdHlw ZSBzdHJpbmc7DQogICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIk9yaWdpbmFsIENsaWVudCBJ RCByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uLCBSRVFVSVJFRCBhbmQgYWRkZWQgd2hlbiBwYXNz aW5nIHRocm91Z2ggYSBET1RTIEdhdGV3YXkuIjsNCiAgICAgICAgICAgICB9DQogICAgICAgICAg ICAgbGVhZi1saXN0IHRhcmdldC1pcCB7DQogICAgICAgICAgICAgICAgdHlwZSBpbmV0OmlwLWFk ZHJlc3M7DQogICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAgICAi SVB2NCBvciBJUHY2IGFkZHJlc3MgaWRlbnRpZnlpbmcgdGhlIHRhcmdldC4iOw0KICAgICAgICAg ICAgIH0NCi0tLS0NCiAgICAgICBzaWduYWwtY29uZmlnDQogICAgICAgICAgKy0tcncgc2Vzc2lv bi1pZD8gICAgICAgICAgIGludDMyDQogICAgICAgICAgKy0tcncgb3JpZ2luYWwtY2xpZW50LWlk KiAgIHN0cmluZw0KICAgICAgICAgICstLXJ3IGhlYXJ0YmVhdC1pbnRlcnZhbD8gICBpbnQxNg0K ICAgICAgICAgICstLXJ3IG1pc3NpbmctaGItYWxsb3dlZD8gICBpbnQxNg0KICAgICAgICAgICst LXJ3IG1heC1yZXRyYW5zbWl0PyAgICAgICBpbnQxNg0KICAgICAgICAgICstLXJ3IGFjay10aW1l b3V0PyAgICAgICAgICBpbnQxNg0KICAgICAgICAgICstLXJ3IGFjay1yYW5kb20tZmFjdG9yPyAg ICBkZWNpbWFsNjQNCiAgICAgICAgICArLS1ydyB0cmlnZ2VyLW1pdGlnYXRpb24/ICAgQm9vbGVh bg0KLS0tDQogICAgIGNvbnRhaW5lciBzaWduYWwtY29uZmlnIHsNCiAgICAgICAgICBkZXNjcmlw dGlvbiAiVG9wIGxldmVsIGNvbnRhaW5lciBmb3IgRE9UUyBzaWduYWwgY2hhbm5lbCBzZXNzaW9u DQogICAgICAgICAgICAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24uIjsNCg0KICAgICAgICAgIGxl YWYgc2Vzc2lvbi1pZCB7DQogICAgICAgICAgICAgIHR5cGUgaW50MzI7DQogICAgICAgICAgICAg IGRlc2NyaXB0aW9uICJBbiBpZGVudGlmaWVyIGZvciB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2Vzc2lvbiBjb25maWd1cmF0aW9uIGRhdGEuIjsN CiAgICAgICAgICB9DQogICAgICAgICAgbGlzdCBvcmlnaW5hbC1jbGllbnQtaWQgew0KICAgICAg ICAgICAgICB0eXBlIHN0cmluZzsNCiAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIk9yaWdpbmFs IENsaWVudCBJRCByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uLCBSRVFVSVJFRCBhbmQgYWRkZWQg d2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdhdGV3YXkuIjsNCiAgICAgICAgICB9DQoNCiAg ICAgICAgICBsZWFmIGhlYXJ0YmVhdC1pbnRlcnZhbCB7DQoNCi0tLQ0KVGhlIGZvbGxvd2luZyBZ QU5HIGNoYW5nZXMgbmVlZCB0byBiZSBtYWRlIHRvIHRoZSBkYXRhIHNwZWMgYW5kIGFzc29jaWF0 ZWQgcmVmZXJlbmNlcyB1cGRhdGVkDQoNCiAgIG1vZHVsZTogaWV0Zi1kb3RzLWRhdGEtY2hhbm5l bC1pZGVudGlmaWVyDQogICAgICAgKy0tcncgaWRlbnRpZmllcg0KICAgICAgICAgICstLXJ3IGFs aWFzKiBbYWxpYXMtbmFtZV0NCiAgICAgICAgICAgICArLS1ydyBhbGlhcy1uYW1lICAgICAgICAg ICBzdHJpbmcNCiAgICAgICAgICAgICArLS1ydyBvcmlnaW5hbC1jbGllbnQtaWQqICBzdHJpbmcN CiAgICAgICAgICAgICArLS1ydyB0YXJnZXQtaXAqICAgICAgICAgICBpbmV0OmlwLWFkZHJlc3MN CiAgICAgICAgICAgICArLS1ydyB0YXJnZXQtcHJlZml4KiAgICAgICBpbmV0OmlwLXByZWZpeA0K ICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wb3J0LXJhbmdlKiBbbG93ZXItcG9ydCB1cHBlci1w b3J0XQ0KICAgICAgICAgICAgIHwgICstLXJ3IGxvd2VyLXBvcnQgICAgaW5ldDpwb3J0LW51bWJl cg0KICAgICAgICAgICAgIHwgICstLXJ3IHVwcGVyLXBvcnQgICAgaW5ldDpwb3J0LW51bWJlcg0K ICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wcm90b2NvbCogICAgIHVpbnQ4DQogICAgICAgICAg ICAgKy0tcncgZnFkbiogICAgICAgICAgICAgICAgaW5ldDpkb21haW4tbmFtZQ0KICAgICAgICAg ICAgICstLXJ3IHVyaSoNCi0tLQ0KICAgICBjb250YWluZXIgaWRlbnRpZmllciB7DQogICAgICAg ICAgZGVzY3JpcHRpb24gInRvcCBsZXZlbCBjb250YWluZXIgZm9yIGlkZW50aWZpZXJzIjsNCiAg ICAgICAgICAgICAgbGlzdCBhbGlhcyB7DQogICAgICAgICAgICAgICAgICAga2V5IGFsaWFzLW5h bWU7DQogICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gImxpc3Qgb2YgaWRlbnRpZmllcnMi Ow0KICAgICAgICAgICAgICAgICAgIGxlYWYgYWxpYXMtbmFtZSB7DQogICAgICAgICAgICAgICAg ICAgICAgdHlwZSBzdHJpbmc7DQogICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gImFs aWFzIG5hbWUiOw0KICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICBsaXN0 IG9yaWdpbmFsLWNsaWVudC1pZCB7DQogICAgICAgICAgICAgICAgICAgICAgIHR5cGUgc3RyaW5n Ow0KICAgICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiT3JpZ2luYWwgQ2xpZW50IElE IHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24sIFJFUVVJUkVEIGFuZCBhZGRlZCB3aGVuIHBhc3Np bmcgdGhyb3VnaCBhIERPVFMgR2F0ZXdheS4iOw0KICAgICAgICAgICAgICAgICAgIH0NCiAgICAg ICAgICAgICAgICAgICBsZWFmLWxpc3QgdGFyZ2V0LWlwIHsNCi0tLQ0KVGhlIGlldGYtYWNjZXNz LWNvbnRyb2wtbGlzdDphY2Nlc3MtbGlzdHMgaXMgbW9yZSBjb21wbGljYXRlZC4gIFdpdGggdGhl IGludHJvZHVjdGlvbiBvZiDigJhjb250YWluZXIgaW50ZXJmYWNlc+KAmSBpbiBkcmFmdC1pZXRm LW5ldG1vZC1hY2wtbW9kZWwtMTQgdGhlIHRleHQgaW4gZ2VuZXJhbCBpbiBkcmFmdC1pZXRmLWRv dHMtZGF0YS1jaGFubmVsIG5lZWRzIHVwZGF0aW5nLiAgVGhpcyBjaGFuZ2UgaW4gZHJhZnQtaWV0 Zi1uZXRtb2QtYWNsLW1vZGVsLTE0IGdpdmVzIHVzIHRoZSBhYmlsaXR5IHRvIGF0dGFjaCBhIHNw ZWNpZmljIHNldCBvZiBzb3J0ZWQgQUNMcyB0byBhbiBpbnRlcmZhY2UsIGJ1dCBzdGlsbCBkb2Vz IG5vdCBlYXNpbHkgYXNzb2NpYXRlIGEgc2V0IG9mIEFDTCBkZWZpbml0aW9ucyB3aXRoIGEgcGFy dGljdWxhciBjbGllbnQuDQoNCk15IHN1Z2dlc3Rpb24gaXMgdGhhdCB3ZSBhZGQgaW4gYW4gYWRk aXRpb25hbCBKU09OIGVudHJ5IGFzIGZvbGxvd3MsIHdpdGggdGhlIFlBTkcgbW9kdWxlIG1vZHVs ZSBpZXRmLWRvdHMtYWNjZXNzLWNvbnRyb2wtbGlzdCB1cGRhdGVkIChteSBZQU5HIGlzIG5vdCBj dXJyZW50bHkgdXAgdG8gZG9pbmcgdGhhdCkgdGhhdCBkZWZpbmVzIHdoYXQgd2UgYXJlIGRvaW5n Lg0KDQogIFBPU1QgL3Jlc3Rjb25mL2RhdGEvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0IEhUVFAv MS4xDQogIEhvc3Q6IHd3dy5leGFtcGxlLmNvbTxodHRwOi8vd3d3LmV4YW1wbGUuY29tPg0KICBD b250ZW50LUZvcm1hdDogImFwcGxpY2F0aW9uL3lhbmcuYXBpK2pzb24iDQogIHsNCiAgICJvcmln aW5hbC1jbGllbnQtaWQiIDogWyJzdHJpbmciIF0sDQogICAiaWV0Zi1hY2Nlc3MtY29udHJvbC1s aXN0OmFjY2Vzcy1saXN0cyI6IHsNCiAgICAgICJhY2wiOiBbDQoNCltBbmQgc2hvdWxkIG5vdCB3 ZSBiZSBwb3N0aW5nIHRvIC9yZXN0Y29uZi9kYXRhL2lldGYtZG90cy1hY2Nlc3MtY29udHJvbC1s aXN0IGFueXdheT9dDQoNClJlZ2FyZHMNCg0KSm9uDQpGcm9tOiBEb3RzIFttYWlsdG86IGRvdHMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxm IE9mIERvYmJpbnMsIFJvbGFuZA0KU2VudDogMDUgT2N0b2JlciAyMDE3IDEwOjQyDQpUbzogZG90 c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRG90c10gRE9U UyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCg0KDQpPbiBPY3QgNSwgMjAxNywgYXQgMTQ6NTgsIEpv biBTaGFsbG93IDxzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPG1haWx0bzpzdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tPj4gd3JvdGU6DQpQZXJoYXBzICJvcmlnaW5hbC1jbGllbnQtaWQiIHdvdWxk IGJlIGEgYmV0dGVyIG5hbWUgLSBpbiBhIHNpbWlsYXIgc29ydCBvZiB3YXkgdGhhdCB0aGUgIlgt Rm9yd2FyZGluZy1Gb3I6IiBoZWFkZXIgcHJvdmlkZXMgdGhlIG9yaWdpbmFsIElQIG1ha2luZyB0 aGUgSFRUUCByZXF1ZXN0IHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgbG9hZC1iYWxhbmNlciBvciBT U0wgdGVybWluYXRvci4NCg0KVGhpcyBpcyBob3cgaXQgKm11c3QqIHdvcmssIGFncmVlZDsgSSBy ZW1lbWJlciBkaXNjdXNzaW5nIHRoaXMgdG9waWMgYXQgb25lIG9mIHRoZSBXRyBtZWV0aW5ncywg c3BlY2lmaWNhbGx5Lg0KDQpJZiBpdCBzb21laG93IHdhcyBkcm9wcGVkLCB3ZSBuZWVkIHRvIGZp eCBpdC4gIEdhdGV3YXlzIGFyZSBhIG5lY2Vzc2FyeSBpbml0aWFsIGNhcGFiaWxpdHksIGFzIGlz IHByZXNlcnZpbmcgRE9UUyBjbGllbnQgSURzIGFjcm9zcyB0aGVtLg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5l dDxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pj4NCg== --_000_787AE7BB302AE849A7480A190F8B93300A0503FFOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVz IENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBk ZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglm b250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5S ZS0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SSBkaXNhZ3JlZSB3aXRo IHRoZSBmb2xsb3dpbmcmbmJzcDs6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBl IHN0cmluZzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7T3JpZ2luYWwgQ2xpZW50IElEIHJlcXVlc3Rpbmcg dGhlIG1pdGlnYXRpb24sIFJFUVVJUkVEIGFuZCBhZGRlZCB3aGVuIHBhc3NpbmcgdGhyb3VnaCBh IERPVFMgR2F0ZXdheS4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ QSBnYXRld2F5IG1heSBiZSBpbnN0cnVjdGVkIHRoZSByZXZlYWwgdGhlIG9yaWdpbmFsIGNsaWVu dCBpZGVudGl0eSBvbmx5IGluIHNvbWUgZGVwbG95bWVudHMgKG5vdCBhbGwpOyBvdGhlcndpc2Ug aXQgaXMgdGhlIGdhdGV3YXkgaWRlbnRpZnkgdGhhdCBpcyB1c2VkDQogYnkgdGhlIHJlbW90ZSBz ZXJ2ZXIuIFRoZSBnYXRld2F5IGlkZW50aXR5IGlzIGV4dHJhY3RlZCBmcm9tIHRoZSBhdXRoZW50 aWNhdGlvbiBjcmVkZW50aWFscy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5BIGNvbmZpZ3VyYWJsZSBwYXJhbWV0ZXIgdG8gZW5hYmxlL2Rpc2Fi bGUgdGhhdCB0aGUgb3JpZ2luYWwgY2xpZW50IGlkZW50aXR5IGlzIHBhc3NlZCwgbWF5IGJlIGNv bnNpZGVyZWQgKGRpc2FibGVkIGJ5IGRlZmF1bHQsIElNTykuIFRoZSBvcmlnaW5hbCBjbGllbnQN CiBpZGVudGl0eSBpcyB0aGVyZWZvcmUgb3B0aW9uYWwsIG5vdCBtYW5kYXRvcnkuICZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5C VFcsIGl0IG1heSBiZSB3b3J0aCB0byBjb25zaWRlciBhIGRlZGljYXRlZCBZQU5HIG1vZHVsZSBm b3IgRE9UUyBnYXRld2F5cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZu YnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9i PiBKb24gU2hhbGxvdzxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSA1IG9jdG9icmUg MjAxNyAxMzozNTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gJ0RvYmJpbnMsIFJvbGFuZCc7IDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZG90c0BpZXRmLm9yZzxicj4NCjxiPk9iamV0 Jm5ic3A7OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIHRoZSB1c2Ugb2Yg4oCcb3Jp Z2luYWwtY2xpZW50LWlk4oCdIGlzIGEgKjxiPm11c3Q8L2I+KiwgdGhlbiBJIHByb3Bvc2UgdGhl IGZvbGxvd2luZyBjaGFuZ2VzLiZuYnNwOyBJdCBpcyBkZWZpbmVkIGFzIGFuIGFycmF5IHNob3Vs ZCB0aGVyZSBiZSBhIGNsaWVudC1pZA0KIG5hbWUgY2xhc2ggYW5kIGEgc2Vjb25kIChvciBtb3Jl KSBlbnRyeSBuZWVkcyB0byBiZSBhZGRlZCBieSBhIERPVFMgR2F0ZXdheSBpbiBhIGxvbmcgY2hh aW4uJm5ic3A7IEluIG5vcm1hbCB1c2UsIGl0IGlzIGV4cGVjdGVkIHRoYXQgdGhlcmUgd2lsbCBv bmx5IGJlIG9uZSBlbnRyeSwgZXZlbiB0aG91Z2ggc2V2ZXJhbCBET1RTIEdhdGV3YXlzIGhhdmUg YmVlbiBwYXNzZWQgdGhyb3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhlIGZvbGxvd2luZyBZQU5HIGNoYW5nZXMgbmVlZCB0byBiZSBtYWRlIHRvIHRoZSBzaWduYWwg c3BlYyBhbmQgYXNzb2NpYXRlZCByZWZlcmVuY2VzIHVwZGF0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIFlBTkcgbW9kdWxlICZxdW90O2ll dGYtZG90cy1zaWduYWwmcXVvdDssIHdoaWNoIGhhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyB0aGUgZm9sbG93aW5nIHRyZWUgc3RydWN0dXJlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBtb2R1bGU6 IGlldGYtZG90cy1zaWduYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IG1pdGlnYXRpb24tc2NvcGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstLXJ3IHNjb3BlKiBbbWl0aWdhdGlvbi1pZF08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IG1pdGlnYXRpb24taWQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50MzI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IG9yaWdpbmFsLWNsaWVudC1p ZCombmJzcDsmbmJzcDsgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7LS1ydyB0YXJnZXQtaXAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6aXAtYWRkcmVzczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdGFyZ2V0LXByZWZpeCom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDppcC1wcmVmaXg8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLXJ3IHRhcmdldC1w b3J0LXJhbmdlKiBbbG93ZXItcG9ydCB1cHBlci1wb3J0XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBsb3dlci1wb3J0Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGluZXQ6cG9ydC1udW1iZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgdXBwZXItcG9ydCZuYnNwOyZuYnNwOyZuYnNwOyBpbmV0 OnBvcnQtbnVtYmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS1ydyB0YXJnZXQtcHJvdG9jb2wqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBmcWRuKiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmV0OmRvbWFpbi1uYW1lPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyB1cmkqJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6dXJpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBhbGlhcy1uYW1lKiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBz dHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGxp ZmV0aW1lPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQzMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNvbnRhaW5lciBtaXRpZ2F0aW9uLXNjb3BlIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVz Y3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VG9w IGxldmVsIGNvbnRhaW5lciBmb3IgYSBtaXRpZ2F0aW9uIHJlcXVlc3QuJnF1b3Q7OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsaXN0IHNjb3BlIHs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsga2V5IG1pdGlnYXRpb24taWQ7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uICZxdW90 O0lkZW50aWZpZXIgZm9yIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QuJnF1b3Q7OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIG1pdGlnYXRpb24taWQgezxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIGlu dDMyOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtNaXRpZ2F0aW9uIHJlcXVlc3QgaWRlbnRpZmllci4mcXVv dDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGlzdCBvcmlnaW5hbC1jbGllbnQtaWQgezxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBl IHN0cmluZzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7T3JpZ2luYWwgQ2xpZW50IElEIHJlcXVlc3Rpbmcg dGhlIG1pdGlnYXRpb24sIFJFUVVJUkVEIGFuZCBhZGRlZCB3aGVuIHBhc3NpbmcgdGhyb3VnaCBh IERPVFMgR2F0ZXdheS4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZi1saXN0IHRh cmdldC1pcCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHR5cGUgaW5ldDppcC1hZGRyZXNzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDtJUHY0IG9yIElQdjYgYWRkcmVzcyBpZGVudGlmeWluZyB0aGUgdGFyZ2V0LiZx dW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaWduYWwtY29uZmlnPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBzZXNzaW9uLWlkPyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQzMjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmIzQzOy0tcncgb3JpZ2luYWwtY2xpZW50LWlkKiZuYnNwOyZuYnNwOyBz dHJpbmcmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1ydyBoZWFydGJl YXQtaW50ZXJ2YWw/Jm5ic3A7Jm5ic3A7IGludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS1ydyBtaXNzaW5nLWhiLWFsbG93ZWQ/Jm5ic3A7Jm5ic3A7IGludDE2PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LS1ydyBtYXgtcmV0cmFuc21pdD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGFjay10aW1l b3V0PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWNrLXJhbmRvbS1mYWN0b3I/ Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlY2ltYWw2NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t cncgdHJpZ2dlci1taXRpZ2F0aW9uPyZuYnNwOyZuYnNwOyBCb29sZWFuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIHNpZ25hbC1jb25maWcgezxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtUb3AgbGV2ZWwgY29udGFpbmVyIGZvciBE T1RTIHNpZ25hbCBjaGFubmVsIHNlc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY29uZmlndXJhdGlvbi4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgc2Vzc2lvbi1pZCB7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgaW50MzI7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9uICZxdW90O0FuIGlk ZW50aWZpZXIgZm9yIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlc3Npb24gY29u ZmlndXJhdGlvbiBkYXRhLiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfSZuYnNwOw0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGlzdCBvcmlnaW5hbC1jbGllbnQtaWQgezxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIHN0cmluZzs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7 T3JpZ2luYWwgQ2xpZW50IElEIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24sIFJFUVVJUkVEIGFu ZCBhZGRlZCB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR2F0ZXdheS4mcXVvdDs7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgbGVhZiBoZWFydGJlYXQtaW50ZXJ2YWwgezxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRoZSBmb2xsb3dpbmcgWUFORyBjaGFuZ2VzIG5lZWQgdG8gYmUgbWFkZSB0byB0aGUg ZGF0YSBzcGVjIGFuZCBhc3NvY2lhdGVkIHJlZmVyZW5jZXMgdXBkYXRlZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBtb2R1 bGU6IGlldGYtZG90cy1kYXRhLWNoYW5uZWwtaWRlbnRpZmllcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgaWRlbnRp ZmllcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWxpYXMqIFthbGlhcy1uYW1lXTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWxpYXMtbmFt ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst LXJ3IG9yaWdpbmFsLWNsaWVudC1pZCombmJzcDsgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyB0YXJnZXQtaXAqJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6aXAtYWRkcmVz czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdGFyZ2V0 LXByZWZpeCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDppcC1wcmVm aXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHRhcmdl dC1wb3J0LXJhbmdlKiBbbG93ZXItcG9ydCB1cHBlci1wb3J0XTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBsb3dlci1wb3J0Jm5ic3A7Jm5i c3A7Jm5ic3A7IGluZXQ6cG9ydC1udW1iZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgdXBwZXItcG9ydCZuYnNwOyZuYnNwOyZuYnNwOyBp bmV0OnBvcnQtbnVtYmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7LS1ydyB0YXJnZXQtcHJvdG9jb2wqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBmcWRuKiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmV0OmRvbWFpbi1uYW1lPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyB1cmkqPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIGlkZW50aWZpZXIgezxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDt0b3AgbGV2ZWwgY29udGFpbmVyIGZvciBpZGVu dGlmaWVycyZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgbGlzdCBhbGlhcyB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGtleSBhbGlhcy1uYW1lOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtsaXN0IG9mIGlkZW50aWZpZXJzJnF1b3Q7Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBsZWFmIGFsaWFzLW5hbWUgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0eXBlIHN0cmluZzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7YWxpYXMgbmFtZSZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsaXN0IG9yaWdpbmFsLWNsaWVudC1pZCB7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgc3RyaW5nOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtPcmlnaW5h bCBDbGllbnQgSUQgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbiwgUkVRVUlSRUQgYW5kIGFkZGVk IHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHYXRld2F5LiZxdW90Ozs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmLWxpc3QgdGFyZ2V0LWlwIHs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdDphY2Nl c3MtbGlzdHMgaXMgbW9yZSBjb21wbGljYXRlZC4mbmJzcDsgV2l0aCB0aGUgaW50cm9kdWN0aW9u IG9mIOKAmGNvbnRhaW5lciBpbnRlcmZhY2Vz4oCZIGluIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1t b2RlbC0xNA0KIHRoZSB0ZXh0IGluIGdlbmVyYWwgaW4gZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hh bm5lbCBuZWVkcyB1cGRhdGluZy4mbmJzcDsgVGhpcyBjaGFuZ2UgaW4gZHJhZnQtaWV0Zi1uZXRt b2QtYWNsLW1vZGVsLTE0IGdpdmVzIHVzIHRoZSBhYmlsaXR5IHRvIGF0dGFjaCBhIHNwZWNpZmlj IHNldCBvZiBzb3J0ZWQgQUNMcyB0byBhbiBpbnRlcmZhY2UsIGJ1dCBzdGlsbCBkb2VzIG5vdCBl YXNpbHkgYXNzb2NpYXRlIGEgc2V0IG9mIEFDTCBkZWZpbml0aW9ucyB3aXRoDQogYSBwYXJ0aWN1 bGFyIGNsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgc3VnZ2Vz dGlvbiBpcyB0aGF0IHdlIGFkZCBpbiBhbiBhZGRpdGlvbmFsIEpTT04gZW50cnkgYXMgZm9sbG93 cywgd2l0aCB0aGUgWUFORyBtb2R1bGUgbW9kdWxlIGlldGYtZG90cy1hY2Nlc3MtY29udHJvbC1s aXN0IHVwZGF0ZWQgKG15IFlBTkcNCiBpcyBub3QgY3VycmVudGx5IHVwIHRvIGRvaW5nIHRoYXQp IHRoYXQgZGVmaW5lcyB3aGF0IHdlIGFyZSBkb2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyBQ T1NUIC9yZXN0Y29uZi9kYXRhL2lldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCBIVFRQLzEuMTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyBIb3N0Og0KPGEgaHJlZj0iaHR0cDovL3d3dy5leGFt cGxlLmNvbSI+d3d3LmV4YW1wbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyBDb250ZW50LUZvcm1hdDogJnF1b3Q7YXBwbGljYXRpb24veWFuZy5hcGkmIzQzO2pzb24mcXVv dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyAmcXVvdDtvcmlnaW5hbC1jbGllbnQtaWQmcXVvdDsgOiBbJnF1b3Q7c3Ry aW5nJnF1b3Q7IF0sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm cXVvdDtpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Q6YWNjZXNzLWxpc3RzJnF1b3Q7OiB7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Fj bCZxdW90OzogWzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQW5kIHNob3Vs ZCBub3Qgd2UgYmUgcG9zdGluZyB0byAvcmVzdGNvbmYvZGF0YS9pZXRmLTwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+ZG90czwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1h Y2Nlc3MtY29udHJvbC1saXN0DQogYW55d2F5P108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Kb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gRG90cyBbbWFpbHRvOg0KPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRm Lm9yZyI+ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mDQo8L2I+RG9i YmlucywgUm9sYW5kPGJyPg0KPGI+U2VudDo8L2I+IDA1IE9jdG9iZXIgMjAxNyAxMDo0Mjxicj4N CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVu Z2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxicj4NCk9uIE9j dCA1LCAyMDE3LCBhdCAxNDo1OCwgSm9uIFNoYWxsb3cgJmx0OzxhIGhyZWY9Im1haWx0bzpzdXBq cHMtaWV0ZkBqcHNoYWxsb3cuY29tIj5zdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+UGVyaGFwcyAmcXVvdDtvcmlnaW5hbC1jbGll bnQtaWQmcXVvdDsgd291bGQgYmUgYSBiZXR0ZXIgbmFtZSAtIGluIGEgc2ltaWxhciBzb3J0IG9m IHdheSB0aGF0IHRoZSAmcXVvdDtYLUZvcndhcmRpbmctRm9yOiZxdW90OyBoZWFkZXIgcHJvdmlk ZXMgdGhlIG9yaWdpbmFsIElQIG1ha2luZyB0aGUgSFRUUCByZXF1ZXN0IHdoZW4gcGFzc2luZyB0 aHJvdWdoIGEgbG9hZC1iYWxhbmNlciBvciBTU0wgdGVybWluYXRvci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoaXMgaXMgaG93IGl0ICptdXN0KiB3 b3JrLCBhZ3JlZWQ7IEkgcmVtZW1iZXIgZGlzY3Vzc2luZyB0aGlzIHRvcGljIGF0IG9uZSBvZiB0 aGUgV0cgbWVldGluZ3MsIHNwZWNpZmljYWxseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPklmIGl0IHNvbWVob3cgd2FzIGRyb3BwZWQsIHdlIG5lZWQg dG8gZml4IGl0LiAmbmJzcDtHYXRld2F5cyBhcmUgYSBuZWNlc3NhcnkgaW5pdGlhbCBjYXBhYmls aXR5LCBhcyBpcyBwcmVzZXJ2aW5nIERPVFMgY2xpZW50IElEcyBhY3Jvc3MgdGhlbS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBsYW5nPSJFTi1HQiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPlJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3Iu bmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93300A0503FFOPEXCLILMA3corp_-- From nobody Fri Oct 6 06:08:15 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FAC13306F for ; Fri, 6 Oct 2017 06:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 at9Lw5dyv2Xr for ; Fri, 6 Oct 2017 06:08:03 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 2E7791349B5 for ; Fri, 6 Oct 2017 06:08:03 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507295282; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=8 JATyeet1lf9Wz1jSqepE9J0v//c9mYkfG3QJQSI/s o=; b=Y5vipz/+AKvfO4k8x2RGPI4GRn17KkV3L0AXpzFatE2c 7czyKc9A+q2b1LfAe/JT2Z9i//ONc2hGqdh8mHGqZbBxCGN5pg dzQCSLfbH3wdGv58XiLQInScxWjFwu70JCZAq4m8q8HuYJPqjY fki7PI6994PsGOh8SbQcjwDhd9I= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 58ca_a0c1_2966595c_67d0_48be_ad6c_3e34ac2e3098; Fri, 06 Oct 2017 08:08:01 -0500 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 09:07:59 -0400 Received: from MIVEX10N02.corpzone.internalzone.com (10.48.48.170) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Oct 2017 09:07:59 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEX10N02.corpzone.internalzone.com (10.48.48.170) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 6 Oct 2017 09:07:59 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 09:07:57 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 6 Oct 2017 13:07:56 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.018; Fri, 6 Oct 2017 13:07:56 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AdM866F1exiXOD0RS+2TvvngfvHPNAAHYE+AAC3w14AALEpYgAALE5ww Date: Fri, 6 Oct 2017 13:07:56 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A050387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A050387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.90.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:VJe9/tBWT+1tOaoGtrjdUBlcAgGRiow4LgyaQ4Yb0RYJzQx/085SydUOa8VSGi1n6YEBsmQzS5+eK12a+1FjncNx7+SNy7m0hDzb5GdoKOVZFW2V2faVSAgJs4bqpuPqUGVrgmtXG6n/iernnM7k2EKqhJUZhctqat7DsgPGSFv3q4jMQvYcK2KZqHLevs3THX38rlqR1B4ZSj9m2a8admz4AsgUIPCM0vYOzLiSEEpLnCT26jtzhWNAI1krUzx4KhcfPB2X4Y6pN7je+j1ZSG3dvnZ0S/8NY/BII7YCay9wqQfc8Ega8o/w1rnYnui2XUE95N2i16r/vVuuIwWtWQ==; 5:s127/hDaqrq+zjGkFx6pLlcWy8JCrRkYGeBEI0LJwcu/Oe/mIs9TmGy/dMh94GWrb77jAg8W17FjjBJCDcSXMxGHax7AiwAdAVdmH5IvIU3AthOJgzK+zQN64COsgnOvWzDJxza7LGjWFpg1x2dUXQ==; 24:T+p9wybFUd+8zVxAnS3fG0W/N3tWjX9Jw9Jj46j78B9HGM3bwA6EpaKKpKcanlMb+fFuUjxKotwRiodIdbxfpNi/asSv5+JWhNCKztI6Zqs=; 7:Ab67FDKIP83S3pJKYIVtutr59nrJlWQbP9U7lrvOsf2VB+6WWK3VVIYzUDlLKz+En1wJ+FTDGCjk4o04DpdsE4tKWh0mJ74zaLHaBnniij9MWsPYH3Om1Mu1ZmISfgxFtMJIH9Rdf4RZf7vRCKYlGyNGOPyNuNp7hCTLPRD2fZYpYimQd1APGkeuoEmJtfg2JBd8e1WLe4TPdmpWxjM1b1nr+TL6dj03YsvCasThFGM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ec275c08-4c4a-4495-221e-08d50cbb4329 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0452022BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(377454003)(199003)(189002)(32952001)(6506006)(110136005)(966005)(102836003)(19609705001)(7696004)(2950100002)(9326002)(68736007)(478600001)(5660300001)(316002)(54356999)(3660700001)(53546010)(2906002)(97736004)(3280700002)(50986999)(76176999)(3846002)(72206003)(14454004)(2501003)(80792005)(790700001)(93886005)(9686003)(6116002)(2900100001)(7736002)(6306002)(229853002)(55016002)(6436002)(54896002)(189998001)(101416001)(25786009)(6246003)(606006)(33656002)(66066001)(236005)(81166006)(77096006)(53946003)(86362001)(74316002)(106356001)(8676002)(53936002)(105586002)(81156014)(8936002)(99286003)(562404015)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788BEFC11F0E6FC0858524CEA710DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2017 13:07:56.6730 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6131> : inlines <6111> : streams <1766092> : uri <2512186> Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 13:08:07 -0000 --_000_DM5PR16MB1788BEFC11F0E6FC0858524CEA710DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, Please see inline [TR] From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, October 6, 2017 12:40 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval Hi Tiru, all, Please see inline. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 5 octobre 2017 12:54 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Minimum heartbeat-interval http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). [Med] You are right about the configurable aspect, but the question from Jo= n is a good one. I interpret it in another way: - Should we rely solely on the missing-hb-allowed to detect a session pro= blem? [TR] If the DOTS agent does not receive a response to "CoAP ping" but recei= ves other type of messages from the peer DOTS agent then a counter incremen= ted each time there is no response to a "CoAP ping" till the counter value = hits missing-hb-allowed to determine the session is defunct can be reset to= zero. - Should we get rid of missing-hb-allowed, but rely on the retransmission= to declare failure or not? [TR] If DOTS agents only rely on the retransmission mechanism then a "CoAP = ping" message will only be retransmitted 4 times before concluding the sess= ion is disconnected in an interval of 93 seconds. The network under DDoS at= tack is likely to be congested (high packet loss and latency), hence missin= g-hb-allowed is used to send the "CoAP ping" more number of times (3 (ping)= + 3*4 (re-transmissions) =3D 15 times) with sufficient time interval (93*3= =3D 279 seconds) to determine the session is defunct. - What is the advantage of cumulating both missing-hb-allowed and the ret= ransmission procedure to declare a channel out? [TR] Please see above. 2) No, [Med] I agree that a heartbeat does not need to be fired when the first pin= g is still alive. We can clarify this in the draft. [TR] Thanks. if the DOTS agent wants to change the default heartbeat interval then the o= ther message transmission parameters will also have to be modified. [Med] I disagree here that the other parameters need to be changed. I don't= see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree= that we need to tweak heartbeat-interval as a function of MAX_TRANSMIT_WAI= T). As you know, MAX_TRANSMIT_WAIT can be derived from other parameters (AC= K_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR)). This i= s why it does not make sense to provide a configuration for MAX_TRANSMIT_WA= IT if the other parameters are provided. [TR] I did not get the above, the draft is not providing any new configurat= ion for MAX_TRANSMIT_WAIT. If let's say the DOTS agents decide to change th= e heartbeat interval to 45 seconds then the max-retransmit has to be change= d to 3 to arrive at 45 second MAX_TRANSMIT_WAIT value (or other message tra= nsmission parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be changed to= arrive at the new heartbeat interval). How can the heartbeat interval chan= ge without changing the message transmission parameters ? -Tiru 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med --_000_DM5PR16MB1788BEFC11F0E6FC0858524CEA710DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

&nbs= p;

Please se= e inline [TR]

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, October 6, 2017 12:40 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] Minimum heartbeat-interval

 

Hi Tiru, all,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com<= span style=3D"font-size:10.0pt;font-family:"Tahoma",sans-serif;ms= o-fareast-language:FR">]
Envoy=E9 : jeudi 5 octobre 2017 12:54
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Minimum heartbeat-interval=

 

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html= /rfc7925 has tested NAT behavior with various routers and lists the tim= eout results. The majority of the devices (62%) have a timeout between 2 an= d 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is = 54 seconds.

 

Responses to the questions below

 

1) The max-retransmit parameter is negotiable and configurable,&nbs= p; DOTS agents can pick suitable values for max-retransmit parameter based = on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).

 

[Med] You are right= about the configurable aspect, but the question from Jon is a good one. I = interpret it in another way:

-Should we rely solely on the missing-hb-allowed to detect a s= ession problem?

&nbs= p;

[TR] If t= he DOTS agent does not receive a response to “CoAP ping” but re= ceives other type of messages from the peer DOTS agent then a counter incre= mented each time there is no response to a “CoAP ping” till the counter value hits missing-hb-allowed to determine th= e session is defunct can be reset to zero.

&nbs= p;

-Should we get rid of missing-hb-allowed, but rely on the retr= ansmission to declare failure or not?

&nbs= p;

[TR] If D= OTS agents only rely on the retransmission mechanism then a “CoAP pin= g” message will only be retransmitted 4 times before concluding the s= ession is disconnected in an interval of 93 seconds. The network under DDoS attack is likely to be congested (high packet loss = and latency), hence missing-hb-allowed is used to send the “CoAP ping= ” more number of times (3 (ping) + 3*4 (re-transmissions) =3D 15 = times) with sufficient time interval (93*3 =3D 279 seconds) to determine the session is defunct.

&nbs= p;

-What is the advantage of cumulating both missing-hb-allowed a= nd the retransmission procedure to declare a channel out?

&nbs= p;

[TR] Plea= se see above.

 

2) No,

[Med] I agree that = a heartbeat does not need to be fired when the first ping is still alive. W= e can clarify this in the draft.

&nbs= p;

[TR] Than= ks.

 

if the DOTS agent wants to change the default heartbeat interval th= en the other message transmission parameters will also have to be modified.

[Med] I disagree he= re that the other parameters need to be changed. I don’t see heartbea= t-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree that we need to tweak heartbeat-interval as a function of MAX_T= RANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from other par= ameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_F= ACTOR)). This is why it does not make sense to provide a configuration for MAX_TRANSMIT_WAIT if the other parame= ters are provided.

&nbs= p;

[TR] I di= d not get the above, the draft is not providing any new configuration for M= AX_TRANSMIT_WAIT. If let’s say the DOTS agents decide to change the h= eartbeat interval to 45 seconds then the max-retransmit has to be changed to 3 to arrive at 45 second MAX_TRANSMIT_WAIT value (or = other message transmission parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have= to be changed to arrive at the new heartbeat interval). How can the heartb= eat interval change without changing the message transmission parameters ?

&nbs= p;

-Tiru

&nbs= p;

 

3) The client will have to assume the session is disconnected (see = the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The he= artbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 

Med – In the below text, recommended value should be 93 secon= ds instead of 90 seconds (see https://tools= .ietf.org/html/rfc7252#section-4.8.2).

 

-Tiru<= /span>

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

&n= bsp;

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

&n= bsp;

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

&n= bsp;

Oct 04 10:53:51 DEBG sending C= oAP ping:

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to re= transmit queue (2281ms)

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:53:51 ALRT got RST f= or message 29548

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending C= oAP ping:

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to re= transmit queue (2938ms)

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:07 ALRT got RST f= or message 29549

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending C= oAP ping:

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to re= transmit queue (2156ms)

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:23 ALRT got RST f= or message 29550

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending C= oAP ping:

Oct 04 10:54:39 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to re= transmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #1

Oct 04 10:54:42 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #2

Oct 04 10:54:48 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #3

Oct 04 10:55:00 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #4

Oct 04 10:55:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up af= ter 4 attempts

&n= bsp;

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

&n= bsp;

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

&n= bsp;

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

&n= bsp;

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

&n= bsp;

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Scenari= o as Q3

&n= bsp;

Does th= e client re-use the old session that the heartbeats are failing on?

- The s= erver may have sent a session close, but it never got through

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

&n= bsp;

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

&n= bsp;

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow = (supjps-ietf@jpshallow.com= )
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during the interim meeting:= “A: (Jon Shallow): The minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with RFC8085 which= says the following:

 

   An application that needs to employ kee=
p-alive messages to deliver
   useful service over UDP in the presence=
 of middleboxes SHOULD NOT
        &nbs=
p;            &=
nbsp;           &nbs=
p;            ^^^^^^=
^^^^^^^^^^^^^^^^
   transmit them more frequently than once=
 every 15 seconds and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   use longer intervals when possible.&nbs=
p;

 

I suggest to add this NEW text to the signal-channel draft= to clarify the rationale for the recommended values:

 

NEW:

    &= nbsp; Note: heartbeat-interval should be tweaked to also assist DOTS

    &= nbsp; messages for NAT traversal (SIG-010 of

    &= nbsp; [I-D.ietf-dots-requirements]).  According to [RFC8085], keepaliv= e

    &= nbsp; messages must not be sent more frequently than once every 15

    &= nbsp; seconds and should use longer intervals when possible.

    &= nbsp; Furthermore, [RFC4787] recommends NATs to use a state timeout of 2

    &= nbsp; minutes or longer.  From that standpoint, this specification

    &= nbsp; recommends a minimum heartbeat-interval of 15 seconds and a

    &= nbsp; maximum heartbeat-interval of 240 seconds.  The recommended valu= e

    &= nbsp; of 90 seconds is selected to anticipate the expiry of NAT states,

    &= nbsp; while avoiding overloading the network with frequent keepalives<= /o:p>

    &= nbsp; for NAT state maintenance purposes.  Note that this recommended<= o:p>

    &= nbsp; value is close to the one recommended for MAX_TRANSMIT_WAIT, whose

    &= nbsp; value is derived from transmission parameters (Section 4.8.2 of<= /o:p>

      [RFC7252]).

 

Thoughts?

 

Cheers,

Med

--_000_DM5PR16MB1788BEFC11F0E6FC0858524CEA710DM5PR16MB1788namp_-- From nobody Fri Oct 6 06:42:31 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D081349C2 for ; Fri, 6 Oct 2017 06:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgZipNO3N3vk for ; Fri, 6 Oct 2017 06:42:21 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93DE1349B9 for ; Fri, 6 Oct 2017 06:42:20 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 13329608B5; Fri, 6 Oct 2017 15:42:19 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id E3EC1C0052; Fri, 6 Oct 2017 15:42:18 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0361.001; Fri, 6 Oct 2017 15:42:18 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AQHTPqjtwyXuulbHFUeXQsYA/9BH5A== Date: Fri, 6 Oct 2017 13:42:17 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0506A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A050387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0506A0OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 13:42:30 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0506A0OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tiru, We are on the same page for (1). I hope we will hear more voices on this be= fore we add some text to the draft to clarify missing points. Please see inline for (2). Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 6 octobre 2017 15:08 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] Minimum heartbeat-interval Hi Med, Please see inline [TR] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, October 6, 2017 12:40 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval Hi Tiru, all, Please see inline. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 5 octobre 2017 12:54 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Minimum heartbeat-interval http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). [Med] You are right about the configurable aspect, but the question from Jo= n is a good one. I interpret it in another way: - Should we rely solely on the missing-hb-allowed to detect a session pro= blem? [TR] If the DOTS agent does not receive a response to "CoAP ping" but recei= ves other type of messages from the peer DOTS agent then a counter incremen= ted each time there is no response to a "CoAP ping" till the counter value = hits missing-hb-allowed to determine the session is defunct can be reset to= zero. - Should we get rid of missing-hb-allowed, but rely on the retransmission= to declare failure or not? [TR] If DOTS agents only rely on the retransmission mechanism then a "CoAP = ping" message will only be retransmitted 4 times before concluding the sess= ion is disconnected in an interval of 93 seconds. The network under DDoS at= tack is likely to be congested (high packet loss and latency), hence missin= g-hb-allowed is used to send the "CoAP ping" more number of times (3 (ping)= + 3*4 (re-transmissions) =3D 15 times) with sufficient time interval (93*3= =3D 279 seconds) to determine the session is defunct. - What is the advantage of cumulating both missing-hb-allowed and the ret= ransmission procedure to declare a channel out? [TR] Please see above. 2) No, [Med] I agree that a heartbeat does not need to be fired when the first pin= g is still alive. We can clarify this in the draft. [TR] Thanks. if the DOTS agent wants to change the default heartbeat interval then the o= ther message transmission parameters will also have to be modified. [Med] I disagree here that the other parameters need to be changed. I don't= see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree= that we need to tweak heartbeat-interval as a function of MAX_TRANSMIT_WAI= T). As you know, MAX_TRANSMIT_WAIT can be derived from other parameters (AC= K_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR)). This i= s why it does not make sense to provide a configuration for MAX_TRANSMIT_WA= IT if the other parameters are provided. [TR] I did not get the above, the draft is not providing any new configurat= ion for MAX_TRANSMIT_WAIT [Med] I was talking about heartbeat-interval. . If let's say the DOTS agents decide to change the heartbeat interval to 4= 5 seconds then the max-retransmit has to be changed to 3 to arrive at 45 se= cond MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_= TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new heartb= eat interval). [Med] My comment is that if heartbeat-interval was dependent on transmissio= n parameters, then we do not need to configure it explicitly IN ADDITION to= the other transmission parameter. How can the heartbeat interval change without changing the message transmis= sion parameters ? [Med] I do see these two as separate parameters. The heartbeat-interval det= ermines the frequency of sending keeplaive messages. This is an additional = transmission parameter specific to heartbeat if you will. -Tiru 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0506A0OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Tiru,

 

We are on the same page for (1). I hope we will hear more voices on this before = we add some text to the draft to clarify missing points.

 

Please see inline for (2).=

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 6 octobre 2017 15:08
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] Minimum heartbeat-interval=

 

Hi Med,

 

Please see inline [TR]

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, October 6, 2017 12:40 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] Minimum heartbeat-interval

 

Hi Tiru, all,

 

Please see inline.

 

Cheers,

Med

 

K= onda, Tirumaleswar Reddy [mailto:TirumaleswarReddy= _Konda@McAfee.com]
Envoy=E9 : jeudi 5 octobre 2017 12:54
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Minimum heartbeat-interval=

 

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf= referenced by https://tools.ietf.org/html= /rfc7925 has tested NAT behavior with various routers and lists the tim= eout results. The majority of the devices (62%) have a timeout between 2 an= d 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is = 54 seconds.

 

Responses to the questions below

 

1) The max-retransmit parameter is negotiable and co= nfigurable,  DOTS agents can pick suitable values for max-retransmit p= arameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).=

 

[Med= ] You are right about the configurable aspect, but the question from Jon is= a good one. I interpret it in another way:

-   Should we rely solel= y on the missing-hb-allowed to detect a session problem?<= /p>

 

[TR] If the DOTS agent does not receive a response to “CoAP pin= g” but receives other type of messages from the peer DOTS agent then = a counter incremented each time there is no response to a “CoAP ping” till the counter value hits missing-hb-allowe= d to determine the session is defunct can be reset to zero.

-   Should we get rid of= missing-hb-allowed, but rely on the retransmission to declare failure or n= ot?

 

[TR] If DOTS agents only rely on the retransmission mechanism then a = “CoAP ping” message will only be retransmitted 4 times before c= oncluding the session is disconnected in an interval of 93 seconds. The network under DDoS attack is likely to be congested (hi= gh packet loss and latency), hence missing-hb-allowed is used to send the &= #8220;CoAP ping” more number of times (3 (ping) + 3*4 (re-transmi= ssions) =3D 15 times) with sufficient time interval (93*3 =3D 279 seconds) to determine the session is defunct.

 

-   What is the advantag= e of cumulating both missing-hb-allowed and the retransmission procedure to= declare a channel out?

 

[TR] Please see above.

 

2) No,=

[Med= ] I agree that a heartbeat does not need to be fired when the first ping is= still alive. We can clarify this in the draft.

 

[TR] Thanks.

 

if the DOTS agent wants to change the default heartb= eat interval then the other message transmission parameters will also have = to be modified.

[Med= ] I disagree here that the other parameters need to be changed. I don’= ;t see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree that we need to tweak heartbeat-interval as a function of= MAX_TRANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from oth= er parameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RA= NDOM_FACTOR)). This is why it does not make sense to provide a configuration for MAX_TRANSMIT_WAIT if the other p= arameters are provided.

 

[TR] I did not get the above, the draft is not providing any new conf= iguration for MAX_TRANSMIT_WAIT

[Med= ] I was talking about heartbeat-interval.<= /span>

 

. If let’s say the DOTS agents decide to change the heartbeat i= nterval to 45 seconds then the max-retransmit has to be changed to 3 to arr= ive at 45 second MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR hav= e to be changed to arrive at the new heartbeat interval).

[Med= ] My comment is that if heartbeat-interval was dependent on transmission pa= rameters, then we do not need to configure it explicitly IN ADDITION to the other transmission parameter.  <= /p>

 

How can the heartbeat interval change without changing the message tr= ansmission parameters ?

[Med= ] I do see these two as separate parameters. The heartbeat-interval determi= nes the frequency of sending keeplaive messages. This is an additional transmission parameter specific to heartbeat if you = will.

 

-Tiru

 

 

3) The client will have to assume the session is dis= connected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will cl= ose the (D)TLS session, the client will have to initiate (D)TLS session res= umption. The heartbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 

Med – In the below text, recommended value sho= uld be 93 seconds instead of 90 seconds (see https://tools= .ietf.org/html/rfc7252#section-4.8.2).

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

&n= bsp;

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

&n= bsp;

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

&n= bsp;

Oct 04 10:53:51 DEBG sending C= oAP ping:

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to re= transmit queue (2281ms)

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:53:51 ALRT got RST f= or message 29548

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending C= oAP ping:

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to re= transmit queue (2938ms)

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:07 ALRT got RST f= or message 29549

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending C= oAP ping:

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to re= transmit queue (2156ms)

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:23 ALRT got RST f= or message 29550

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending C= oAP ping:

Oct 04 10:54:39 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to re= transmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #1

Oct 04 10:54:42 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #2

Oct 04 10:54:48 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #3

Oct 04 10:55:00 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #4

Oct 04 10:55:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up af= ter 4 attempts

&n= bsp;

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

&n= bsp;

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

&n= bsp;

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

&n= bsp;

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

&n= bsp;

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Scenari= o as Q3

&n= bsp;

Does th= e client re-use the old session that the heartbeats are failing on?

- The s= erver may have sent a session close, but it never got through

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

&n= bsp;

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

&n= bsp;

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto:ietf-sup= jps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow = (supjps-ietf@jpshallow.com= )
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during the i= nterim meeting: “A: (Jon Shallow): The minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned wit= h RFC8085 which says the following:

 

   An application that need=
s to employ keep-alive messages to deliver
   useful service over UDP =
in the presence of middleboxes SHOULD NOT
      &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;  ^^^^^^^^^^^^^^^^^^^^^^
   transmit them more frequ=
ently than once every 15 seconds and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   use longer intervals whe=
n possible. 

 

I suggest to add this NEW text to the signa= l-channel draft to clarify the rationale for the recommended values:

 

NEW:

 &nbs= p;    Note: heartbeat-interval should be tweaked to also ass= ist DOTS

 &nbs= p;    messages for NAT traversal (SIG-010 of

 &nbs= p;    [I-D.ietf-dots-requirements]).  According to [RFC= 8085], keepalive

 &nbs= p;    messages must not be sent more frequently than once ev= ery 15

 &nbs= p;    seconds and should use longer intervals when possible.=

 &nbs= p;    Furthermore, [RFC4787] recommends NATs to use a state = timeout of 2

 &nbs= p;    minutes or longer.  From that standpoint, this sp= ecification

 &nbs= p;    recommends a minimum heartbeat-interval of 15 seconds = and a

 &nbs= p;    maximum heartbeat-interval of 240 seconds.  The r= ecommended value

 &nbs= p;    of 90 seconds is selected to anticipate the expiry of = NAT states,

 &nbs= p;    while avoiding overloading the network with frequent k= eepalives

 &nbs= p;    for NAT state maintenance purposes.  Note that th= is recommended

 &nbs= p;    value is close to the one recommended for MAX_TRANSMIT= _WAIT, whose

 &nbs= p;    value is derived from transmission parameters (Section= 4.8.2 of

      [RFC7252]).

 

Thoughts?

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A0506A0OPEXCLILMA3corp_-- From nobody Fri Oct 6 06:58:04 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324871349CF for ; Fri, 6 Oct 2017 06:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 aNy_bV5ZWJqY for ; Fri, 6 Oct 2017 06:57:59 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 3DAE01349CE for ; Fri, 6 Oct 2017 06:57:59 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507298261; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-exchange-antispam-report-test:x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=f 7sgF524gZBkfeH//jrhQdC39WND+rshax5AVfDpk1 I=; b=iFqj8no8xuso+PUtmW0x9jt2SjMjZStJdXz7KorlZ9Uf KTPns0+dsMXToKgPyul2koNKs9tkyL3QdjO4rNM8xvhXtte56h CR8cv9UE8Y/nHLy1YQ5xQvsuutKmldXIxVM3s+M+gxN+FL2YVE s7HoU0ZZRo+bj41Kj3JdHH58MNE= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 58c2_38ec_fba549f0_ebab_4fe8_8ea8_4913626d2ebc; Fri, 06 Oct 2017 08:57:39 -0500 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 09:57:37 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Oct 2017 09:57:37 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 09:57:36 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 6 Oct 2017 13:57:34 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.018; Fri, 6 Oct 2017 13:57:34 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "'Dobbins, Roland'" , "dots@ietf.org" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oA== Date: Fri, 6 Oct 2017 13:57:34 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.171.90.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:SC/efGHue84VCmQzpsOXsDgDvfsDn4MTdiFZp261/CByEtIvPGexWifuxeHxHgcl8NUQHpaEYgo6WfnVgA6xV6/iwFNX0kGxYuFfitfV6XgDplbQMChuYu5Nfd+ycw4DhAQiDQfytidtlbt5Qx8KAuGntDLz/tahtgai52IRmtnWmdKdOKIJXVFPnWGlZI2ab/HPmiHQDlf9QVozasyJPahPkNLA/ium/WAKtFe924ECejZKLf1ih/kVDzC0X89K3pdJ+ha3zHT3cjMONpZLXv757p8Psp7bOAz5URs+S0NGBuClDSq5OLQG0sF1qtQ4c5rSILxC17B6LuoB7VOBzQ==; 5:cE5Nf78zKATlWn+F5SUNUYyjqySPHFO1C6rKVT6n4gSLsz98L8tV2QbIfrzo2VNFaM2ERuUAVVpV4oAbAimbVlQdEaogO6Z93UXAk3Dwk9AMJKxv06pnRw1X2WS9Mq1gdaAJjV0dyuZTHuVCFmIILg==; 24:eI2WoDj8T0/Cg00Ia9f4BTqSG7FNdjsCn+ubT+PPBntEOr5DtmVXU9svhQ6KPsS6/7r/BiBTbB+zxKje9z2d+gon+2sL8E5KA6vfw08pTIo=; 7:koMJohLUj6TaGaKTTP6qQbhDrdZ5WdW5x9Co2Vt/PUOutKuNezlNQZj5kKd44aKLvdt96NzuO4ov2cqmskeGRYNVnA08K3HfmC0ycT/Pd6e7nhE0tckZNV/uNWW3t+BpYJCrQr4vEj7O7ZWJc9RiysWx5WN9/lYlvi/GGfyf1ezWMerrl+2OlM2qcGYxu98usl7w0a2D7wfVzR50E4xAbnojE5ecAVmQbgtxSQespPc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a0ad5c42-7998-421a-ca32-08d50cc2324b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(79290750141951); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0452022BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(189002)(32952001)(199003)(377454003)(24454002)(229853002)(97736004)(3280700002)(2950100002)(53936002)(55016002)(110136005)(2906002)(86362001)(14454004)(53946003)(606006)(80792005)(53546010)(790700001)(236005)(102836003)(7696004)(53386004)(3846002)(99286003)(6116002)(9686003)(6246003)(316002)(3660700001)(33656002)(72206003)(5890100001)(6436002)(105586002)(101416001)(68736007)(106356001)(54356999)(6306002)(93886005)(81166006)(8936002)(54896002)(77096006)(7736002)(6506006)(74316002)(81156014)(50986999)(76176999)(8676002)(25786009)(1680700002)(19609705001)(2900100001)(189998001)(66066001)(5660300001)(478600001)(2501003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788BA6C11EF781C7702AE3EEA710DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2017 13:57:34.8403 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6131> : inlines <6111> : streams <1766097> : uri <2512206> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 13:58:02 -0000 --_000_DM5PR16MB1788BA6C11EF781C7702AE3EEA710DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHNlZSBhIG5lZWQgZm9yIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252 ZXkgdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4g4oCc RE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gbG9va3MgcmVxdWlyZWQgb25seSBmb3IgdGhlIHNlcnZl ci1zaWRlIERPVFMgZ2F0ZXdheXMuIEluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5 LCBpdCBjYW4gY29udmV5IHRoZSBjbGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMg Y2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBj YW4gZ2VuZXJhdGUgYSB1bmlxdWUgY2xpZW50LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQg YW4gYXJyYXkgb2YgY2xpZW50LWlkcyB0byB0aGUgRE9UUyBzZXJ2ZXIgdG8gcmVzb2x2ZSBjbGFz aGVzLg0KDQotVGlydQ0KDQpGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KU2VudDogRnJpZGF5 LCBPY3RvYmVyIDYsIDIwMTcgMTowNyBQTQ0KVG86IEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tPjsgJ0RvYmJpbnMsIFJvbGFuZCcgPHJkb2JiaW5zQGFyYm9yLm5ldD47IGRv dHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2Vz DQoNClJlLSwNCg0KSSBkaXNhZ3JlZSB3aXRoIHRoZSBmb2xsb3dpbmcgOg0KDQogICAgICAgICAg ICAgICAgdHlwZSBzdHJpbmc7DQogICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIk9yaWdpbmFs IENsaWVudCBJRCByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uLCBSRVFVSVJFRCBhbmQgYWRkZWQg d2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdhdGV3YXkuIjsNCiAgICAgICAgICAgICB9DQoN CkEgZ2F0ZXdheSBtYXkgYmUgaW5zdHJ1Y3RlZCB0aGUgcmV2ZWFsIHRoZSBvcmlnaW5hbCBjbGll bnQgaWRlbnRpdHkgb25seSBpbiBzb21lIGRlcGxveW1lbnRzIChub3QgYWxsKTsgb3RoZXJ3aXNl IGl0IGlzIHRoZSBnYXRld2F5IGlkZW50aWZ5IHRoYXQgaXMgdXNlZCBieSB0aGUgcmVtb3RlIHNl cnZlci4gVGhlIGdhdGV3YXkgaWRlbnRpdHkgaXMgZXh0cmFjdGVkIGZyb20gdGhlIGF1dGhlbnRp Y2F0aW9uIGNyZWRlbnRpYWxzLg0KDQpBIGNvbmZpZ3VyYWJsZSBwYXJhbWV0ZXIgdG8gZW5hYmxl L2Rpc2FibGUgdGhhdCB0aGUgb3JpZ2luYWwgY2xpZW50IGlkZW50aXR5IGlzIHBhc3NlZCwgbWF5 IGJlIGNvbnNpZGVyZWQgKGRpc2FibGVkIGJ5IGRlZmF1bHQsIElNTykuIFRoZSBvcmlnaW5hbCBj bGllbnQgaWRlbnRpdHkgaXMgdGhlcmVmb3JlIG9wdGlvbmFsLCBub3QgbWFuZGF0b3J5Lg0KDQpC VFcsIGl0IG1heSBiZSB3b3J0aCB0byBjb25zaWRlciBhIGRlZGljYXRlZCBZQU5HIG1vZHVsZSBm b3IgRE9UUyBnYXRld2F5cy4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogRG90cyBbbWFpbHRvOmRv dHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKb24gU2hhbGxvdw0KRW52b3nDqSA6 IGpldWRpIDUgb2N0b2JyZSAyMDE3IDEzOjM1DQrDgCA6ICdEb2JiaW5zLCBSb2xhbmQnOyBkb3Rz QGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW0RvdHNdIERPVFMg R2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpBcyB0aGUgdXNlIG9mIOKAnG9yaWdpbmFsLWNsaWVudC1p ZOKAnSBpcyBhICptdXN0KiwgdGhlbiBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBjaGFuZ2VzLiAg SXQgaXMgZGVmaW5lZCBhcyBhbiBhcnJheSBzaG91bGQgdGhlcmUgYmUgYSBjbGllbnQtaWQgbmFt ZSBjbGFzaCBhbmQgYSBzZWNvbmQgKG9yIG1vcmUpIGVudHJ5IG5lZWRzIHRvIGJlIGFkZGVkIGJ5 IGEgRE9UUyBHYXRld2F5IGluIGEgbG9uZyBjaGFpbi4gIEluIG5vcm1hbCB1c2UsIGl0IGlzIGV4 cGVjdGVkIHRoYXQgdGhlcmUgd2lsbCBvbmx5IGJlIG9uZSBlbnRyeSwgZXZlbiB0aG91Z2ggc2V2 ZXJhbCBET1RTIEdhdGV3YXlzIGhhdmUgYmVlbiBwYXNzZWQgdGhyb3VnaC4NCg0KVGhlIGZvbGxv d2luZyBZQU5HIGNoYW5nZXMgbmVlZCB0byBiZSBtYWRlIHRvIHRoZSBzaWduYWwgc3BlYyBhbmQg YXNzb2NpYXRlZCByZWZlcmVuY2VzIHVwZGF0ZWQNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVz IHRoZSBZQU5HIG1vZHVsZSAiaWV0Zi1kb3RzLXNpZ25hbCIsIHdoaWNoIGhhcw0KICAgdGhlIGZv bGxvd2luZyB0cmVlIHN0cnVjdHVyZToNCg0KICAgbW9kdWxlOiBpZXRmLWRvdHMtc2lnbmFsDQog ICAgICAgKy0tcncgbWl0aWdhdGlvbi1zY29wZQ0KICAgICAgICAgICstLXJ3IHNjb3BlKiBbbWl0 aWdhdGlvbi1pZF0NCiAgICAgICAgICAgICArLS1ydyBtaXRpZ2F0aW9uLWlkICAgICAgICAgaW50 MzINCiAgICAgICAgICAgICArLS1ydyBvcmlnaW5hbC1jbGllbnQtaWQqICAgc3RyaW5nDQogICAg ICAgICAgICAgKy0tcncgdGFyZ2V0LWlwKiAgICAgICAgICAgIGluZXQ6aXAtYWRkcmVzcw0KICAg ICAgICAgICAgICstLXJ3IHRhcmdldC1wcmVmaXgqICAgICAgICBpbmV0OmlwLXByZWZpeA0KICAg ICAgICAgICAgICstLXJ3IHRhcmdldC1wb3J0LXJhbmdlKiBbbG93ZXItcG9ydCB1cHBlci1wb3J0 XQ0KICAgICAgICAgICAgIHwgICstLXJ3IGxvd2VyLXBvcnQgICAgaW5ldDpwb3J0LW51bWJlcg0K ICAgICAgICAgICAgIHwgICstLXJ3IHVwcGVyLXBvcnQgICAgaW5ldDpwb3J0LW51bWJlcg0KICAg ICAgICAgICAgICstLXJ3IHRhcmdldC1wcm90b2NvbCogICAgICB1aW50OA0KICAgICAgICAgICAg ICstLXJ3IGZxZG4qICAgICAgICAgICAgICAgICBpbmV0OmRvbWFpbi1uYW1lDQogICAgICAgICAg ICAgKy0tcncgdXJpKiAgICAgICAgICAgICAgICAgIGluZXQ6dXJpDQogICAgICAgICAgICAgKy0t cncgYWxpYXMtbmFtZSogICAgICAgICAgIHN0cmluZw0KICAgICAgICAgICAgICstLXJ3IGxpZmV0 aW1lPyAgICAgICAgICAgICBpbnQzMg0KDQotLS0tDQogICAgIGNvbnRhaW5lciBtaXRpZ2F0aW9u LXNjb3BlIHsNCiAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICJUb3AgbGV2ZWwg Y29udGFpbmVyIGZvciBhIG1pdGlnYXRpb24gcmVxdWVzdC4iOw0KDQogICAgICAgICAgbGlzdCBz Y29wZSB7DQogICAgICAgICAgICAga2V5IG1pdGlnYXRpb24taWQ7DQogICAgICAgICAgICAgZGVz Y3JpcHRpb24gIklkZW50aWZpZXIgZm9yIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QuIjsNCiAgICAg ICAgICAgICBsZWFmIG1pdGlnYXRpb24taWQgew0KICAgICAgICAgICAgICAgIHR5cGUgaW50MzI7 DQogICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIk1pdGlnYXRpb24gcmVxdWVzdCBpZGVudGlm aWVyLiI7DQogICAgICAgICAgICAgfQ0KICAgICAgICAgICAgIGxpc3Qgb3JpZ2luYWwtY2xpZW50 LWlkIHsNCiAgICAgICAgICAgICAgICB0eXBlIHN0cmluZzsNCiAgICAgICAgICAgICAgICBkZXNj cmlwdGlvbiAiT3JpZ2luYWwgQ2xpZW50IElEIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24sIFJF UVVJUkVEIGFuZCBhZGRlZCB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR2F0ZXdheS4iOw0K ICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICBsZWFmLWxpc3QgdGFyZ2V0LWlwIHsNCiAgICAg ICAgICAgICAgICB0eXBlIGluZXQ6aXAtYWRkcmVzczsNCiAgICAgICAgICAgICAgICBkZXNjcmlw dGlvbg0KICAgICAgICAgICAgICAgICAgICJJUHY0IG9yIElQdjYgYWRkcmVzcyBpZGVudGlmeWlu ZyB0aGUgdGFyZ2V0LiI7DQogICAgICAgICAgICAgfQ0KLS0tLQ0KICAgICAgIHNpZ25hbC1jb25m aWcNCiAgICAgICAgICArLS1ydyBzZXNzaW9uLWlkPyAgICAgICAgICAgaW50MzINCiAgICAgICAg ICArLS1ydyBvcmlnaW5hbC1jbGllbnQtaWQqICAgc3RyaW5nDQogICAgICAgICAgKy0tcncgaGVh cnRiZWF0LWludGVydmFsPyAgIGludDE2DQogICAgICAgICAgKy0tcncgbWlzc2luZy1oYi1hbGxv d2VkPyAgIGludDE2DQogICAgICAgICAgKy0tcncgbWF4LXJldHJhbnNtaXQ/ICAgICAgIGludDE2 DQogICAgICAgICAgKy0tcncgYWNrLXRpbWVvdXQ/ICAgICAgICAgIGludDE2DQogICAgICAgICAg Ky0tcncgYWNrLXJhbmRvbS1mYWN0b3I/ICAgIGRlY2ltYWw2NA0KICAgICAgICAgICstLXJ3IHRy aWdnZXItbWl0aWdhdGlvbj8gICBCb29sZWFuDQotLS0NCiAgICAgY29udGFpbmVyIHNpZ25hbC1j b25maWcgew0KICAgICAgICAgIGRlc2NyaXB0aW9uICJUb3AgbGV2ZWwgY29udGFpbmVyIGZvciBE T1RTIHNpZ25hbCBjaGFubmVsIHNlc3Npb24NCiAgICAgICAgICAgICAgICAgICAgICAgY29uZmln dXJhdGlvbi4iOw0KDQogICAgICAgICAgbGVhZiBzZXNzaW9uLWlkIHsNCiAgICAgICAgICAgICAg dHlwZSBpbnQzMjsNCiAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIkFuIGlkZW50aWZpZXIgZm9y IHRoZSBET1RTIHNpZ25hbCBjaGFubmVsDQogICAgICAgICAgICAgICAgICAgICAgICAgICBzZXNz aW9uIGNvbmZpZ3VyYXRpb24gZGF0YS4iOw0KICAgICAgICAgIH0NCiAgICAgICAgICBsaXN0IG9y aWdpbmFsLWNsaWVudC1pZCB7DQogICAgICAgICAgICAgIHR5cGUgc3RyaW5nOw0KICAgICAgICAg ICAgICBkZXNjcmlwdGlvbiAiT3JpZ2luYWwgQ2xpZW50IElEIHJlcXVlc3RpbmcgdGhlIG1pdGln YXRpb24sIFJFUVVJUkVEIGFuZCBhZGRlZCB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR2F0 ZXdheS4iOw0KICAgICAgICAgIH0NCg0KICAgICAgICAgIGxlYWYgaGVhcnRiZWF0LWludGVydmFs IHsNCg0KLS0tDQpUaGUgZm9sbG93aW5nIFlBTkcgY2hhbmdlcyBuZWVkIHRvIGJlIG1hZGUgdG8g dGhlIGRhdGEgc3BlYyBhbmQgYXNzb2NpYXRlZCByZWZlcmVuY2VzIHVwZGF0ZWQNCg0KICAgbW9k dWxlOiBpZXRmLWRvdHMtZGF0YS1jaGFubmVsLWlkZW50aWZpZXINCiAgICAgICArLS1ydyBpZGVu dGlmaWVyDQogICAgICAgICAgKy0tcncgYWxpYXMqIFthbGlhcy1uYW1lXQ0KICAgICAgICAgICAg ICstLXJ3IGFsaWFzLW5hbWUgICAgICAgICAgIHN0cmluZw0KICAgICAgICAgICAgICstLXJ3IG9y aWdpbmFsLWNsaWVudC1pZCogIHN0cmluZw0KICAgICAgICAgICAgICstLXJ3IHRhcmdldC1pcCog ICAgICAgICAgIGluZXQ6aXAtYWRkcmVzcw0KICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wcmVm aXgqICAgICAgIGluZXQ6aXAtcHJlZml4DQogICAgICAgICAgICAgKy0tcncgdGFyZ2V0LXBvcnQt cmFuZ2UqIFtsb3dlci1wb3J0IHVwcGVyLXBvcnRdDQogICAgICAgICAgICAgfCAgKy0tcncgbG93 ZXItcG9ydCAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAgICAgfCAgKy0tcncgdXBwZXIt cG9ydCAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAgICAgKy0tcncgdGFyZ2V0LXByb3Rv Y29sKiAgICAgdWludDgNCiAgICAgICAgICAgICArLS1ydyBmcWRuKiAgICAgICAgICAgICAgICBp bmV0OmRvbWFpbi1uYW1lDQogICAgICAgICAgICAgKy0tcncgdXJpKg0KLS0tDQogICAgIGNvbnRh aW5lciBpZGVudGlmaWVyIHsNCiAgICAgICAgICBkZXNjcmlwdGlvbiAidG9wIGxldmVsIGNvbnRh aW5lciBmb3IgaWRlbnRpZmllcnMiOw0KICAgICAgICAgICAgICBsaXN0IGFsaWFzIHsNCiAgICAg ICAgICAgICAgICAgICBrZXkgYWxpYXMtbmFtZTsNCiAgICAgICAgICAgICAgICAgICBkZXNjcmlw dGlvbiAibGlzdCBvZiBpZGVudGlmaWVycyI7DQogICAgICAgICAgICAgICAgICAgbGVhZiBhbGlh cy1uYW1lIHsNCiAgICAgICAgICAgICAgICAgICAgICB0eXBlIHN0cmluZzsNCiAgICAgICAgICAg ICAgICAgICAgICBkZXNjcmlwdGlvbiAiYWxpYXMgbmFtZSI7DQogICAgICAgICAgICAgICAgICAg fQ0KICAgICAgICAgICAgICAgICAgIGxpc3Qgb3JpZ2luYWwtY2xpZW50LWlkIHsNCiAgICAgICAg ICAgICAgICAgICAgICAgdHlwZSBzdHJpbmc7DQogICAgICAgICAgICAgICAgICAgICAgIGRlc2Ny aXB0aW9uICJPcmlnaW5hbCBDbGllbnQgSUQgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbiwgUkVR VUlSRUQgYW5kIGFkZGVkIHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHYXRld2F5LiI7DQog ICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgIGxlYWYtbGlzdCB0YXJnZXQt aXAgew0KLS0tDQpUaGUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0OmFjY2Vzcy1saXN0cyBpcyBt b3JlIGNvbXBsaWNhdGVkLiAgV2l0aCB0aGUgaW50cm9kdWN0aW9uIG9mIOKAmGNvbnRhaW5lciBp bnRlcmZhY2Vz4oCZIGluIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xNCB0aGUgdGV4dCBp biBnZW5lcmFsIGluIGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwgbmVlZHMgdXBkYXRpbmcu ICBUaGlzIGNoYW5nZSBpbiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTQgZ2l2ZXMgdXMg dGhlIGFiaWxpdHkgdG8gYXR0YWNoIGEgc3BlY2lmaWMgc2V0IG9mIHNvcnRlZCBBQ0xzIHRvIGFu IGludGVyZmFjZSwgYnV0IHN0aWxsIGRvZXMgbm90IGVhc2lseSBhc3NvY2lhdGUgYSBzZXQgb2Yg QUNMIGRlZmluaXRpb25zIHdpdGggYSBwYXJ0aWN1bGFyIGNsaWVudC4NCg0KTXkgc3VnZ2VzdGlv biBpcyB0aGF0IHdlIGFkZCBpbiBhbiBhZGRpdGlvbmFsIEpTT04gZW50cnkgYXMgZm9sbG93cywg d2l0aCB0aGUgWUFORyBtb2R1bGUgbW9kdWxlIGlldGYtZG90cy1hY2Nlc3MtY29udHJvbC1saXN0 IHVwZGF0ZWQgKG15IFlBTkcgaXMgbm90IGN1cnJlbnRseSB1cCB0byBkb2luZyB0aGF0KSB0aGF0 IGRlZmluZXMgd2hhdCB3ZSBhcmUgZG9pbmcuDQoNCiAgUE9TVCAvcmVzdGNvbmYvZGF0YS9pZXRm LWFjY2Vzcy1jb250cm9sLWxpc3QgSFRUUC8xLjENCiAgSG9zdDogd3d3LmV4YW1wbGUuY29tPGh0 dHA6Ly93d3cuZXhhbXBsZS5jb20+DQogIENvbnRlbnQtRm9ybWF0OiAiYXBwbGljYXRpb24veWFu Zy5hcGkranNvbiINCiAgew0KICAgIm9yaWdpbmFsLWNsaWVudC1pZCIgOiBbInN0cmluZyIgXSwN CiAgICJpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Q6YWNjZXNzLWxpc3RzIjogew0KICAgICAgImFj bCI6IFsNCg0KW0FuZCBzaG91bGQgbm90IHdlIGJlIHBvc3RpbmcgdG8gL3Jlc3Rjb25mL2RhdGEv aWV0Zi1kb3RzLWFjY2Vzcy1jb250cm9sLWxpc3QgYW55d2F5P10NCg0KUmVnYXJkcw0KDQpKb24N CkZyb206IERvdHMgW21haWx0bzogZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJv dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRG9iYmlucywgUm9sYW5kDQpTZW50OiAwNSBP Y3RvYmVyIDIwMTcgMTA6NDINClRvOiBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KDQoNCk9u IE9jdCA1LCAyMDE3LCBhdCAxNDo1OCwgSm9uIFNoYWxsb3cgPHN1cGpwcy1pZXRmQGpwc2hhbGxv dy5jb208bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20+PiB3cm90ZToNClBlcmhhcHMg Im9yaWdpbmFsLWNsaWVudC1pZCIgd291bGQgYmUgYSBiZXR0ZXIgbmFtZSAtIGluIGEgc2ltaWxh ciBzb3J0IG9mIHdheSB0aGF0IHRoZSAiWC1Gb3J3YXJkaW5nLUZvcjoiIGhlYWRlciBwcm92aWRl cyB0aGUgb3JpZ2luYWwgSVAgbWFraW5nIHRoZSBIVFRQIHJlcXVlc3Qgd2hlbiBwYXNzaW5nIHRo cm91Z2ggYSBsb2FkLWJhbGFuY2VyIG9yIFNTTCB0ZXJtaW5hdG9yLg0KDQpUaGlzIGlzIGhvdyBp dCAqbXVzdCogd29yaywgYWdyZWVkOyBJIHJlbWVtYmVyIGRpc2N1c3NpbmcgdGhpcyB0b3BpYyBh dCBvbmUgb2YgdGhlIFdHIG1lZXRpbmdzLCBzcGVjaWZpY2FsbHkuDQoNCklmIGl0IHNvbWVob3cg d2FzIGRyb3BwZWQsIHdlIG5lZWQgdG8gZml4IGl0LiAgR2F0ZXdheXMgYXJlIGEgbmVjZXNzYXJ5 IGluaXRpYWwgY2FwYWJpbGl0eSwgYXMgaXMgcHJlc2VydmluZyBET1RTIGNsaWVudCBJRHMgYWNy b3NzIHRoZW0uDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSb2xhbmQg RG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0K --_000_DM5PR16MB1788BA6C11EF781C7702AE3EEA710DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQg MiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBVSSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnAuVGV4dGVkZWJ1 bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxsZXMNCgl7bXNvLXN0eWxlLW5h bWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBD YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5UZXh0 ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9 DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBzZWUgYSBuZWVkIGZvciBjbGllbnQt c2lkZSBET1RTIGdhdGV3YXkgdG8gY29udmV5IHRoZSDigJxET1RTIGNsaWVudCBpZGVudGl0eeKA nSB0byB0aGUgRE9UUyBzZXJ2ZXIuIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIGxvb2tzIHJl cXVpcmVkIG9ubHkgZm9yIHRoZSBzZXJ2ZXItc2lkZSBET1RTDQogZ2F0ZXdheXMuIEluIGNhc2Ug b2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5IHRoZSBjbGllbnQtaWQg Z2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RT IHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1bmlxdWUgY2xpZW50LWlk IGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4gYXJyYXkgb2YgY2xpZW50LWlkcyB0byB0aGUg RE9UUyBzZXJ2ZXIgdG8NCiByZXNvbHZlIGNsYXNoZXMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tVGlydTxh IG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PG86cD48L286cD48L2E+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgT2N0b2JlciA2LCAyMDE3IDE6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IEpvbiBT aGFsbG93ICZsdDtzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tJmd0OzsgJ0RvYmJpbnMsIFJvbGFu ZCcgJmx0O3Jkb2JiaW5zQGFyYm9yLm5ldCZndDs7IGRvdHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPlJlLSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGRpc2Fn cmVlIHdpdGggdGhlIGZvbGxvd2luZyZuYnNwOzoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBzdHJp bmc7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGRlc2NyaXB0aW9uICZxdW90O09yaWdpbmFsIENsaWVudCBJRCByZXF1ZXN0aW5nIHRoZSBt aXRpZ2F0aW9uLCBSRVFVSVJFRCBhbmQgYWRkZWQgd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RT IEdhdGV3YXkuJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BIGdhdGV3YXkgbWF5IGJlIGluc3RydWN0ZWQgdGhl IHJldmVhbCB0aGUgb3JpZ2luYWwgY2xpZW50IGlkZW50aXR5IG9ubHkgaW4gc29tZSBkZXBsb3lt ZW50cyAobm90IGFsbCk7IG90aGVyd2lzZSBpdCBpcyB0aGUgZ2F0ZXdheSBpZGVudGlmeSB0aGF0 IGlzIHVzZWQgYnkgdGhlIHJlbW90ZQ0KIHNlcnZlci4gVGhlIGdhdGV3YXkgaWRlbnRpdHkgaXMg ZXh0cmFjdGVkIGZyb20gdGhlIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzLiA8bzpwPg0KPC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+QSBjb25maWd1cmFibGUgcGFyYW1ldGVyIHRvIGVuYWJsZS9kaXNh YmxlIHRoYXQgdGhlIG9yaWdpbmFsIGNsaWVudCBpZGVudGl0eSBpcyBwYXNzZWQsIG1heSBiZSBj b25zaWRlcmVkIChkaXNhYmxlZCBieSBkZWZhdWx0LCBJTU8pLiBUaGUgb3JpZ2luYWwgY2xpZW50 IGlkZW50aXR5IGlzIHRoZXJlZm9yZQ0KIG9wdGlvbmFsLCBub3QgbWFuZGF0b3J5LiAmbmJzcDsm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkJUVywgaXQgbWF5IGJlIHdvcnRoIHRvIGNv bnNpZGVyIGEgZGVkaWNhdGVkIFlBTkcgbW9kdWxlIGZvciBET1RTIGdhdGV3YXlzLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gRG90cyBbPGEgaHJl Zj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBKb24gU2hhbGxvdzxicj4NCjxiPkVudm95 w6kmbmJzcDs6PC9iPiBqZXVkaSA1IG9jdG9icmUgMjAxNyAxMzozNTxicj4NCjxiPsOAJm5ic3A7 OjwvYj4gJ0RvYmJpbnMsIFJvbGFuZCc7IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYi PjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjxicj4NCjxi Pk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXMg dGhlIHVzZSBvZiDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0gaXMgYSAqPGI+bXVzdDwvYj4qLCB0 aGVuIEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIGNoYW5nZXMuJm5ic3A7IEl0IGlzIGRlZmluZWQg YXMgYW4gYXJyYXkgc2hvdWxkIHRoZXJlIGJlIGEgY2xpZW50LWlkDQogbmFtZSBjbGFzaCBhbmQg YSBzZWNvbmQgKG9yIG1vcmUpIGVudHJ5IG5lZWRzIHRvIGJlIGFkZGVkIGJ5IGEgRE9UUyBHYXRl d2F5IGluIGEgbG9uZyBjaGFpbi4mbmJzcDsgSW4gbm9ybWFsIHVzZSwgaXQgaXMgZXhwZWN0ZWQg dGhhdCB0aGVyZSB3aWxsIG9ubHkgYmUgb25lIGVudHJ5LCBldmVuIHRob3VnaCBzZXZlcmFsIERP VFMgR2F0ZXdheXMgaGF2ZSBiZWVuIHBhc3NlZCB0aHJvdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZm9s bG93aW5nIFlBTkcgY2hhbmdlcyBuZWVkIHRvIGJlIG1hZGUgdG8gdGhlIHNpZ25hbCBzcGVjIGFu ZCBhc3NvY2lhdGVkIHJlZmVyZW5jZXMgdXBkYXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9j dW1lbnQgZGVmaW5lcyB0aGUgWUFORyBtb2R1bGUgJnF1b3Q7aWV0Zi1kb3RzLXNpZ25hbCZxdW90 Oywgd2hpY2ggaGFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHRoZSBmb2xs b3dpbmcgdHJlZSBzdHJ1Y3R1cmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG1vZHVsZTogaWV0Zi1kb3RzLXNpZ25hbDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmIzQzOy0tcncgbWl0aWdhdGlvbi1zY29wZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t cncgc2NvcGUqIFttaXRpZ2F0aW9uLWlkXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmIzQzOy0tcncgbWl0aWdhdGlvbi1pZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQzMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tcncgb3JpZ2luYWwtY2xpZW50LWlkKiZuYnNwOyZuYnNwOyBzdHJp bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHRhcmdl dC1pcCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaW5ldDppcC1hZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyB0YXJnZXQtcHJlZml4KiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmV0OmlwLXByZWZpeDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tcncgdGFyZ2V0LXBvcnQtcmFuZ2UqIFtsb3dlci1w b3J0IHVwcGVyLXBvcnRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsgJiM0MzstLXJ3IGxvd2VyLXBvcnQmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDpwb3J0LW51 bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7 LS1ydyB1cHBlci1wb3J0Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6cG9ydC1udW1iZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHRhcmdldC1wcm90b2Nv bCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGZxZG4qJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6ZG9tYWluLW5hbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHVyaSombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDp1cmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstLXJ3IGFsaWFzLW5hbWUqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmluZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbGlmZXRpbWU/Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGludDMyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIG1pdGlnYXRpb24tc2NvcGUgezxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDtUb3AgbGV2ZWwgY29udGFpbmVyIGZvciBhIG1pdGlnYXRpb24gcmVxdWVzdC4m cXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGxpc3Qgc2NvcGUgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBrZXkg bWl0aWdhdGlvbi1pZDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVz Y3JpcHRpb24gJnF1b3Q7SWRlbnRpZmllciBmb3IgdGhlIG1pdGlnYXRpb24gcmVxdWVzdC4mcXVv dDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgbWl0aWdhdGlv bi1pZCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHR5cGUgaW50MzI7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uICZxdW90O01pdGlnYXRpb24gcmVxdWVzdCBp ZGVudGlmaWVyLiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsaXN0IG9yaWdpbmFsLWNs aWVudC1pZCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHR5cGUgc3RyaW5nOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtPcmlnaW5hbCBDbGllbnQg SUQgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbiwgUkVRVUlSRUQgYW5kIGFkZGVkIHdoZW4gcGFz c2luZyB0aHJvdWdoIGEgRE9UUyBHYXRld2F5LiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBsZWFmLWxpc3QgdGFyZ2V0LWlwIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBpbmV0OmlwLWFkZHJlc3M7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0lQdjQgb3IgSVB2NiBhZGRyZXNzIGlkZW50aWZ5aW5n IHRoZSB0YXJnZXQuJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS0tPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpZ25hbC1jb25maWc8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHNlc3Npb24taWQ/Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludDMyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyYjNDM7LS1ydyBvcmlnaW5hbC1jbGllbnQtaWQqJm5ic3A7Jm5ic3A7 IHN0cmluZyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLXJ3IGhlYXJ0 YmVhdC1pbnRlcnZhbD8mbmJzcDsmbmJzcDsgaW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0 MzstLXJ3IG1pc3NpbmctaGItYWxsb3dlZD8mbmJzcDsmbmJzcDsgaW50MTY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJiM0MzstLXJ3IG1heC1yZXRyYW5zbWl0PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWNrLXRp bWVvdXQ/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBhY2stcmFuZG9tLWZhY3Rv cj8mbmJzcDsmbmJzcDsmbmJzcDsgZGVjaW1hbDY0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS1ydyB0cmlnZ2VyLW1pdGlnYXRpb24/Jm5ic3A7Jm5ic3A7IEJvb2xlYW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBjb250YWluZXIgc2lnbmFsLWNvbmZpZyB7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGRlc2NyaXB0aW9uICZxdW90O1RvcCBsZXZlbCBjb250YWluZXIgZm9yIERPVFMgc2lnbmFs IGNoYW5uZWwgc2Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBjb25maWd1cmF0aW9uLiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBzZXNzaW9uLWlkIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBpbnQzMjs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGVzY3JpcHRpb24gJnF1b3Q7QW4gaWRlbnRpZmllciBm b3IgdGhlIERPVFMgc2lnbmFsIGNoYW5uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vzc2lvbiBjb25maWd1cmF0aW9u IGRhdGEuJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9Jm5ic3A7DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtsaXN0IG9yaWdpbmFsLWNsaWVudC1pZCB7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgc3RyaW5nOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtPcmlnaW5hbCBD bGllbnQgSUQgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbiwgUkVRVUlSRUQgYW5kIGFkZGVkIHdo ZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHYXRld2F5LiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBsZWFmIGhlYXJ0YmVhdC1pbnRlcnZhbCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0tLTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+VGhlIGZvbGxvd2luZyBZQU5HIGNoYW5nZXMgbmVlZCB0byBiZSBt YWRlIHRvIHRoZSBkYXRhIHNwZWMgYW5kIGFzc29jaWF0ZWQgcmVmZXJlbmNlcyB1cGRhdGVkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IG1vZHVsZTogaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC1pZGVudGlmaWVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS1ydyBpZGVudGlmaWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBhbGlhcyogW2Fs aWFzLW5hbWVdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1y dyBhbGlhcy1uYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHN0cmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmIzQzOy0tcncgb3JpZ2luYWwtY2xpZW50LWlkKiZuYnNwOyBzdHJpbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHRhcmdldC1pcCombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5l dDppcC1hZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS1ydyB0YXJnZXQtcHJlZml4KiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBp bmV0OmlwLXByZWZpeDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0tcncgdGFyZ2V0LXBvcnQtcmFuZ2UqIFtsb3dlci1wb3J0IHVwcGVyLXBvcnRdPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGxvd2VyLXBv cnQmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDpwb3J0LW51bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB1cHBlci1wb3J0Jm5ic3A7Jm5i c3A7Jm5ic3A7IGluZXQ6cG9ydC1udW1iZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJiM0MzstLXJ3IHRhcmdldC1wcm90b2NvbCombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3 IGZxZG4qJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6ZG9tYWluLW5hbWU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHVyaSo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb250YWluZXIgaWRlbnRpZmllciB7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRlc2NyaXB0aW9uICZxdW90O3RvcCBsZXZlbCBjb250YWluZXIgZm9yIGlkZW50 aWZpZXJzJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBsaXN0IGFsaWFzIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsga2V5IGFsaWFzLW5hbWU7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRlc2NyaXB0aW9uICZxdW90O2xpc3Qgb2YgaWRlbnRpZmllcnMmcXVvdDs7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGxlYWYgYWxpYXMtbmFtZSB7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHR5cGUgc3RyaW5nOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBkZXNjcmlwdGlvbiAmcXVvdDthbGlhcyBuYW1lJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpc3Qgb3JpZ2luYWwtY2xpZW50LWlkIHs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBzdHJpbmc7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uICZxdW90O09yaWdpbmFs IENsaWVudCBJRCByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uLCBSRVFVSVJFRCBhbmQgYWRkZWQg d2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdhdGV3YXkuJnF1b3Q7OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYtbGlzdCB0YXJnZXQtaXAgezxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+LS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U aGUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0OmFjY2Vzcy1saXN0cyBpcyBtb3JlIGNvbXBsaWNh dGVkLiZuYnNwOyBXaXRoIHRoZSBpbnRyb2R1Y3Rpb24gb2Yg4oCYY29udGFpbmVyIGludGVyZmFj ZXPigJkgaW4gZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTE0DQogdGhlIHRleHQgaW4gZ2Vu ZXJhbCBpbiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsIG5lZWRzIHVwZGF0aW5nLiZuYnNw OyBUaGlzIGNoYW5nZSBpbiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTQgZ2l2ZXMgdXMg dGhlIGFiaWxpdHkgdG8gYXR0YWNoIGEgc3BlY2lmaWMgc2V0IG9mIHNvcnRlZCBBQ0xzIHRvIGFu IGludGVyZmFjZSwgYnV0IHN0aWxsIGRvZXMgbm90IGVhc2lseSBhc3NvY2lhdGUgYSBzZXQgb2Yg QUNMIGRlZmluaXRpb25zIHdpdGgNCiBhIHBhcnRpY3VsYXIgY2xpZW50LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5N eSBzdWdnZXN0aW9uIGlzIHRoYXQgd2UgYWRkIGluIGFuIGFkZGl0aW9uYWwgSlNPTiBlbnRyeSBh cyBmb2xsb3dzLCB3aXRoIHRoZSBZQU5HIG1vZHVsZSBtb2R1bGUgaWV0Zi1kb3RzLWFjY2Vzcy1j b250cm9sLWxpc3QgdXBkYXRlZCAobXkgWUFORyBpcw0KIG5vdCBjdXJyZW50bHkgdXAgdG8gZG9p bmcgdGhhdCkgdGhhdCBkZWZpbmVzIHdoYXQgd2UgYXJlIGRvaW5nLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IFBPU1Qg L3Jlc3Rjb25mL2RhdGEvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0IEhUVFAvMS4xPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IEhvc3Q6DQo8YSBocmVmPSJodHRwOi8vd3d3LmV4YW1wbGUu Y29tIj53d3cuZXhhbXBsZS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IENv bnRlbnQtRm9ybWF0OiAmcXVvdDthcHBsaWNhdGlvbi95YW5nLmFwaSYjNDM7anNvbiZxdW90Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7ICZxdW90O29yaWdpbmFsLWNsaWVudC1pZCZxdW90OyA6IFsmcXVvdDtzdHJpbmcm cXVvdDsgXSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZxdW90 O2lldGYtYWNjZXNzLWNvbnRyb2wtbGlzdDphY2Nlc3MtbGlzdHMmcXVvdDs6IHs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YWNsJnF1 b3Q7OiBbPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPltBbmQgc2hvdWxkIG5vdCB3ZSBiZSBwb3N0aW5nIHRvIC9yZXN0 Y29uZi9kYXRhL2lldGYtPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 cmVkIj5kb3RzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+LWFjY2Vzcy1jb250cm9sLWxpc3QNCiBhbnl3YXk/XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gRG90cyBbbWFpbHRvOg0KPGEgaHJlZj0ibWFp bHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+ T24gQmVoYWxmIE9mDQo8L2I+RG9iYmlucywgUm9sYW5kPGJyPg0KPGI+U2VudDo8L2I+IDA1IE9j dG9iZXIgMjAxNyAxMDo0Mjxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0 Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10g RE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iRU4tR0IiPjxicj4NCk9uIE9jdCA1LCAyMDE3LCBhdCAxNDo1OCwgSm9uIFNoYWxsb3cgJmx0 OzxhIGhyZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tIj5zdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+UGVyaGFw cyAmcXVvdDtvcmlnaW5hbC1jbGllbnQtaWQmcXVvdDsgd291bGQgYmUgYSBiZXR0ZXIgbmFtZSAt IGluIGEgc2ltaWxhciBzb3J0IG9mIHdheSB0aGF0IHRoZSAmcXVvdDtYLUZvcndhcmRpbmctRm9y OiZxdW90OyBoZWFkZXIgcHJvdmlkZXMgdGhlIG9yaWdpbmFsIElQIG1ha2luZyB0aGUgSFRUUCBy ZXF1ZXN0IHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgbG9hZC1iYWxhbmNlciBvciBTU0wgdGVybWlu YXRvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlRo aXMgaXMgaG93IGl0ICptdXN0KiB3b3JrLCBhZ3JlZWQ7IEkgcmVtZW1iZXIgZGlzY3Vzc2luZyB0 aGlzIHRvcGljIGF0IG9uZSBvZiB0aGUgV0cgbWVldGluZ3MsIHNwZWNpZmljYWxseS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPklmIGl0IHNvbWVob3cg d2FzIGRyb3BwZWQsIHdlIG5lZWQgdG8gZml4IGl0LiAmbmJzcDtHYXRld2F5cyBhcmUgYSBuZWNl c3NhcnkgaW5pdGlhbCBjYXBhYmlsaXR5LCBhcyBpcyBwcmVzZXJ2aW5nIERPVFMgY2xpZW50IElE cyBhY3Jvc3MgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJt YWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB1788BA6C11EF781C7702AE3EEA710DM5PR16MB1788namp_-- From nobody Fri Oct 6 07:00:35 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011B0134292 for ; Fri, 6 Oct 2017 07:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 rfQPuXe-5WYr for ; Fri, 6 Oct 2017 07:00:28 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 343331349CE for ; Fri, 6 Oct 2017 07:00:28 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507298427; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=i Fi+A/MaENar97jebskw6zOqut1ufQ91k0u3/EwkGu s=; b=g8EyZZZvwUeG6Im1PY+ZKNFLh3MrhE4WLA71cW4e6LQs l5ZsfUevQCDAJlR+rc+augGqwW5xM0GFcheZ/RByVjO/JG9fOv n8c5LIUHIOaPWWuBHeghNlk7vlwnECoN/YP7hp0Ql2xZOIL1bb xC4iVlVuq2HIMx3yTtWHQI/Yqo4= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 58ca_fdc7_26edb254_b41f_4f1d_8f22_214c2c32beec; Fri, 06 Oct 2017 09:00:25 -0500 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 10:00:22 -0400 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 10:00:21 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Oct 2017 10:00:21 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 10:00:20 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 6 Oct 2017 14:00:19 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.018; Fri, 6 Oct 2017 14:00:19 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AdM866F1exiXOD0RS+2TvvngfvHPNAAHYE+AAC3w14AALEpYgAALE5wwAAKjs4AAAJFkQA== Date: Fri, 6 Oct 2017 14:00:19 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A050387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0506A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0506A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.90.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:R81+iNF3bazg+22mN7TkXetHJK/MjBE8Hi/j2k/XuW+ATJM1R2Z+Os9qfGn0bQT5a92vZgwO7vU/EEiIxCH8prksapSuenUzbdNLQIRZBnV2B+U9xpNOHA1exMl9qX9z5nPZNqqEESsfdFL6Z/l0NsuwOF4ZkHN/OZ3UTG1dM+w7FjbrGe42/F+RH1diySQWzyMjMzqIZ5Lt1egCsBIx8s9Xc1NHacTjTqiU3yb9aIuRkI/eAUKfwoOxK+tywBlyQwfLiPgmqGhbYMS9jodY7v0sTDUDKGlakr0q+3x53VEJdvWSL2YvjtiaNvNLxgotiaPhIIODveglr0kCCrv6yw==; 5:DiGPcqletx9vuKCXiagx5fFIF/xBVqt3QfZq8QTEby3Ah0gPJRC5rLKc3ql/eAQZg9T0F0TKJ5/J560SqjmKU2G6gA9H4y2tE2XOdD5HxnTyULvUK/1ddF477ijkDCPMS69XOYrkdbchLgI5n0fcNw==; 24:oCCsqGVSYAQaig1XNwSP8n+CcXWJnGOpvOFs9hLYJXpAMJbfcvkkI0Ljr4yJJ9mSbJGyNlXsO1BJvIReAuDgtZ6l0StMHjwgNjPSj8w6kRY=; 7:drLH3TUjb0AdT4IlyMOlX/PF7st01hPAF+05AzcJ7cMWOIVavbz1tgA+iugvATGLuYVT0wzn0UHoCQhLIaCsv89EmgE56rPIzrCuIDaJdasO/CHwbTLtoCB33hQbO5CRKj6xZyPUztZVFx2R3NDBynJTb7GL8I/MfCYP1P2m39o9KPfSBFeHho0JKIm3BDxtxnKCMKPJ+tomq+PeIZhh5gnw7lRcotC8nEUgRbkbqp8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e0b93c15-0b02-41f2-6c52-08d50cc2942b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0452022BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(377454003)(199003)(32952001)(189002)(72206003)(3280700002)(76176999)(53936002)(101416001)(316002)(50986999)(2501003)(80792005)(106356001)(105586002)(2900100001)(81156014)(229853002)(7736002)(97736004)(93886005)(6246003)(54356999)(99286003)(189998001)(9686003)(606006)(74316002)(66066001)(33656002)(8676002)(81166006)(236005)(8936002)(966005)(6306002)(68736007)(5660300001)(6506006)(25786009)(14454004)(54896002)(19609705001)(3660700001)(53946003)(77096006)(6116002)(86362001)(53546010)(55016002)(478600001)(3846002)(7696004)(2906002)(110136005)(6436002)(790700001)(102836003)(2950100002)(562404015)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788891866846C81818797F4EA710DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2017 14:00:19.0293 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6131> : inlines <6111> : streams <1766098> : uri <2512207> Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 14:00:33 -0000 --_000_DM5PR16MB1788891866846C81818797F4EA710DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-int= erval). -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, October 6, 2017 7:12 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval Tiru, We are on the same page for (1). I hope we will hear more voices on this be= fore we add some text to the draft to clarify missing points. Please see inline for (2). Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 6 octobre 2017 15:08 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] Minimum heartbeat-interval Hi Med, Please see inline [TR] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, October 6, 2017 12:40 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval Hi Tiru, all, Please see inline. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 5 octobre 2017 12:54 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Minimum heartbeat-interval http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). [Med] You are right about the configurable aspect, but the question from Jo= n is a good one. I interpret it in another way: - Should we rely solely on the missing-hb-allowed to detect a session pro= blem? [TR] If the DOTS agent does not receive a response to "CoAP ping" but recei= ves other type of messages from the peer DOTS agent then a counter incremen= ted each time there is no response to a "CoAP ping" till the counter value = hits missing-hb-allowed to determine the session is defunct can be reset to= zero. - Should we get rid of missing-hb-allowed, but rely on the retransmission= to declare failure or not? [TR] If DOTS agents only rely on the retransmission mechanism then a "CoAP = ping" message will only be retransmitted 4 times before concluding the sess= ion is disconnected in an interval of 93 seconds. The network under DDoS at= tack is likely to be congested (high packet loss and latency), hence missin= g-hb-allowed is used to send the "CoAP ping" more number of times (3 (ping)= + 3*4 (re-transmissions) =3D 15 times) with sufficient time interval (93*3= =3D 279 seconds) to determine the session is defunct. - What is the advantage of cumulating both missing-hb-allowed and the ret= ransmission procedure to declare a channel out? [TR] Please see above. 2) No, [Med] I agree that a heartbeat does not need to be fired when the first pin= g is still alive. We can clarify this in the draft. [TR] Thanks. if the DOTS agent wants to change the default heartbeat interval then the o= ther message transmission parameters will also have to be modified. [Med] I disagree here that the other parameters need to be changed. I don't= see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree= that we need to tweak heartbeat-interval as a function of MAX_TRANSMIT_WAI= T). As you know, MAX_TRANSMIT_WAIT can be derived from other parameters (AC= K_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR)). This i= s why it does not make sense to provide a configuration for MAX_TRANSMIT_WA= IT if the other parameters are provided. [TR] I did not get the above, the draft is not providing any new configurat= ion for MAX_TRANSMIT_WAIT [Med] I was talking about heartbeat-interval. . If let's say the DOTS agents decide to change the heartbeat interval to 4= 5 seconds then the max-retransmit has to be changed to 3 to arrive at 45 se= cond MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_= TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new heartb= eat interval). [Med] My comment is that if heartbeat-interval was dependent on transmissio= n parameters, then we do not need to configure it explicitly IN ADDITION to= the other transmission parameter. How can the heartbeat interval change without changing the message transmis= sion parameters ? [Med] I do see these two as separate parameters. The heartbeat-interval det= ermines the frequency of sending keeplaive messages. This is an additional = transmission parameter specific to heartbeat if you will. -Tiru 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med --_000_DM5PR16MB1788891866846C81818797F4EA710DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Me= d, agreed on (2) (no need to negotiate and configure heartbeat-interval).

&nbs= p;

-Tiru

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, October 6, 2017 7:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] Minimum heartbeat-interval

 

Tiru,

 

We are on the same page for (1). I hope we will hear more voices on this before we add some tex= t to the draft to clarify missing points.

 

Please see inline for (2).

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 6 octobre 2017 15:08
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] Minimum heartbeat-interval=

 

Hi Med,

&nbs= p;

Please se= e inline [TR]

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, October 6, 2017 12:40 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] Minimum heartbeat-interval

 

Hi Tiru, all,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com<= span style=3D"font-size:10.0pt;font-family:"Tahoma",sans-serif;ms= o-fareast-language:FR">]
Envoy=E9 : jeudi 5 octobre 2017 12:54
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Minimum heartbeat-interval=

 

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html= /rfc7925 has tested NAT behavior with various routers and lists the tim= eout results. The majority of the devices (62%) have a timeout between 2 an= d 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is = 54 seconds.

 

Responses to the questions below

 

1) The max-retransmit parameter is negotiable and configurable,&nbs= p; DOTS agents can pick suitable values for max-retransmit parameter based = on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).

 

[Med] You are right= about the configurable aspect, but the question from Jon is a good one. I = interpret it in another way:

- &n= bsp; Should we rely solely on the missin= g-hb-allowed to detect a session problem?

&nbs= p;

[TR] If t= he DOTS agent does not receive a response to “CoAP ping” but re= ceives other type of messages from the peer DOTS agent then a counter incre= mented each time there is no response to a “CoAP ping” till the counter value hits missing-hb-allowed to determine th= e session is defunct can be reset to zero.

- &n= bsp; Should we get rid of missing-hb-all= owed, but rely on the retransmission to declare failure or not?<= /span>

&nbs= p;

[TR] If D= OTS agents only rely on the retransmission mechanism then a “CoAP pin= g” message will only be retransmitted 4 times before concluding the s= ession is disconnected in an interval of 93 seconds. The network under DDoS attack is likely to be congested (high packet loss = and latency), hence missing-hb-allowed is used to send the “CoAP ping= ” more number of times (3 (ping) + 3*4 (re-transmissions) =3D 15 = times) with sufficient time interval (93*3 =3D 279 seconds) to determine the session is defunct.

&nbs= p;

- &n= bsp; What is the advantage of cumulating= both missing-hb-allowed and the retransmission procedure to declare a chan= nel out?

&nbs= p;

[TR] Plea= se see above.

 

2) No,

[Med] I agree that = a heartbeat does not need to be fired when the first ping is still alive. W= e can clarify this in the draft.

&nbs= p;

[TR] Than= ks.

 

if the DOTS agent wants to change the default heartbeat interval th= en the other message transmission parameters will also have to be modified.

[Med] I disagree he= re that the other parameters need to be changed. I don’t see heartbea= t-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree that we need to tweak heartbeat-interval as a function of MAX_T= RANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from other par= ameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_F= ACTOR)). This is why it does not make sense to provide a configuration for MAX_TRANSMIT_WAIT if the other parame= ters are provided.

&nbs= p;

[TR] I di= d not get the above, the draft is not providing any new configuration for M= AX_TRANSMIT_WAIT

[Med] I was talking= about heartbeat-interval.

 

. If let&= #8217;s say the DOTS agents decide to change the heartbeat interval to 45 s= econds then the max-retransmit has to be changed to 3 to arrive at 45 secon= d MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be change= d to arrive at the new heartbeat interval).

[Med] My comment is= that if heartbeat-interval was dependent on transmission parameters, then = we do not need to configure it explicitly IN ADDITION to the other transmission parameter.  

 

How can t= he heartbeat interval change without changing the message transmission para= meters ?

[Med] I do see thes= e two as separate parameters. The heartbeat-interval determines the frequen= cy of sending keeplaive messages. This is an additional transmission parameter specific to heartbeat if you will.

&nbs= p;

-Tiru

&nbs= p;

 

3) The client will have to assume the session is disconnected (see = the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The he= artbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 

Med – In the below text, recommended value should be 93 secon= ds instead of 90 seconds (see https://tools= .ietf.org/html/rfc7252#section-4.8.2).

 

-Tiru<= /span>

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

&n= bsp;

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

&n= bsp;

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

&n= bsp;

Oct 04 10:53:51 DEBG sending C= oAP ping:

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to re= transmit queue (2281ms)

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:53:51 ALRT got RST f= or message 29548

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending C= oAP ping:

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to re= transmit queue (2938ms)

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:07 ALRT got RST f= or message 29549

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending C= oAP ping:

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to re= transmit queue (2156ms)

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:23 ALRT got RST f= or message 29550

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending C= oAP ping:

Oct 04 10:54:39 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to re= transmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #1

Oct 04 10:54:42 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #2

Oct 04 10:54:48 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #3

Oct 04 10:55:00 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #4

Oct 04 10:55:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up af= ter 4 attempts

&n= bsp;

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

&n= bsp;

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

&n= bsp;

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

&n= bsp;

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

&n= bsp;

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Scenari= o as Q3

&n= bsp;

Does th= e client re-use the old session that the heartbeats are failing on?

- The s= erver may have sent a session close, but it never got through

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

&n= bsp;

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

&n= bsp;

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow = (supjps-ietf@jpshallow.com= )
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during the interim meeting:= “A: (Jon Shallow): The minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with RFC8085 which= says the following:

 

   An application that needs to employ kee=
p-alive messages to deliver
   useful service over UDP in the presence=
 of middleboxes SHOULD NOT
        &nbs=
p;            &=
nbsp;           &nbs=
p;            ^^^^^^=
^^^^^^^^^^^^^^^^
   transmit them more frequently than once=
 every 15 seconds and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   use longer intervals when possible.&nbs=
p;

 

I suggest to add this NEW text to the signal-channel draft= to clarify the rationale for the recommended values:

 

NEW:

    &= nbsp; Note: heartbeat-interval should be tweaked to also assist DOTS

    &= nbsp; messages for NAT traversal (SIG-010 of

    &= nbsp; [I-D.ietf-dots-requirements]).  According to [RFC8085], keepaliv= e

    &= nbsp; messages must not be sent more frequently than once every 15

    &= nbsp; seconds and should use longer intervals when possible.

    &= nbsp; Furthermore, [RFC4787] recommends NATs to use a state timeout of 2

    &= nbsp; minutes or longer.  From that standpoint, this specification

    &= nbsp; recommends a minimum heartbeat-interval of 15 seconds and a

    &= nbsp; maximum heartbeat-interval of 240 seconds.  The recommended valu= e

    &= nbsp; of 90 seconds is selected to anticipate the expiry of NAT states,

    &= nbsp; while avoiding overloading the network with frequent keepalives<= /o:p>

    &= nbsp; for NAT state maintenance purposes.  Note that this recommended<= o:p>

    &= nbsp; value is close to the one recommended for MAX_TRANSMIT_WAIT, whose

    &= nbsp; value is derived from transmission parameters (Section 4.8.2 of<= /o:p>

      [RFC7252]).

 

Thoughts?

 

Cheers,

Med

--_000_DM5PR16MB1788891866846C81818797F4EA710DM5PR16MB1788namp_-- From nobody Fri Oct 6 07:11:46 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04DA1349D8 for ; Fri, 6 Oct 2017 07:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymYObFFHRw3B for ; Fri, 6 Oct 2017 07:11:43 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 EBE3B1349D3 for ; Fri, 6 Oct 2017 07:11:42 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e0TLn-0005rO-Lr; Fri, 06 Oct 2017 15:11:39 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , , "Roland Dobbins" References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 6 Oct 2017 15:11:40 +0100 Message-ID: <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0920_01D33EB5.69B18280" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIKLRwl6A Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 14:11:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0920_01D33EB5.69B18280 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru ------=_NextPart_000_0920_01D33EB5.69B18280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= Konda, = Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com] =
Sent: 06 October 2017 14:58
To: = mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org
Subject: RE: [Dots] DOTS Gateways = Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 =

-Tiru

------=_NextPart_000_0920_01D33EB5.69B18280-- From nobody Fri Oct 6 07:44:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE211349E9 for ; Fri, 6 Oct 2017 07:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifkGeGKec1Im for ; Fri, 6 Oct 2017 07:44:40 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A691349E5 for ; Fri, 6 Oct 2017 07:44:38 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id C74DD607BD; Fri, 6 Oct 2017 16:44:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id A126DC0062; Fri, 6 Oct 2017 16:44:37 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0361.001; Fri, 6 Oct 2017 16:44:37 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "'Dobbins, Roland'" , "dots@ietf.org" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAACVilg Date: Fri, 6 Oct 2017 14:44:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0507C1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0507C1OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 14:44:50 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0507C1OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogS29uZGEs IFRpcnVtYWxlc3dhciBSZWRkeSBbbWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZl ZS5jb21dDQpFbnZvecOpIDogdmVuZHJlZGkgNiBvY3RvYnJlIDIwMTcgMTU6NTgNCsOAIDogQk9V Q0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgSm9uIFNoYWxsb3c7ICdEb2JiaW5zLCBSb2xhbmQnOyBk b3RzQGlldGYub3JnDQpPYmpldCA6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2Vz DQoNCkkgZG9u4oCZdCBzZWUgYSBuZWVkIGZvciBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgdG8g Y29udmV5IHRoZSDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIu DQpbTWVkXSBBZ3JlZS4NCg0K4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gbG9va3MgcmVxdWly ZWQgb25seSBmb3IgdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheXMuDQpbTWVkXSBZZXMuDQoN CkluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5IHRoZSBj bGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRv IHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1bmlxdWUg Y2xpZW50LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4gYXJyYXkgb2YgY2xpZW50LWlk cyB0byB0aGUgRE9UUyBzZXJ2ZXIgdG8gcmVzb2x2ZSBjbGFzaGVzLg0KW01lZF0gV2hhdGV2ZXIg dGhlIG1lY2hhbmlzbSB1c2VkIHRvIGdlbmVyYXRlIHRoYXQgaWQsIHdlIHdpbGwgbmVlZCBhIGNo YW5uZWwgdG8gY29udmV5IGl0IHRvIHRoZSBzZXJ2ZXIuIE9idmlvdXNseSwgaXQgY2Fubm90IGJl IGV4dHJhY3RlZCBmcm9tIHRoZSBpZGVudGl0eSBvZiB0aGUgZ2F0ZXdheSBpdHNlbGYgYmVjYXVz ZSBpdCBhZ2dyZWdhdGVzIG1hbnkgY2xpZW50cyAodGhhdCBiZWxvbmdzIHRvIGRpc3RpbmN0IHN1 YnNjcmliZXJzKS4gVGhlcmUgaXMgYSByb29tIGZvciBhbiBvcHRpb25hbCBwYXJhbWV0ZXIgZm9y IHRoaXMuDQoNCg0KLVRpcnUNCg0KRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgNiwgMjAx NyAxOjA3IFBNDQpUbzogSm9uIFNoYWxsb3cgPHN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208bWFp bHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20+PjsgJ0RvYmJpbnMsIFJvbGFuZCcgPHJkb2Ji aW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pj47IGRvdHNAaWV0Zi5vcmc8 bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMg Q2hhbGxlbmdlcw0KDQpSZS0sDQoNCkkgZGlzYWdyZWUgd2l0aCB0aGUgZm9sbG93aW5nIDoNCg0K ICAgICAgICAgICAgICAgIHR5cGUgc3RyaW5nOw0KICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9u ICJPcmlnaW5hbCBDbGllbnQgSUQgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbiwgUkVRVUlSRUQg YW5kIGFkZGVkIHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHYXRld2F5LiI7DQogICAgICAg ICAgICAgfQ0KDQpBIGdhdGV3YXkgbWF5IGJlIGluc3RydWN0ZWQgdGhlIHJldmVhbCB0aGUgb3Jp Z2luYWwgY2xpZW50IGlkZW50aXR5IG9ubHkgaW4gc29tZSBkZXBsb3ltZW50cyAobm90IGFsbCk7 IG90aGVyd2lzZSBpdCBpcyB0aGUgZ2F0ZXdheSBpZGVudGlmeSB0aGF0IGlzIHVzZWQgYnkgdGhl IHJlbW90ZSBzZXJ2ZXIuIFRoZSBnYXRld2F5IGlkZW50aXR5IGlzIGV4dHJhY3RlZCBmcm9tIHRo ZSBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscy4NCg0KQSBjb25maWd1cmFibGUgcGFyYW1ldGVy IHRvIGVuYWJsZS9kaXNhYmxlIHRoYXQgdGhlIG9yaWdpbmFsIGNsaWVudCBpZGVudGl0eSBpcyBw YXNzZWQsIG1heSBiZSBjb25zaWRlcmVkIChkaXNhYmxlZCBieSBkZWZhdWx0LCBJTU8pLiBUaGUg b3JpZ2luYWwgY2xpZW50IGlkZW50aXR5IGlzIHRoZXJlZm9yZSBvcHRpb25hbCwgbm90IG1hbmRh dG9yeS4NCg0KQlRXLCBpdCBtYXkgYmUgd29ydGggdG8gY29uc2lkZXIgYSBkZWRpY2F0ZWQgWUFO RyBtb2R1bGUgZm9yIERPVFMgZ2F0ZXdheXMuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IERvdHMg W21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSm9uIFNoYWxsb3cN CkVudm95w6kgOiBqZXVkaSA1IG9jdG9icmUgMjAxNyAxMzozNQ0Kw4AgOiAnRG9iYmlucywgUm9s YW5kJzsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtE b3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KQXMgdGhlIHVzZSBvZiDigJxvcmlnaW5h bC1jbGllbnQtaWTigJ0gaXMgYSAqbXVzdCosIHRoZW4gSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcg Y2hhbmdlcy4gIEl0IGlzIGRlZmluZWQgYXMgYW4gYXJyYXkgc2hvdWxkIHRoZXJlIGJlIGEgY2xp ZW50LWlkIG5hbWUgY2xhc2ggYW5kIGEgc2Vjb25kIChvciBtb3JlKSBlbnRyeSBuZWVkcyB0byBi ZSBhZGRlZCBieSBhIERPVFMgR2F0ZXdheSBpbiBhIGxvbmcgY2hhaW4uICBJbiBub3JtYWwgdXNl LCBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZXJlIHdpbGwgb25seSBiZSBvbmUgZW50cnksIGV2ZW4g dGhvdWdoIHNldmVyYWwgRE9UUyBHYXRld2F5cyBoYXZlIGJlZW4gcGFzc2VkIHRocm91Z2guDQoN ClRoZSBmb2xsb3dpbmcgWUFORyBjaGFuZ2VzIG5lZWQgdG8gYmUgbWFkZSB0byB0aGUgc2lnbmFs IHNwZWMgYW5kIGFzc29jaWF0ZWQgcmVmZXJlbmNlcyB1cGRhdGVkDQoNCiAgIFRoaXMgZG9jdW1l bnQgZGVmaW5lcyB0aGUgWUFORyBtb2R1bGUgImlldGYtZG90cy1zaWduYWwiLCB3aGljaCBoYXMN CiAgIHRoZSBmb2xsb3dpbmcgdHJlZSBzdHJ1Y3R1cmU6DQoNCiAgIG1vZHVsZTogaWV0Zi1kb3Rz LXNpZ25hbA0KICAgICAgICstLXJ3IG1pdGlnYXRpb24tc2NvcGUNCiAgICAgICAgICArLS1ydyBz Y29wZSogW21pdGlnYXRpb24taWRdDQogICAgICAgICAgICAgKy0tcncgbWl0aWdhdGlvbi1pZCAg ICAgICAgIGludDMyDQogICAgICAgICAgICAgKy0tcncgb3JpZ2luYWwtY2xpZW50LWlkKiAgIHN0 cmluZw0KICAgICAgICAgICAgICstLXJ3IHRhcmdldC1pcCogICAgICAgICAgICBpbmV0OmlwLWFk ZHJlc3MNCiAgICAgICAgICAgICArLS1ydyB0YXJnZXQtcHJlZml4KiAgICAgICAgaW5ldDppcC1w cmVmaXgNCiAgICAgICAgICAgICArLS1ydyB0YXJnZXQtcG9ydC1yYW5nZSogW2xvd2VyLXBvcnQg dXBwZXItcG9ydF0NCiAgICAgICAgICAgICB8ICArLS1ydyBsb3dlci1wb3J0ICAgIGluZXQ6cG9y dC1udW1iZXINCiAgICAgICAgICAgICB8ICArLS1ydyB1cHBlci1wb3J0ICAgIGluZXQ6cG9ydC1u dW1iZXINCiAgICAgICAgICAgICArLS1ydyB0YXJnZXQtcHJvdG9jb2wqICAgICAgdWludDgNCiAg ICAgICAgICAgICArLS1ydyBmcWRuKiAgICAgICAgICAgICAgICAgaW5ldDpkb21haW4tbmFtZQ0K ICAgICAgICAgICAgICstLXJ3IHVyaSogICAgICAgICAgICAgICAgICBpbmV0OnVyaQ0KICAgICAg ICAgICAgICstLXJ3IGFsaWFzLW5hbWUqICAgICAgICAgICBzdHJpbmcNCiAgICAgICAgICAgICAr LS1ydyBsaWZldGltZT8gICAgICAgICAgICAgaW50MzINCg0KLS0tLQ0KICAgICBjb250YWluZXIg bWl0aWdhdGlvbi1zY29wZSB7DQogICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAi VG9wIGxldmVsIGNvbnRhaW5lciBmb3IgYSBtaXRpZ2F0aW9uIHJlcXVlc3QuIjsNCg0KICAgICAg ICAgIGxpc3Qgc2NvcGUgew0KICAgICAgICAgICAgIGtleSBtaXRpZ2F0aW9uLWlkOw0KICAgICAg ICAgICAgIGRlc2NyaXB0aW9uICJJZGVudGlmaWVyIGZvciB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0 LiI7DQogICAgICAgICAgICAgbGVhZiBtaXRpZ2F0aW9uLWlkIHsNCiAgICAgICAgICAgICAgICB0 eXBlIGludDMyOw0KICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJNaXRpZ2F0aW9uIHJlcXVl c3QgaWRlbnRpZmllci4iOw0KICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICBsaXN0IG9yaWdp bmFsLWNsaWVudC1pZCB7DQogICAgICAgICAgICAgICAgdHlwZSBzdHJpbmc7DQogICAgICAgICAg ICAgICAgZGVzY3JpcHRpb24gIk9yaWdpbmFsIENsaWVudCBJRCByZXF1ZXN0aW5nIHRoZSBtaXRp Z2F0aW9uLCBSRVFVSVJFRCBhbmQgYWRkZWQgd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdh dGV3YXkuIjsNCiAgICAgICAgICAgICB9DQogICAgICAgICAgICAgbGVhZi1saXN0IHRhcmdldC1p cCB7DQogICAgICAgICAgICAgICAgdHlwZSBpbmV0OmlwLWFkZHJlc3M7DQogICAgICAgICAgICAg ICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAgICAiSVB2NCBvciBJUHY2IGFkZHJlc3Mg aWRlbnRpZnlpbmcgdGhlIHRhcmdldC4iOw0KICAgICAgICAgICAgIH0NCi0tLS0NCiAgICAgICBz aWduYWwtY29uZmlnDQogICAgICAgICAgKy0tcncgc2Vzc2lvbi1pZD8gICAgICAgICAgIGludDMy DQogICAgICAgICAgKy0tcncgb3JpZ2luYWwtY2xpZW50LWlkKiAgIHN0cmluZw0KICAgICAgICAg ICstLXJ3IGhlYXJ0YmVhdC1pbnRlcnZhbD8gICBpbnQxNg0KICAgICAgICAgICstLXJ3IG1pc3Np bmctaGItYWxsb3dlZD8gICBpbnQxNg0KICAgICAgICAgICstLXJ3IG1heC1yZXRyYW5zbWl0PyAg ICAgICBpbnQxNg0KICAgICAgICAgICstLXJ3IGFjay10aW1lb3V0PyAgICAgICAgICBpbnQxNg0K ICAgICAgICAgICstLXJ3IGFjay1yYW5kb20tZmFjdG9yPyAgICBkZWNpbWFsNjQNCiAgICAgICAg ICArLS1ydyB0cmlnZ2VyLW1pdGlnYXRpb24/ICAgQm9vbGVhbg0KLS0tDQogICAgIGNvbnRhaW5l ciBzaWduYWwtY29uZmlnIHsNCiAgICAgICAgICBkZXNjcmlwdGlvbiAiVG9wIGxldmVsIGNvbnRh aW5lciBmb3IgRE9UUyBzaWduYWwgY2hhbm5lbCBzZXNzaW9uDQogICAgICAgICAgICAgICAgICAg ICAgIGNvbmZpZ3VyYXRpb24uIjsNCg0KICAgICAgICAgIGxlYWYgc2Vzc2lvbi1pZCB7DQogICAg ICAgICAgICAgIHR5cGUgaW50MzI7DQogICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJBbiBpZGVu dGlmaWVyIGZvciB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgc2Vzc2lvbiBjb25maWd1cmF0aW9uIGRhdGEuIjsNCiAgICAgICAgICB9DQogICAgICAg ICAgbGlzdCBvcmlnaW5hbC1jbGllbnQtaWQgew0KICAgICAgICAgICAgICB0eXBlIHN0cmluZzsN CiAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIk9yaWdpbmFsIENsaWVudCBJRCByZXF1ZXN0aW5n IHRoZSBtaXRpZ2F0aW9uLCBSRVFVSVJFRCBhbmQgYWRkZWQgd2hlbiBwYXNzaW5nIHRocm91Z2gg YSBET1RTIEdhdGV3YXkuIjsNCiAgICAgICAgICB9DQoNCiAgICAgICAgICBsZWFmIGhlYXJ0YmVh dC1pbnRlcnZhbCB7DQoNCi0tLQ0KVGhlIGZvbGxvd2luZyBZQU5HIGNoYW5nZXMgbmVlZCB0byBi ZSBtYWRlIHRvIHRoZSBkYXRhIHNwZWMgYW5kIGFzc29jaWF0ZWQgcmVmZXJlbmNlcyB1cGRhdGVk DQoNCiAgIG1vZHVsZTogaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC1pZGVudGlmaWVyDQogICAgICAg Ky0tcncgaWRlbnRpZmllcg0KICAgICAgICAgICstLXJ3IGFsaWFzKiBbYWxpYXMtbmFtZV0NCiAg ICAgICAgICAgICArLS1ydyBhbGlhcy1uYW1lICAgICAgICAgICBzdHJpbmcNCiAgICAgICAgICAg ICArLS1ydyBvcmlnaW5hbC1jbGllbnQtaWQqICBzdHJpbmcNCiAgICAgICAgICAgICArLS1ydyB0 YXJnZXQtaXAqICAgICAgICAgICBpbmV0OmlwLWFkZHJlc3MNCiAgICAgICAgICAgICArLS1ydyB0 YXJnZXQtcHJlZml4KiAgICAgICBpbmV0OmlwLXByZWZpeA0KICAgICAgICAgICAgICstLXJ3IHRh cmdldC1wb3J0LXJhbmdlKiBbbG93ZXItcG9ydCB1cHBlci1wb3J0XQ0KICAgICAgICAgICAgIHwg ICstLXJ3IGxvd2VyLXBvcnQgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgIHwgICst LXJ3IHVwcGVyLXBvcnQgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgICstLXJ3IHRh cmdldC1wcm90b2NvbCogICAgIHVpbnQ4DQogICAgICAgICAgICAgKy0tcncgZnFkbiogICAgICAg ICAgICAgICAgaW5ldDpkb21haW4tbmFtZQ0KICAgICAgICAgICAgICstLXJ3IHVyaSoNCi0tLQ0K ICAgICBjb250YWluZXIgaWRlbnRpZmllciB7DQogICAgICAgICAgZGVzY3JpcHRpb24gInRvcCBs ZXZlbCBjb250YWluZXIgZm9yIGlkZW50aWZpZXJzIjsNCiAgICAgICAgICAgICAgbGlzdCBhbGlh cyB7DQogICAgICAgICAgICAgICAgICAga2V5IGFsaWFzLW5hbWU7DQogICAgICAgICAgICAgICAg ICAgZGVzY3JpcHRpb24gImxpc3Qgb2YgaWRlbnRpZmllcnMiOw0KICAgICAgICAgICAgICAgICAg IGxlYWYgYWxpYXMtbmFtZSB7DQogICAgICAgICAgICAgICAgICAgICAgdHlwZSBzdHJpbmc7DQog ICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gImFsaWFzIG5hbWUiOw0KICAgICAgICAg ICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICBsaXN0IG9yaWdpbmFsLWNsaWVudC1pZCB7 DQogICAgICAgICAgICAgICAgICAgICAgIHR5cGUgc3RyaW5nOw0KICAgICAgICAgICAgICAgICAg ICAgICBkZXNjcmlwdGlvbiAiT3JpZ2luYWwgQ2xpZW50IElEIHJlcXVlc3RpbmcgdGhlIG1pdGln YXRpb24sIFJFUVVJUkVEIGFuZCBhZGRlZCB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR2F0 ZXdheS4iOw0KICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICBsZWFmLWxp c3QgdGFyZ2V0LWlwIHsNCi0tLQ0KVGhlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdDphY2Nlc3Mt bGlzdHMgaXMgbW9yZSBjb21wbGljYXRlZC4gIFdpdGggdGhlIGludHJvZHVjdGlvbiBvZiDigJhj b250YWluZXIgaW50ZXJmYWNlc+KAmSBpbiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTQg dGhlIHRleHQgaW4gZ2VuZXJhbCBpbiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsIG5lZWRz IHVwZGF0aW5nLiAgVGhpcyBjaGFuZ2UgaW4gZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTE0 IGdpdmVzIHVzIHRoZSBhYmlsaXR5IHRvIGF0dGFjaCBhIHNwZWNpZmljIHNldCBvZiBzb3J0ZWQg QUNMcyB0byBhbiBpbnRlcmZhY2UsIGJ1dCBzdGlsbCBkb2VzIG5vdCBlYXNpbHkgYXNzb2NpYXRl IGEgc2V0IG9mIEFDTCBkZWZpbml0aW9ucyB3aXRoIGEgcGFydGljdWxhciBjbGllbnQuDQoNCk15 IHN1Z2dlc3Rpb24gaXMgdGhhdCB3ZSBhZGQgaW4gYW4gYWRkaXRpb25hbCBKU09OIGVudHJ5IGFz IGZvbGxvd3MsIHdpdGggdGhlIFlBTkcgbW9kdWxlIG1vZHVsZSBpZXRmLWRvdHMtYWNjZXNzLWNv bnRyb2wtbGlzdCB1cGRhdGVkIChteSBZQU5HIGlzIG5vdCBjdXJyZW50bHkgdXAgdG8gZG9pbmcg dGhhdCkgdGhhdCBkZWZpbmVzIHdoYXQgd2UgYXJlIGRvaW5nLg0KDQogIFBPU1QgL3Jlc3Rjb25m L2RhdGEvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0IEhUVFAvMS4xDQogIEhvc3Q6IHd3dy5leGFt cGxlLmNvbTxodHRwOi8vd3d3LmV4YW1wbGUuY29tPg0KICBDb250ZW50LUZvcm1hdDogImFwcGxp Y2F0aW9uL3lhbmcuYXBpK2pzb24iDQogIHsNCiAgICJvcmlnaW5hbC1jbGllbnQtaWQiIDogWyJz dHJpbmciIF0sDQogICAiaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0OmFjY2Vzcy1saXN0cyI6IHsN CiAgICAgICJhY2wiOiBbDQoNCltBbmQgc2hvdWxkIG5vdCB3ZSBiZSBwb3N0aW5nIHRvIC9yZXN0 Y29uZi9kYXRhL2lldGYtZG90cy1hY2Nlc3MtY29udHJvbC1saXN0IGFueXdheT9dDQoNClJlZ2Fy ZHMNCg0KSm9uDQpGcm9tOiBEb3RzIFttYWlsdG86IGRvdHMtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86ZG90cy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIERvYmJpbnMsIFJvbGFuZA0K U2VudDogMDUgT2N0b2JlciAyMDE3IDEwOjQyDQpUbzogZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90 c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2Vz DQoNCg0KDQpPbiBPY3QgNSwgMjAxNywgYXQgMTQ6NTgsIEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0 ZkBqcHNoYWxsb3cuY29tPG1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPj4gd3JvdGU6 DQpQZXJoYXBzICJvcmlnaW5hbC1jbGllbnQtaWQiIHdvdWxkIGJlIGEgYmV0dGVyIG5hbWUgLSBp biBhIHNpbWlsYXIgc29ydCBvZiB3YXkgdGhhdCB0aGUgIlgtRm9yd2FyZGluZy1Gb3I6IiBoZWFk ZXIgcHJvdmlkZXMgdGhlIG9yaWdpbmFsIElQIG1ha2luZyB0aGUgSFRUUCByZXF1ZXN0IHdoZW4g cGFzc2luZyB0aHJvdWdoIGEgbG9hZC1iYWxhbmNlciBvciBTU0wgdGVybWluYXRvci4NCg0KVGhp cyBpcyBob3cgaXQgKm11c3QqIHdvcmssIGFncmVlZDsgSSByZW1lbWJlciBkaXNjdXNzaW5nIHRo aXMgdG9waWMgYXQgb25lIG9mIHRoZSBXRyBtZWV0aW5ncywgc3BlY2lmaWNhbGx5Lg0KDQpJZiBp dCBzb21laG93IHdhcyBkcm9wcGVkLCB3ZSBuZWVkIHRvIGZpeCBpdC4gIEdhdGV3YXlzIGFyZSBh IG5lY2Vzc2FyeSBpbml0aWFsIGNhcGFiaWxpdHksIGFzIGlzIHByZXNlcnZpbmcgRE9UUyBjbGll bnQgSURzIGFjcm9zcyB0aGVtLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJi b3IubmV0Pj4NCg== --_000_787AE7BB302AE849A7480A190F8B93300A0507C1OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIg NCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJ e21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2 Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxsb29uVGV4 dCwgZGl2LkJhbGxvb25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQiOw0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBVSSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlBsZWFzZSBzZWUgaW5saW5lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g S29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSBbbWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRh QE1jQWZlZS5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gdmVuZHJlZGkgNiBvY3Rv YnJlIDIwMTcgMTU6NTg8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElN VC9PTE47IEpvbiBTaGFsbG93OyAnRG9iYmlucywgUm9sYW5kJzsgZG90c0BpZXRmLm9yZzxicj4N CjxiPk9iamV0Jm5ic3A7OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGRvbuKAmXQgc2VlIGEgbmVlZCBmb3Ig Y2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcRE9UUyBjbGllbnQgaWRl bnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBBZ3Jl ZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gbG9va3Mg cmVxdWlyZWQgb25seSBmb3IgdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheXMuPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5bTWVkXSBZZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIGNhc2Ugb2Ygc2VydmVy LXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5IHRoZSBjbGllbnQtaWQgZ2VuZXJhdGVk IGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4g VGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUNCiBhIHVuaXF1ZSBjbGllbnQtaWQgYW5kIGRv ZXMgbm90IGhhdmUgdG8gc2VuZCBhbiBhcnJheSBvZiBjbGllbnQtaWRzIHRvIHRoZSBET1RTIHNl cnZlciB0byByZXNvbHZlIGNsYXNoZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPltNZWRdIFdoYXRldmVyIHRoZSBtZWNoYW5pc20gdXNlZCB0byBnZW5lcmF0ZSB0 aGF0IGlkLCB3ZSB3aWxsIG5lZWQgYSBjaGFubmVsIHRvIGNvbnZleSBpdCB0byB0aGUgc2VydmVy LiBPYnZpb3VzbHksIGl0IGNhbm5vdCBiZSBleHRyYWN0ZWQgZnJvbSB0aGUNCiBpZGVudGl0eSBv ZiB0aGUgZ2F0ZXdheSBpdHNlbGYgYmVjYXVzZSBpdCBhZ2dyZWdhdGVzIG1hbnkgY2xpZW50cyAo dGhhdCBiZWxvbmdzIHRvIGRpc3RpbmN0IHN1YnNjcmliZXJzKS4gVGhlcmUgaXMgYSByb29tIGZv ciBhbiBvcHRpb25hbCBwYXJhbWV0ZXIgZm9yIHRoaXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi1UaXJ1PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48bzpwPjwvbzpwPjwvYT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERvdHMgWzxhIGhyZWY9Im1haWx0bzpkb3RzLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBPY3RvYmVyIDYsIDIwMTcgMTowNyBQTTxicj4NCjxiPlRvOjwvYj4gSm9uIFNoYWxsb3cg Jmx0OzxhIGhyZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tIj5zdXBqcHMtaWV0 ZkBqcHNoYWxsb3cuY29tPC9hPiZndDs7ICdEb2JiaW5zLCBSb2xhbmQnICZsdDs8YSBocmVmPSJt YWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0OzsNCjxh IGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5JIGRpc2FncmVlIHdpdGggdGhlIGZvbGxvd2luZyZuYnNwOzoNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHR5cGUgc3RyaW5nOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtPcmlnaW5h bCBDbGllbnQgSUQgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbiwgUkVRVUlSRUQgYW5kIGFkZGVk IHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHYXRld2F5LiZxdW90Ozs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5BIGdhdGV3YXkgbWF5IGJlIGluc3RydWN0ZWQgdGhlIHJldmVh bCB0aGUgb3JpZ2luYWwgY2xpZW50IGlkZW50aXR5IG9ubHkgaW4gc29tZSBkZXBsb3ltZW50cyAo bm90IGFsbCk7IG90aGVyd2lzZSBpdCBpcyB0aGUgZ2F0ZXdheSBpZGVudGlmeSB0aGF0DQogaXMg dXNlZCBieSB0aGUgcmVtb3RlIHNlcnZlci4gVGhlIGdhdGV3YXkgaWRlbnRpdHkgaXMgZXh0cmFj dGVkIGZyb20gdGhlIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkEgY29uZmlndXJhYmxlIHBhcmFtZXRlciB0byBlbmFibGUvZGlzYWJs ZSB0aGF0IHRoZSBvcmlnaW5hbCBjbGllbnQgaWRlbnRpdHkgaXMgcGFzc2VkLCBtYXkgYmUgY29u c2lkZXJlZCAoZGlzYWJsZWQgYnkgZGVmYXVsdCwgSU1PKS4gVGhlIG9yaWdpbmFsDQogY2xpZW50 IGlkZW50aXR5IGlzIHRoZXJlZm9yZSBvcHRpb25hbCwgbm90IG1hbmRhdG9yeS4gJm5ic3A7Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJUVywgaXQgbWF5IGJlIHdvcnRoIHRv IGNvbnNpZGVyIGEgZGVkaWNhdGVkIFlBTkcgbW9kdWxlIGZvciBET1RTIGdhdGV3YXlzLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRG90cyBb PGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRvdHMtYm91bmNl c0BpZXRmLm9yZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBKb24gU2hhbGxvdzxicj4NCjxi PkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSA1IG9jdG9icmUgMjAxNyAxMzozNTxicj4NCjxiPsOA Jm5ic3A7OjwvYj4gJ0RvYmJpbnMsIFJvbGFuZCc7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxl bmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgdGhl IHVzZSBvZiDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0gaXMgYSAqPGI+bXVzdDwvYj4qLCB0aGVu IEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIGNoYW5nZXMuJm5ic3A7IEl0IGlzIGRlZmluZWQgYXMg YW4gYXJyYXkgc2hvdWxkIHRoZXJlIGJlIGEgY2xpZW50LWlkDQogbmFtZSBjbGFzaCBhbmQgYSBz ZWNvbmQgKG9yIG1vcmUpIGVudHJ5IG5lZWRzIHRvIGJlIGFkZGVkIGJ5IGEgRE9UUyBHYXRld2F5 IGluIGEgbG9uZyBjaGFpbi4mbmJzcDsgSW4gbm9ybWFsIHVzZSwgaXQgaXMgZXhwZWN0ZWQgdGhh dCB0aGVyZSB3aWxsIG9ubHkgYmUgb25lIGVudHJ5LCBldmVuIHRob3VnaCBzZXZlcmFsIERPVFMg R2F0ZXdheXMgaGF2ZSBiZWVuIHBhc3NlZCB0aHJvdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGUgZm9sbG93aW5nIFlBTkcgY2hhbmdlcyBuZWVkIHRvIGJlIG1hZGUg dG8gdGhlIHNpZ25hbCBzcGVjIGFuZCBhc3NvY2lhdGVkIHJlZmVyZW5jZXMgdXBkYXRlZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyB0aGUgWUFORyBtb2R1bGUgJnF1b3Q7aWV0Zi1kb3RzLXNpZ25hbCZxdW90Oywgd2hp Y2ggaGFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7IHRoZSBmb2xsb3dpbmcgdHJlZSBzdHJ1Y3R1cmU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG1vZHVsZTogaWV0Zi1kb3RzLXNpZ25hbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tcncgbWl0aWdhdGlvbi1zY29wZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgc2NvcGUqIFttaXRpZ2F0aW9uLWlkXTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0tcncgbWl0aWdhdGlvbi1pZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBpbnQzMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgb3JpZ2luYWwtY2xpZW50LWlkKiZuYnNwOyZuYnNw OyBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJiM0MzstLXJ3IHRhcmdldC1pcCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDppcC1hZGRyZXNzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7LS1ydyB0YXJnZXQtcHJlZml4KiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBpbmV0OmlwLXByZWZpeDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tcncgdGFyZ2V0LXBvcnQtcmFuZ2UqIFtsb3dl ci1wb3J0IHVwcGVyLXBvcnRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGxvd2VyLXBvcnQmbmJzcDsmbmJz cDsmbmJzcDsgaW5ldDpwb3J0LW51bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB1cHBlci1wb3J0Jm5i c3A7Jm5ic3A7Jm5ic3A7IGluZXQ6cG9ydC1udW1iZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHRhcmdldC1wcm90b2Nv bCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGZxZG4qJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6ZG9tYWluLW5hbWU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0 MzstLXJ3IHVyaSombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aW5ldDp1cmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJiM0MzstLXJ3IGFsaWFzLW5hbWUqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmluZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbGlmZXRp bWU/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludDMyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPi0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIG1pdGlnYXRpb24tc2NvcGUgezxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtUb3AgbGV2ZWwg Y29udGFpbmVyIGZvciBhIG1pdGlnYXRpb24gcmVxdWVzdC4mcXVvdDs7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGxpc3Qgc2NvcGUgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBrZXkgbWl0aWdhdGlvbi1pZDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRp b24gJnF1b3Q7SWRlbnRpZmllciBmb3IgdGhlIG1pdGlnYXRpb24gcmVxdWVzdC4mcXVvdDs7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxl YWYgbWl0aWdhdGlvbi1pZCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgaW50MzI7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRlc2NyaXB0aW9uICZxdW90O01pdGlnYXRpb24gcmVxdWVzdCBpZGVudGlmaWVy LiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBsaXN0IG9yaWdpbmFsLWNsaWVudC1pZCB7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5 cGUgc3RyaW5nOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtPcmlnaW5hbCBD bGllbnQgSUQgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbiwgUkVRVUlSRUQgYW5kIGFkZGVkIHdo ZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHYXRld2F5LiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmLWxpc3QgdGFy Z2V0LWlwIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBpbmV0OmlwLWFkZHJlc3M7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZxdW90O0lQdjQgb3IgSVB2NiBhZGRyZXNzIGlkZW50aWZ5aW5nIHRoZSB0YXJnZXQuJnF1b3Q7 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLS0tPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHNpZ25hbC1jb25maWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstLXJ3IHNlc3Npb24taWQ/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludDMyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyYjNDM7LS1ydyBvcmlnaW5hbC1jbGllbnQtaWQqJm5i c3A7Jm5ic3A7IHN0cmluZyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7JiM0MzstLXJ3IGhlYXJ0YmVhdC1pbnRlcnZhbD8mbmJzcDsmbmJzcDsgaW50 MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IG1pc3Np bmctaGItYWxsb3dlZD8mbmJzcDsmbmJzcDsgaW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IG1heC1yZXRyYW5zbWl0PyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmIzQzOy0tcncgYWNrLXRpbWVvdXQ/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBhY2stcmFuZG9tLWZhY3Rvcj8mbmJzcDsmbmJzcDsm bmJzcDsgZGVjaW1hbDY0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7LS1ydyB0cmlnZ2VyLW1pdGlnYXRpb24/Jm5ic3A7Jm5ic3A7IEJvb2xlYW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb250YWluZXIg c2lnbmFsLWNvbmZpZyB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRl c2NyaXB0aW9uICZxdW90O1RvcCBsZXZlbCBjb250YWluZXIgZm9yIERPVFMgc2lnbmFsIGNoYW5u ZWwgc2Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBjb25maWd1cmF0aW9uLiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbGVhZiBzZXNzaW9uLWlkIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBpbnQzMjs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGVzY3Jp cHRpb24gJnF1b3Q7QW4gaWRlbnRpZmllciBmb3IgdGhlIERPVFMgc2lnbmFsIGNoYW5uZWw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vzc2lvbiBjb25maWd1cmF0aW9uIGRhdGEuJnF1b3Q7 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9Jm5ic3A7DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtsaXN0IG9yaWdpbmFsLWNsaWVu dC1pZCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHR5cGUgc3RyaW5nOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtPcmlnaW5h bCBDbGllbnQgSUQgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbiwgUkVRVUlSRUQgYW5kIGFkZGVk IHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHYXRld2F5LiZxdW90Ozs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBsZWFmIGhlYXJ0YmVhdC1pbnRlcnZhbCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhl IGZvbGxvd2luZyBZQU5HIGNoYW5nZXMgbmVlZCB0byBiZSBtYWRlIHRvIHRoZSBkYXRhIHNwZWMg YW5kIGFzc29jaWF0ZWQgcmVmZXJlbmNlcyB1cGRhdGVkPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG1vZHVsZTogaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC1pZGVu dGlmaWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBpZGVudGlmaWVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBhbGlhcyogW2FsaWFzLW5h bWVdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7LS1ydyBhbGlhcy1uYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgb3JpZ2luYWwtY2xp ZW50LWlkKiZuYnNwOyBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHRhcmdldC1pcCombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDppcC1hZGRy ZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7LS1ydyB0YXJnZXQtcHJlZml4KiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBpbmV0OmlwLXByZWZpeDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdGFyZ2V0LXBvcnQtcmFuZ2UqIFtsb3dl ci1wb3J0IHVwcGVyLXBvcnRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGxvd2VyLXBvcnQmbmJzcDsmbmJz cDsmbmJzcDsgaW5ldDpwb3J0LW51bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB1cHBlci1wb3J0Jm5i c3A7Jm5ic3A7Jm5ic3A7IGluZXQ6cG9ydC1udW1iZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHRhcmdldC1wcm90b2Nv bCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGZxZG4qJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6ZG9tYWluLW5hbWU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHVyaSo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBj b250YWluZXIgaWRlbnRpZmllciB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGRlc2NyaXB0aW9uICZxdW90O3RvcCBsZXZlbCBjb250YWluZXIgZm9yIGlkZW50aWZpZXJz JnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBsaXN0IGFsaWFzIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsga2V5IGFsaWFzLW5hbWU7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGRlc2NyaXB0aW9uICZxdW90O2xpc3Qgb2YgaWRlbnRpZmllcnMmcXVvdDs7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgYWxpYXMtbmFtZSB7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgc3RyaW5nOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlw dGlvbiAmcXVvdDthbGlhcyBuYW1lJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpc3Qgb3JpZ2lu YWwtY2xpZW50LWlkIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBzdHJpbmc7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uICZxdW90O09yaWdp bmFsIENsaWVudCBJRCByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uLCBSRVFVSVJFRCBhbmQgYWRk ZWQgd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdhdGV3YXkuJnF1b3Q7OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGxlYWYtbGlzdCB0YXJnZXQtaXAgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+LS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0OmFjY2Vzcy1saXN0cyBpcyBtb3JlIGNv bXBsaWNhdGVkLiZuYnNwOyBXaXRoIHRoZSBpbnRyb2R1Y3Rpb24gb2Yg4oCYY29udGFpbmVyIGlu dGVyZmFjZXPigJkgaW4gZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTE0DQogdGhlIHRleHQg aW4gZ2VuZXJhbCBpbiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsIG5lZWRzIHVwZGF0aW5n LiZuYnNwOyBUaGlzIGNoYW5nZSBpbiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTQgZ2l2 ZXMgdXMgdGhlIGFiaWxpdHkgdG8gYXR0YWNoIGEgc3BlY2lmaWMgc2V0IG9mIHNvcnRlZCBBQ0xz IHRvIGFuIGludGVyZmFjZSwgYnV0IHN0aWxsIGRvZXMgbm90IGVhc2lseSBhc3NvY2lhdGUgYSBz ZXQgb2YgQUNMIGRlZmluaXRpb25zIHdpdGgNCiBhIHBhcnRpY3VsYXIgY2xpZW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBzdWdnZXN0aW9uIGlzIHRoYXQgd2UgYWRk IGluIGFuIGFkZGl0aW9uYWwgSlNPTiBlbnRyeSBhcyBmb2xsb3dzLCB3aXRoIHRoZSBZQU5HIG1v ZHVsZSBtb2R1bGUgaWV0Zi1kb3RzLWFjY2Vzcy1jb250cm9sLWxpc3QgdXBkYXRlZCAobXkgWUFO Rw0KIGlzIG5vdCBjdXJyZW50bHkgdXAgdG8gZG9pbmcgdGhhdCkgdGhhdCBkZWZpbmVzIHdoYXQg d2UgYXJlIGRvaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IFBP U1QgL3Jlc3Rjb25mL2RhdGEvaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0IEhUVFAvMS4xPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IEhvc3Q6DQo8YSBocmVm PSJodHRwOi8vd3d3LmV4YW1wbGUuY29tIj53d3cuZXhhbXBsZS5jb208L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IENvbnRlbnQtRm9ybWF0OiAmcXVv dDthcHBsaWNhdGlvbi95YW5nLmFwaSYjNDM7anNvbiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZxdW90O29yaWdpbmFsLWNsaWVudC1pZCZxdW90 OyA6IFsmcXVvdDtzdHJpbmcmcXVvdDsgXSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2lldGYtYWNjZXNzLWNvbnRyb2wt bGlzdDphY2Nlc3MtbGlzdHMmcXVvdDs6IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YWNsJnF1b3Q7 OiBbPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltBbmQgc2hvdWxkIG5vdCB3 ZSBiZSBwb3N0aW5nIHRvIC9yZXN0Y29uZi9kYXRhL2lldGYtPC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5kb3RzPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LWFjY2Vzcy1j b250cm9sLWxpc3QNCiBhbnl3YXk/XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkpvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBEb3RzIFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5k b3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Eb2JiaW5zLCBS b2xhbmQ8YnI+DQo8Yj5TZW50OjwvYj4gMDUgT2N0b2JlciAyMDE3IDEwOjQyPGJyPg0KPGI+VG86 PC9iPiA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PGJyPg0KT24gT2N0IDUsIDIw MTcsIGF0IDE0OjU4LCBKb24gU2hhbGxvdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRm QGpwc2hhbGxvdy5jb20iPnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5QZXJoYXBzICZxdW90O29yaWdpbmFsLWNsaWVudC1pZCZx dW90OyB3b3VsZCBiZSBhIGJldHRlciBuYW1lIC0gaW4gYSBzaW1pbGFyIHNvcnQgb2Ygd2F5IHRo YXQgdGhlICZxdW90O1gtRm9yd2FyZGluZy1Gb3I6JnF1b3Q7IGhlYWRlciBwcm92aWRlcyB0aGUg b3JpZ2luYWwgSVAgbWFraW5nIHRoZSBIVFRQIHJlcXVlc3Qgd2hlbiBwYXNzaW5nIHRocm91Z2gg YSBsb2FkLWJhbGFuY2VyIG9yIFNTTCB0ZXJtaW5hdG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhpcyBpcyBob3cgaXQgKm11c3QqIHdvcmssIGFn cmVlZDsgSSByZW1lbWJlciBkaXNjdXNzaW5nIHRoaXMgdG9waWMgYXQgb25lIG9mIHRoZSBXRyBt ZWV0aW5ncywgc3BlY2lmaWNhbGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+SWYgaXQgc29tZWhvdyB3YXMgZHJvcHBlZCwgd2UgbmVlZCB0byBmaXgg aXQuICZuYnNwO0dhdGV3YXlzIGFyZSBhIG5lY2Vzc2FyeSBpbml0aWFsIGNhcGFiaWxpdHksIGFz IGlzIHByZXNlcnZpbmcgRE9UUyBjbGllbnQgSURzIGFjcm9zcyB0aGVtLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLUdCIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ Um9sYW5kIERvYmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiPnJk b2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93300A0507C1OPEXCLILMA3corp_-- From nobody Fri Oct 6 12:48:10 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40EE134C7E for ; Fri, 6 Oct 2017 12:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lCU-_FS3ZyS for ; Fri, 6 Oct 2017 12:48:07 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 2C996134C77 for ; Fri, 6 Oct 2017 12:48:07 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e0YbN-00062n-Db; Fri, 06 Oct 2017 20:48:05 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> <00a101d32d46$b2f30cf0$18d926d0$@jpshallow.com> <037c01d33a2c$ed764700$c862d500$@jpshallow.com> <040401d33ac9$85542c80$8ffc8580$@jpshallow.com> <060201d33c52$ca5ca390$5f15eab0$@jpshallow.com> In-Reply-To: Date: Fri, 6 Oct 2017 20:48:06 +0100 Message-ID: <097101d33edc$0770b330$16521990$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJWDLbdGWgIliMeta88DlSb7Xyh6wERxjbqAVIVJZ8CskQHRgGAczJ7AlDJcXkCdZkf6AHJEO5BoWhtbaA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 19:48:09 -0000 Hi Tiru >> >> So, should it be displayed (in JSON) as UTC, local timezone or simply seconds? >> >> Mitigation-start: 2017-10-03T10:15:30-05:00 Or >> Mitigation-start: 2017-10-03T15:15:30Z Or >> Mitigation-start: 1507040181.567890 > Mitigation-start: 1507040181.567890 (represented in JSON number format). > -Tiru If you could add this " Mitigation-start: 1507040181.567890" into the spec as part of Fig 10, this would be great. However Tagged CBOR -> JSON is fine, but JSON -> CBOR will not create the tagged entry in CBOR. Regards Jon From nobody Fri Oct 6 13:14:48 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443CF134C88 for ; Fri, 6 Oct 2017 13:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6buzOQCi2Ja1 for ; Fri, 6 Oct 2017 13:14:44 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 A550C134C73 for ; Fri, 6 Oct 2017 13:14:43 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e0Z17-00063n-0n; Fri, 06 Oct 2017 21:14:41 +0100 From: "Jon Shallow" To: , References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0507C1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0507C1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Fri, 6 Oct 2017 21:14:41 +0100 Message-ID: <097301d33edf$be7ba640$3b72f2c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0974_01D33EE8.20445400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIALaw1YmortR1WA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 20:14:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0974_01D33EE8.20445400 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, =20 Comment inline. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com Sent: 06 October 2017 15:45 To: Konda, Tirumaleswar Reddy; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: Re: [Dots] DOTS Gateways Challenges =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=C3=A9 : vendredi 6 octobre 2017 15:58 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Objet : RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server.=20 [Med] Agree. [Jon] But we do need to transfer something in this session =E2=80=93 the = unique client-id =E2=80=93 see below =20 =E2=80=9CDOTS client identity=E2=80=9D looks required only for the = server-side DOTS gateways. [Med] Yes.=20 =20 In case of server-side DOTS gateway, it can convey the client-id = generated from the =E2=80=9CDOTS client identity=E2=80=9D to the DOTS = server. The DOTS gateway can generate a unique client-id and does not = have to send an array of client-ids to the DOTS server to resolve = clashes.=20 [Med] Whatever the mechanism used to generate that id, we will need a = channel to convey it to the server. Obviously, it cannot be extracted = from the identity of the gateway itself because it aggregates many = clients (that belongs to distinct subscribers). There is a room for an = optional parameter for this.=20 =20 [Jon] Agreed that support for this additional parameter is required and = it needs to be conveyed at the CBOR / RESTCONF layer =E2=80=93 which I = initially suggested (badly) as =E2=80=9Coriginal-client-id=E2=80=9D. =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com Sent: Friday, October 6, 2017 1:07 PM To: Jon Shallow ; 'Dobbins, Roland' = ; dots@ietf.org Subject: Re: [Dots] DOTS Gateways Challenges =20 Re-, =20 I disagree with the following :=20 =20 type string; description "Original Client ID requesting the = mitigation, REQUIRED and added when passing through a DOTS Gateway."; } =20 A gateway may be instructed the reveal the original client identity only = in some deployments (not all); otherwise it is the gateway identify that = is used by the remote server. The gateway identity is extracted from the = authentication credentials.=20 =20 A configurable parameter to enable/disable that the original client = identity is passed, may be considered (disabled by default, IMO). The = original client identity is therefore optional, not mandatory. =20 =20 BTW, it may be worth to consider a dedicated YANG module for DOTS = gateways.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=C3=A9 : jeudi 5 octobre 2017 13:35 =C3=80 : 'Dobbins, Roland'; dots@ietf.org Objet : Re: [Dots] DOTS Gateways Challenges =20 As the use of =E2=80=9Coriginal-client-id=E2=80=9D is a *must*, then I = propose the following changes. It is defined as an array should there = be a client-id name clash and a second (or more) entry needs to be added = by a DOTS Gateway in a long chain. In normal use, it is expected that = there will only be one entry, even though several DOTS Gateways have = been passed through. =20 The following YANG changes need to be made to the signal spec and = associated references updated =20 This document defines the YANG module "ietf-dots-signal", which has the following tree structure: =20 module: ietf-dots-signal +--rw mitigation-scope +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw original-client-id* string +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port inet:port-number +--rw target-protocol* uint8 +--rw fqdn* inet:domain-name +--rw uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 =20 ---- container mitigation-scope { description "Top level container for a mitigation request."; =20 list scope { key mitigation-id; description "Identifier for the mitigation request."; leaf mitigation-id { type int32; description "Mitigation request identifier."; } list original-client-id { type string; description "Original Client ID requesting the = mitigation, REQUIRED and added when passing through a DOTS Gateway."; } leaf-list target-ip { type inet:ip-address; description "IPv4 or IPv6 address identifying the target."; } ---- signal-config +--rw session-id? int32 +--rw original-client-id* string =20 +--rw heartbeat-interval? int16 +--rw missing-hb-allowed? int16 +--rw max-retransmit? int16 +--rw ack-timeout? int16 +--rw ack-random-factor? decimal64 +--rw trigger-mitigation? Boolean --- container signal-config { description "Top level container for DOTS signal channel = session configuration."; =20 leaf session-id { type int32; description "An identifier for the DOTS signal channel session configuration data."; } =20 list original-client-id { type string; description "Original Client ID requesting the mitigation, = REQUIRED and added when passing through a DOTS Gateway."; } =20 leaf heartbeat-interval { =20 --- The following YANG changes need to be made to the data spec and = associated references updated =20 module: ietf-dots-data-channel-identifier +--rw identifier +--rw alias* [alias-name] +--rw alias-name string +--rw original-client-id* string +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port inet:port-number +--rw target-protocol* uint8 +--rw fqdn* inet:domain-name +--rw uri* --- container identifier { description "top level container for identifiers"; list alias { key alias-name; description "list of identifiers"; leaf alias-name { type string; description "alias name"; } list original-client-id { type string; description "Original Client ID requesting the = mitigation, REQUIRED and added when passing through a DOTS Gateway."; } leaf-list target-ip { --- The ietf-access-control-list:access-lists is more complicated. With the = introduction of =E2=80=98container interfaces=E2=80=99 in = draft-ietf-netmod-acl-model-14 the text in general in = draft-ietf-dots-data-channel needs updating. This change in = draft-ietf-netmod-acl-model-14 gives us the ability to attach a specific = set of sorted ACLs to an interface, but still does not easily associate = a set of ACL definitions with a particular client. =20 My suggestion is that we add in an additional JSON entry as follows, = with the YANG module module ietf-dots-access-control-list updated (my = YANG is not currently up to doing that) that defines what we are doing. =20 POST /restconf/data/ietf-access-control-list HTTP/1.1 Host: www.example.com Content-Format: "application/yang.api+json" { "original-client-id" : ["string" ],=20 "ietf-access-control-list:access-lists": { "acl": [ =20 [And should not we be posting to = /restconf/data/ietf-dots-access-control-list anyway?] =20 Regards =20 Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Dobbins, Roland Sent: 05 October 2017 10:42 To: dots@ietf.org Subject: Re: [Dots] DOTS Gateways Challenges =20 =20 On Oct 5, 2017, at 14:58, Jon Shallow wrote: Perhaps "original-client-id" would be a better name - in a similar sort = of way that the "X-Forwarding-For:" header provides the original IP = making the HTTP request when passing through a load-balancer or SSL = terminator. =20 This is how it *must* work, agreed; I remember discussing this topic at = one of the WG meetings, specifically. =20 If it somehow was dropped, we need to fix it. Gateways are a necessary = initial capability, as is preserving DOTS client IDs across them. =20 ----------------------------------- Roland Dobbins ------=_NextPart_000_0974_01D33EE8.20445400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Comment inline.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 06 October 2017 = 15:45
To: Konda, Tirumaleswar Reddy; Jon Shallow; 'Dobbins, = Roland'; dots@ietf.org
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, = Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=C3=A9 : vendredi 6 = octobre 2017 15:58
=C3=80 : BOUCADAIR Mohamed IMT/OLN; = Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Objet : = RE: [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server.

[Med] = Agree.

[Jon] But we do need to transfer something in this session =E2=80=93 = the unique client-id =E2=80=93 see below

=

 

=E2=80=9CDO= TS client identity=E2=80=9D looks required only for the server-side DOTS = gateways.

[Med] = Yes.

 

In case of = server-side DOTS gateway, it can convey the client-id generated from the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. The DOTS = gateway can generate a unique client-id and does not have to send an = array of client-ids to the DOTS server to resolve clashes. =

[Med] = Whatever the mechanism used to generate that id, we will need a channel = to convey it to the server. Obviously, it cannot be extracted from the = identity of the gateway itself because it aggregates many clients (that = belongs to distinct subscribers). There is a room for an optional = parameter for this.

 

[Jon] Agreed that support for this additional parameter is required = and it needs to be conveyed at the CBOR / RESTCONF layer =E2=80=93 which = I initially suggested (badly) as = =E2=80=9Coriginal-client-id=E2=80=9D.

 

-Tiru

 =

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Friday, October 6, 2017 1:07 PM
To: Jon = Shallow <supjps-ietf@jpshallow.com&g= t;; 'Dobbins, Roland' <rdobbins@arbor.net>; dots@ietf.org
Subject: Re: = [Dots] DOTS Gateways Challenges

 

Re-,

 

I disagree with the following : =

 

         = ;       type = string;

         = ;       description "Original Client = ID requesting the mitigation, REQUIRED and added when passing through a = DOTS Gateway.";

         = ;    }

 

A gateway may be instructed the reveal the original = client identity only in some deployments (not all); otherwise it is the = gateway identify that is used by the remote server. The gateway identity = is extracted from the authentication credentials. =

 

A configurable parameter to enable/disable that the = original client identity is passed, may be considered (disabled by = default, IMO). The original client identity is therefore optional, not = mandatory.   

 

BTW, it may be worth to consider a dedicated YANG = module for DOTS gateways.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=C3=A9 : jeudi 5 = octobre 2017 13:35
=C3=80 : 'Dobbins, Roland'; = dots@ietf.org
Objet : = Re: [Dots] DOTS Gateways Challenges

 

As the use of =E2=80=9Coriginal-client-id=E2=80=9D is a = *must*, then I propose the following changes.  It is defined = as an array should there be a client-id name clash and a second (or = more) entry needs to be added by a DOTS Gateway in a long chain.  = In normal use, it is expected that there will only be one entry, even = though several DOTS Gateways have been passed = through.

 

The following YANG changes need to be made to the signal spec and = associated references updated

 

   This document defines the YANG module = "ietf-dots-signal", which has

   the following tree = structure:

 

   module: = ietf-dots-signal

       +--rw = mitigation-scope

         = ; +--rw scope* [mitigation-id]

         = ;    +--rw = mitigation-id         = int32

         = ;    +--rw original-client-id*   = string

         = ;    +--rw = target-ip*          &nb= sp; inet:ip-address

         = ;    +--rw = target-prefix*        = inet:ip-prefix

         =     +--rw target-port-range* [lower-port = upper-port]

         = ;    |  +--rw lower-port    = inet:port-number

         = ;    |  +--rw upper-port    = inet:port-number

         = ;    +--rw target-protocol*      = uint8

         = ;    +--rw = fqdn*           &n= bsp;     inet:domain-name

         = ;    +--rw = uri*           &nb= sp;      inet:uri

         = ;    +--rw = alias-name*           = string

         = ;    +--rw = lifetime?          &nbs= p;  int32

 

----

     container mitigation-scope = {

         = ; description

         = ;    "Top level container for a mitigation = request.";

 

         = ; list scope {

         = ;    key mitigation-id;

         = ;    description "Identifier for the mitigation = request.";

         = ;    leaf mitigation-id {

         = ;       type = int32;

         = ;       description "Mitigation = request identifier.";

         = ;    }

         = ;    list original-client-id {

         = ;       type = string;

         = ;       description "Original Client = ID requesting the mitigation, REQUIRED and added when passing through a = DOTS Gateway.";

         = ;    }

         = ;    leaf-list target-ip {

         = ;       type = inet:ip-address;

         = ;       = description

         = ;          "IPv4 or = IPv6 address identifying the target.";

         = ;    }

----

       = signal-config

         = ; +--rw = session-id?           = int32

        =   +--rw original-client-id*   string  =

         = ; +--rw heartbeat-interval?   = int16

         = ; +--rw missing-hb-allowed?   int16

         = ; +--rw max-retransmit?       = int16

         = ; +--rw = ack-timeout?          = int16

         = ; +--rw ack-random-factor?    = decimal64

         = ; +--rw trigger-mitigation?   Boolean

---

     container signal-config = {

         = ; description "Top level container for DOTS signal channel = session

         = ;            =   configuration.";

 

         = ; leaf session-id {

         = ;     type int32;

   =            descrip= tion "An identifier for the DOTS signal = channel

         = ;            =       session configuration = data.";

         = ; } 

         = ; list original-client-id {

         = ;     type string;

         = ;     description "Original Client ID = requesting the mitigation, REQUIRED and added when passing through a = DOTS Gateway.";

         = ; }

 

         = ; leaf heartbeat-interval {

 

---

The following YANG changes need to be made to the data spec and = associated references updated

 

   module: = ietf-dots-data-channel-identifier

       +--rw = identifier

         = ; +--rw alias* [alias-name]

         = ;    +--rw = alias-name           = string

         = ;    +--rw original-client-id*  = string

         = ;    +--rw = target-ip*           = inet:ip-address

         = ;    +--rw = target-prefix*       = inet:ip-prefix

         = ;    +--rw target-port-range* [lower-port = upper-port]

         = ;    |  +--rw lower-port    = inet:port-number

         = ;    |  +--rw upper-port    = inet:port-number

         = ;    +--rw target-protocol*     = uint8

         = ;    +--rw = fqdn*           &n= bsp;    inet:domain-name

         = ;    +--rw uri*

---

     container identifier = {

         = ; description "top level container for = identifiers";

         = ;     list alias {

         = ;          key = alias-name;

         = ;          description = "list of identifiers";

         = ;          leaf alias-name = {

         = ;            = type string;

         = ;            = description "alias name";

         = ;          = }

         = ;          list = original-client-id {

         = ;            =   type string;

         = ;            =   description "Original Client ID requesting the mitigation, = REQUIRED and added when passing through a DOTS = Gateway.";

         = ;          = }

         = ;          leaf-list = target-ip {

---

The ietf-access-control-list:access-lists is more complicated.  = With the introduction of =E2=80=98container interfaces=E2=80=99 in = draft-ietf-netmod-acl-model-14 the text in general in = draft-ietf-dots-data-channel needs updating.  This change in = draft-ietf-netmod-acl-model-14 gives us the ability to attach a specific = set of sorted ACLs to an interface, but still does not easily associate = a set of ACL definitions with a particular = client.

 

My suggestion is that we add in an additional JSON entry as follows, = with the YANG module module ietf-dots-access-control-list updated (my = YANG is not currently up to doing that) that defines what we are = doing.

 

  = POST /restconf/data/ietf-access-control-list = HTTP/1.1

  = Host: www.example.com

=

  Content-Format: = "application/yang.api+json"

  {

   "original-client-id" : = ["string" ],

   "ietf-access-control-list:acce= ss-lists": {

      "acl": = [

 

[And should not we be posting to /restconf/data/ietf-d= ots-access-control-list anyway?]

 

Regards

 

Jon

From:= Dots = [mailto: dots-bounces@ietf.org] On = Behalf Of Dobbins, Roland
Sent: 05 October 2017 = 10:42
To: dots@ietf.org
Subject: Re: = [Dots] DOTS Gateways Challenges

 

 


On Oct 5, 2017, at 14:58, Jon Shallow = <supjps-ietf@jpshallow.com&g= t; wrote:

Perhaps "original-client-id" would be a = better name - in a similar sort of way that the = "X-Forwarding-For:" header provides the original IP making the = HTTP request when passing through a load-balancer or SSL = terminator.

 

This is = how it *must* work, agreed; I remember discussing this topic at one of = the WG meetings, specifically.

 

If it somehow was dropped, we need to fix it. =  Gateways are a necessary initial capability, as is preserving DOTS = client IDs across them.

 

-----------------------------------

Roland Dobbins <rdobbins@arbor.net><= /p>

------=_NextPart_000_0974_01D33EE8.20445400-- From nobody Fri Oct 6 13:33:31 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE485134C84 for ; Fri, 6 Oct 2017 13:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgAtpDVEXCV6 for ; Fri, 6 Oct 2017 13:33:26 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 5C859134C9B for ; Fri, 6 Oct 2017 13:33:26 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e0ZJE-00064M-Kp; Fri, 06 Oct 2017 21:33:24 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A050387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0506A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 6 Oct 2017 21:33:25 +0100 Message-ID: <098901d33ee2$5c3478b0$149d6a10$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_098A_01D33EEA.BDFCFF60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFSg1IOmvyw/QR4DyHE01ic1cgMDAGpyfFOAh5uDMMCAHhKFQHQoSRQAj9UiokCbRRdiaN2jLIg Content-Language: en-gb Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 20:33:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_098A_01D33EEA.BDFCFF60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Guys, =20 > Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-interval). =20 If heartbeat-interval is not defined / negotiated =96 what happens in = peace time? What rate should the heartbeats be sent at? =20 If COAP Pings are timing out =96 yes, the length of time before the = timeout is reported to the upper layers is dependent on max-retransmit, ack-timeout = and ack-random-factor at which point a COAP ping could get re-transmitted. = But does the peace time COAP Ping transmission rate have to be greater or = equal to the COAP layer reporting the =93Ping=94 CON has failed? =20 In war time, the next COAP Ping should be delayed until after the = current COAP Ping has expired. =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy Sent: 06 October 2017 15:00 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval =20 Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-interval). =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, October 6, 2017 7:12 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval =20 Tiru, =20 We are on the same page for (1). I hope we will hear more voices on this before we add some text to the draft to clarify missing points.=20 =20 Please see inline for (2). =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 6 octobre 2017 15:08 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] Minimum heartbeat-interval =20 Hi Med, =20 Please see inline [TR] =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, October 6, 2017 12:40 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval =20 Hi Tiru, all,=20 =20 Please see inline.=20 =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy [ = mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : jeudi 5 octobre 2017 12:54 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Minimum heartbeat-interval =20 http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds.=20 =20 Responses to the questions below=20 =20 1) The max-retransmit parameter is negotiable and configurable, DOTS = agents can pick suitable values for max-retransmit parameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).=20 =20 [Med] You are right about the configurable aspect, but the question from = Jon is a good one. I interpret it in another way:=20 - Should we rely solely on the missing-hb-allowed to detect a session problem? =20 [TR] If the DOTS agent does not receive a response to =93CoAP ping=94 = but receives other type of messages from the peer DOTS agent then a counter incremented each time there is no response to a =93CoAP ping=94 till the = counter value hits missing-hb-allowed to determine the session is defunct can be reset to zero. - Should we get rid of missing-hb-allowed, but rely on the = retransmission to declare failure or not? =20 [TR] If DOTS agents only rely on the retransmission mechanism then a = =93CoAP ping=94 message will only be retransmitted 4 times before concluding the session is disconnected in an interval of 93 seconds. The network under = DDoS attack is likely to be congested (high packet loss and latency), hence missing-hb-allowed is used to send the =93CoAP ping=94 more number of = times (3 (ping) + 3*4 (re-transmissions) =3D 15 times) with sufficient time = interval (93*3 =3D 279 seconds) to determine the session is defunct.=20 =20 - What is the advantage of cumulating both missing-hb-allowed and the retransmission procedure to declare a channel out? =20 [TR] Please see above. =20 2) No, [Med] I agree that a heartbeat does not need to be fired when the first = ping is still alive. We can clarify this in the draft.=20 =20 [TR] Thanks.=20 =20 if the DOTS agent wants to change the default heartbeat interval then = the other message transmission parameters will also have to be modified.=20 [Med] I disagree here that the other parameters need to be changed. I = don=92t see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I = agree that we need to tweak heartbeat-interval as a function of MAX_TRANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from = other parameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR)). This is why it does not make sense to provide a configuration for MAX_TRANSMIT_WAIT if the other parameters are = provided.=20 =20 [TR] I did not get the above, the draft is not providing any new configuration for MAX_TRANSMIT_WAIT [Med] I was talking about heartbeat-interval. =20 . If let=92s say the DOTS agents decide to change the heartbeat interval = to 45 seconds then the max-retransmit has to be changed to 3 to arrive at 45 second MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new heartbeat interval). [Med] My comment is that if heartbeat-interval was dependent on = transmission parameters, then we do not need to configure it explicitly IN ADDITION = to the other transmission parameter. =20 =20 How can the heartbeat interval change without changing the message transmission parameters ? [Med] I do see these two as separate parameters. The heartbeat-interval determines the frequency of sending keeplaive messages. This is an additional transmission parameter specific to heartbeat if you will. =20 -Tiru =20 =20 3) The client will have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1= ) and initiate (D)TLS session resumption=20 4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The = heartbeat expires only after 273 seconds (3 =93CoAP ping=94 confirmable messages, = each=20 =93CoAP ping=94 re-transmitted 4 times).=20 =20 Med =96 In the below text, recommended value should be 93 seconds = instead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2).=20 =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval =20 Hi Mohamed, =20 In principal I agree with your suggested updates =96 the minimum of 10s = was an off the cuff response, to handle the =93broken=94 NAT timing = implementations out there. =20 =20 The Heartbeat mechanism does raise a few questions in my mind which do = need to be thought through. On a DOTS server, using a heartbeat interval of = 15 secs, with the client going away circa 10:54:30, I get =20 Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: give up after 4 attempts =20 Here we see the 91 seconds (dependant on the max-retransmit value being = 4) 10:56:09 =96 10:54:39. There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 = before retry transmission #4). =20 Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that = we do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to = be in peace time) and heartbeats, not mitigation requests =20 Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds =96 say 60 seconds and = the first heartbeat ping is still active, should a second heartbeat be fired off? - I think not, but the text then needs to get updated to state the = interval is used whenever there is not a pending heartbeat response outstanding. =20 Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Heartbeat checks are being initiated by the client. The client gets a heartbeat timeout on the session. The client subsequently needs to send = a PUT mitigate request. =20 Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. =20 Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Scenario as Q3 =20 Does the client re-use the old session that the heartbeats are failing = on? - The server may have sent a session close, but it never got through =20 Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 When the heartbeats are initiated by the server, and the heartbeat times out, the session is =93bad=94, but the current mitigation request = continues until it expires. The client may have kicked off his heartbeats at a different time, and = there likely will be a sending frequency drift over time, so the client may = think the session is still active, the server not, and the client decides it = is time to send a non-confirmable PUT to refresh the mitigation as it is = about to expire or possibly another PUT for a different IP that has just = started to get hammered =96 hence heartbeat failures. =20 Alternatively the client decides that the reason for =93bad=94 session = (from the client=92s perspective) is an attack stopping traffic getting through = and needs to do a PUT on the existing session. =20 So server receives a PUT (refresh or for a new IP) on a session that has heartbeat expired. The session contained all the negotiated PKI session keys etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in = peace time. - I believe the session on the server needs to be kept hanging around = for some time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may = answer how to keep =93bad=94 session hanging around] =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com) Subject: [Dots] Minimum heartbeat-interval =20 Dear all,=20 =20 Jon made the following comment during the interim meeting: =93A: (Jon Shallow): The minimum for the heartbeat should be 10s=94 =20 Actually, the use of 10s is not aligned with RFC8085 which says the following:=20 =20 An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. =20 =20 I suggest to add this NEW text to the signal-channel draft to clarify = the rationale for the recommended values:=20 =20 NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). =20 Thoughts?=20 =20 Cheers, Med ------=_NextPart_000_098A_01D33EEA.BDFCFF60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Guys,

 

> Thanks Med, agreed on = (2) (no need to negotiate and configure = heartbeat-interval).

 

If heartbeat-interval is = not defined / negotiated – what happens in peace time?=A0 What = rate should the heartbeats be sent at?

 

If COAP Pings are timing = out – yes, the length of time before the timeout is reported to = the upper layers is dependent on max-retransmit, ack-timeout and = ack-random-factor at which point a COAP ping could get re-transmitted. = =A0=A0But does the peace time COAP Ping transmission rate have to be = greater or equal to the COAP layer reporting the “Ping” CON = has failed?

 

In war time, the next = COAP Ping should be delayed until after the current COAP Ping has = expired.

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 October 2017 = 15:00
To: mohamed.boucadair@orange.com; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] Minimum = heartbeat-interval

 

Thanks Med, agreed on = (2) (no need to negotiate and configure = heartbeat-interval).

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, October 6, 2017 7:12 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] Minimum heartbeat-interval

 

Tiru,

 

We are on the same page for (1). I hope we will hear more voices on this before we add = some text to the draft to clarify missing points. =

 

Please see inline for (2).

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 6 octobre 2017 15:08
=C0 : BOUCADAIR Mohamed = IMT/OLN; Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] Minimum = heartbeat-interval

 

Hi Med,

 

Please see inline = [TR]

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, October 6, 2017 12:40 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] Minimum heartbeat-interval

 

Hi = Tiru, all,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-l= anguage:FR'>]
Envoy=E9 : jeudi 5 octobre 2017 = 12:54
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org
Objet : RE: [Dots] Minimum = heartbeat-interval

 

http://c= onferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/= rfc7925 has tested NAT behavior with various routers and lists the = timeout results. The majority of the devices (62%) have a timeout = between 2 and 2.5 minutes and the minimum timeout value observed when = packets are exchanged b/w peers in both directions is 54 seconds. =

 

Responses to the = questions below

 

1) The = max-retransmit parameter is negotiable and configurable,  DOTS = agents can pick suitable values for max-retransmit parameter based on = the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the = MAX_TRANSMIT_WAIT to 45 seconds).

&n= bsp;

[Med] You are right about = the configurable aspect, but the question from Jon is a good one. I = interpret it in another way:

-   = Should we rely solely on = the missing-hb-allowed to detect a session = problem?

 

[TR] If the DOTS agent does not = receive a response to “CoAP ping” but receives other type of = messages from the peer DOTS agent then a counter incremented each time = there is no response to a “CoAP ping” till the counter value = hits missing-hb-allowed to determine the session is defunct can be reset = to zero.

-   = Should we get rid of = missing-hb-allowed, but rely on the retransmission to declare failure or = not?

 

[TR] If DOTS agents only rely on = the retransmission mechanism then a “CoAP ping” message will = only be retransmitted 4 times before concluding the session is = disconnected in an interval of 93 seconds. The network under DDoS attack = is likely to be congested (high packet loss and latency), hence = missing-hb-allowed is used to send the “CoAP ping” more = number of times (3 (ping) + 3*4 (re-transmissions) =3D 15 times) with = sufficient time interval (93*3 =3D 279 seconds) to determine the session = is defunct.

 

-   = What is the advantage of = cumulating both missing-hb-allowed and the retransmission procedure to = declare a channel out?

 

[TR] Please see = above.

 

=

2) No,

[Med] I agree that a = heartbeat does not need to be fired when the first ping is still alive. = We can clarify this in the draft.

 

[TR] Thanks. =

 

=

if the DOTS agent = wants to change the default heartbeat interval then the other message = transmission parameters will also have to be modified. =

[Med] I disagree here that = the other parameters need to be changed. I don’t see = heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree = that we need to tweak heartbeat-interval as a function of = MAX_TRANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from = other parameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * = ACK_RANDOM_FACTOR)). This is why it does not make sense to provide a = configuration for MAX_TRANSMIT_WAIT if the other parameters are = provided.

 

[TR] I did not get the above, the = draft is not providing any new configuration for MAX_TRANSMIT_WAIT

[Med] I was talking about = heartbeat-interval.

 

=

. If let’s say the DOTS = agents decide to change the heartbeat interval to 45 seconds then the = max-retransmit has to be changed to 3 to arrive at 45 second = MAX_TRANSMIT_WAIT value (or other message transmission parameters = ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new = heartbeat interval).

[Med] My comment is that if = heartbeat-interval was dependent on transmission parameters, then we do = not need to configure it explicitly IN ADDITION to the other = transmission parameter.  

 

=

How can the heartbeat interval = change without changing the message transmission parameters = ?

[Med] I do see these two as = separate parameters. The heartbeat-interval determines the frequency of = sending keeplaive messages. This is an additional transmission parameter = specific to heartbeat if you will.

 

-Tiru

 

 

=

3) The client will = have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#sec= tion-2.2.1) and initiate (D)TLS session resumption =

4) If heartbeat = expires then the DOTS server will close the (D)TLS session, the client = will have to initiate (D)TLS session resumption. The heartbeat expires = only after 273 seconds (3 “CoAP ping” confirmable messages, = each
“CoAP ping” re-transmitted 4 times). =

 

Med – In the = below text, recommended value should be 93 seconds instead of 90 seconds = (see https://tools.= ietf.org/html/rfc7252#section-4.8.2).

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Wednesday, October 4, = 2017 5:36 PM
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] Minimum heartbeat-interval

 

Hi = Mohamed,

 

In principal I agree = with your suggested updates – the minimum of 10s was an off the = cuff response, to handle the “broken” NAT timing = implementations out there. 

 

The Heartbeat mechanism = does raise a few questions in my mind which do need to be thought = through.  On a DOTS server, using a heartbeat interval of 15 secs, = with the client going away circa 10:54:30, I get

 

Oct 04 10:53:51 DEBG sending CoAP = ping:

Oct 04 = 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to retransmit queue = (2281ms)

Oct 04 = 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message = 29548

Oct 04 = 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending CoAP = ping:

Oct 04 = 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to retransmit queue = (2938ms)

Oct 04 = 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message = 29549

Oct 04 = 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending CoAP = ping:

Oct 04 = 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to retransmit queue = (2156ms)

Oct 04 = 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message = 29550

Oct 04 = 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending CoAP = ping:

Oct 04 = 10:54:39 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to retransmit queue = (2813ms)

Oct 04 = 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #1

Oct 04 10:54:42 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #2

Oct 04 10:54:48 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #3

Oct 04 10:55:00 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #4

Oct 04 10:55:23 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: give up after 4 attempts

 

Here we see the 91 = seconds (dependant on the max-retransmit value being 4) 10:56:09 – = 10:54:39.  There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 = before retry transmission #4).

 

Question = 1

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

Should the = max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON is only used for signal configuration = (infrequent, likely only to be in peace time) and heartbeats, not = mitigation requests

 

Question = 2

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

If the heartbeat = interval is less than 91 seconds – say 60 seconds and the first = heartbeat ping is still active, should a second heartbeat be fired = off?

- I think not, but the text then needs to get = updated to state the interval is used whenever there is not a pending = heartbeat response outstanding.

 

Question = 3

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

 

Heartbeat checks are = being initiated by the client.  The client gets a heartbeat timeout = on the session.  The client subsequently needs to send a PUT = mitigate request.

 

Does the client set up a = new session?

- Difficult as we are unlikely to be in peace = time

- PKI exchanges are likely to = fail

- the client just needs to send a = non-confirmable PUT.

 

Question = 4

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

 

Scenario as = Q3

 

Does the client re-use = the old session that the heartbeats are failing = on?

- The server may have sent a session close, but = it never got through

 

Question = 4

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

When the heartbeats are = initiated by the server, and the heartbeat times out, the session is = “bad”, but the current mitigation request continues until it = expires.

The client may have kicked off his heartbeats at = a different time, and there likely will be a sending frequency drift = over time, so the client may think the session is still active, the = server not, and the client decides it is time to send a non-confirmable = PUT to refresh the mitigation as it is about to expire or possibly = another PUT for a different IP that has just started to get hammered = – hence heartbeat failures. 

Alternatively the client = decides that the reason for “bad” session (from the = client’s perspective) is an attack stopping traffic getting = through and needs to do a PUT on the existing = session.

 

So server receives a PUT = (refresh or for a new IP) on a session that has heartbeat expired.  = The session contained all the negotiated PKI session keys etc.  = What should happen here?

- as the heartbeats are failing, it is safe to = assume we are not in peace time.

- I believe the session = on the server needs to be kept hanging around for some time post = heartbeat time-out. For how long?

- the server may be = seeing the client heartbeat messages [this may answer how to keep = “bad” session hanging around]

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots= -bounces@ietf.org] On Behalf Of ietf-supjps-moha= med.boucadair@orange.com
Sent: 04 October 2017 = 09:35
To: dots@ietf.org; = Jon Shallow (supjps-ietf@jpshallow.com)<= br>Subject: [Dots] Minimum = heartbeat-interval

 

Dear all, =

 

Jon = made the following comment during the interim meeting: = “A: (Jon Shallow): The minimum for the = heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with RFC8085 which says = the following:

 

   An application that needs to =
employ keep-alive messages to deliver
   useful service over UDP in =
the presence of middleboxes SHOULD NOT
       &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;  ^^^^^^^^^^^^^^^^^^^^^^
   transmit them more frequently =
than once every 15 seconds and SHOULD
 =
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^
   use longer intervals when =
possible. 

 

I = suggest to add this NEW text to the signal-channel draft to clarify the = rationale for the recommended values:

 

NEW:

      Note: heartbeat-interval should = be tweaked to also assist DOTS

      messages for NAT traversal = (SIG-010 of

      = [I-D.ietf-dots-requirements]).  According to [RFC8085], = keepalive

      messages must not be sent more = frequently than once every 15

      seconds and should use longer = intervals when possible.

      Furthermore, [RFC4787] = recommends NATs to use a state timeout of 2

      minutes or longer.  From = that standpoint, this specification

      recommends a minimum = heartbeat-interval of 15 seconds and a

      maximum heartbeat-interval of = 240 seconds.  The recommended value

      of 90 seconds is selected to = anticipate the expiry of NAT states,

      while avoiding overloading the = network with frequent keepalives

      for NAT state maintenance = purposes.  Note that this recommended

      value is close to the one = recommended for MAX_TRANSMIT_WAIT, whose

      value is derived from = transmission parameters (Section 4.8.2 of

      [RFC7252]).

 

Thoughts?

 

Cheers,

Med

------=_NextPart_000_098A_01D33EEA.BDFCFF60-- From nobody Fri Oct 6 20:08:02 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E950C13219B for ; Fri, 6 Oct 2017 20:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 YQZvBLMyBsaP for ; Fri, 6 Oct 2017 20:07:58 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 E913613219C for ; Fri, 6 Oct 2017 20:07:57 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507345677; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-exchange-antispam-report-test:x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=RAxUETmmAaMrElxqnG0XgO6DjXi1xCkto36jHx Jq+Sc=; b=WxPSzDXt289IUatLk3adzoNyHWBdpOYR4F3iQmX2 qdzRxRcEe0DC1pclSVii8UjDuds2I6rVNQHVSMXAdVCIUCth9m 2qqR+HGWjy9x5kdWg0c6H7SnZO2gaiuePlXJo0o/Oo/1tEg6P9 GnbfZK6ppFC1ocnb2RdjlvdATmrlDiU= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 2ead_0a1b_6cb298a3_c404_429a_ae86_88a4d97942f4; Fri, 06 Oct 2017 22:07:56 -0500 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 21:07:56 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 21:07:55 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Oct 2017 21:07:54 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 21:07:54 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sat, 7 Oct 2017 03:07:53 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.018; Sat, 7 Oct 2017 03:07:53 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Coding and Interoperability Challenges Thread-Index: AdMouv44Udo0NFExSCOHW+HXkRNTEQERxjbqAVIVJZ8CskQHRqGgxiVwoaSKVGC8uS4jAP/8yNewgAhJpAD//4ZJ0A== Date: Sat, 7 Oct 2017 03:07:53 +0000 Message-ID: References: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> <00a101d32d46$b2f30cf0$18d926d0$@jpshallow.com> <037c01d33a2c$ed764700$c862d500$@jpshallow.com> <040401d33ac9$85542c80$8ffc8580$@jpshallow.com> <060201d33c52$ca5ca390$5f15eab0$@jpshallow.com> <097101d33edc$0770b330$16521990$@jpshallow.com> In-Reply-To: <097101d33edc$0770b330$16521990$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.69.122.17] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:y+abltvzcAJUtNC1OTcE8E4003uhUh9T6FRxRPEzq3Zj/M3M1t1RFMI9pe8Blj3L/orSKchzEp7OxdLGPI/GoNJix0t/mbHMy/RwNT6s/uOK9rkuARoW6xa6C/Y710iJ7fciozTs9IANkKmaNsPiIrux5drEjb8jGXbBCQSREoOOoDoCWXpCcBmT6URoRzrDZbNhSKMowauGeGRqrD+sLSfxhnY0xw8qQmeiOo8CCK/bETpl2gSenKsbhPXJw1Y7BRpoyCU8uCdUFGi27XEGYxbovF8xfdc1BMcUZRSu/6akmpp/p5/PWSVIAzemDECV3aO1pZ0Uk+OEvI7IsH8aSg==; 5:HWdQELNPJKwowLZm0NrPK9cylRFLIsrnNxZYfXsxDQVQNo1gEGS6p2L91aPyarnGHmlXCp5YhGmK6dtfyw2Ce5DtRGauiCZkaQwiGTWrXAvTzTn94o/IIgt9usPySRZ1H84K7Ah/PJ1xHrH4EeJToA==; 24:rBzMovMdYwaQ0XRCzn4D6fvSWhyDHmEAswz2xJe8ZC6szV+51jrqSV5+NFWj++uiGuIQe+UU61yV48y1BZNCa0xwkxOcpqlk9ArbUIvRYYs=; 7:lgMHiZa12Gw7oxDmJqHAR9RsXGfYaaUB0/FibxRYKKlq7sioo/lZ8zn6XlkKtkalWi8wGzK086g1RrtLuIWGiRTxK5/eLPEC/mpN0G5b4+DPLr51RXDbfBgQUXb0Ko46SSUvZt0+ly5WrAGoL+5/LumoBIGEymMvQSdFe8okFWpHMmH2nVQmio5y5dNZ50YBWDfZRAi6N8bDuKUe3tEVdfBRxGjA2ceTEhK6qLXJrTg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 882d4d19-fd75-45fa-25d7-08d50d309a02 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-exchange-antispam-report-test: UriScan:(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 045315E1EE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(32952001)(199003)(13464003)(377454003)(97736004)(2950100002)(53936002)(3280700002)(55016002)(110136005)(2906002)(86362001)(14454004)(80792005)(102836003)(3846002)(7696004)(53546010)(99286003)(9686003)(6246003)(3660700001)(316002)(229853002)(7736002)(33656002)(72206003)(6436002)(101416001)(68736007)(105586002)(305945005)(106356001)(54356999)(81166006)(8936002)(93886005)(6116002)(81156014)(77096006)(6506006)(74316002)(76176999)(50986999)(2900100001)(8676002)(25786009)(6306002)(66066001)(189998001)(2501003)(5660300001)(966005)(478600001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2017 03:07:53.5122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6131> : inlines <6112> : streams <1766175> : uri <2512493> Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 03:08:00 -0000 > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Saturday, October 7, 2017 1:18 AM > To: Konda, Tirumaleswar Reddy ; > dots@ietf.org > Subject: RE: [Dots] Coding and Interoperability Challenges >=20 > Hi Tiru >=20 > >> > >> So, should it be displayed (in JSON) as UTC, local timezone or simply > seconds? > >> > >> Mitigation-start: 2017-10-03T10:15:30-05:00 Or > >> Mitigation-start: 2017-10-03T15:15:30Z Or > >> Mitigation-start: 1507040181.567890 >=20 > > Mitigation-start: 1507040181.567890 (represented in JSON number format)= . >=20 > > -Tiru >=20 > If you could add this " Mitigation-start: 1507040181.567890" into the spe= c as > part of Fig 10, this would be great. >=20 > However Tagged CBOR -> JSON is fine, but JSON -> CBOR will not create the > tagged entry in CBOR. Good point, we can follow the approach taken by https://tools.ietf.org/html= /draft-ietf-ace-cbor-web-token-08 for NumericDate to address this problem. -Tiru >=20 > Regards >=20 > Jon From nobody Fri Oct 6 20:11:43 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7591113219C for ; Fri, 6 Oct 2017 20:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 QuCj3loP2Fqm for ; Fri, 6 Oct 2017 20:11:39 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 63DE613219B for ; Fri, 6 Oct 2017 20:11:38 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507345892; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-exchange-antispam-report-test:x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=v qsDbxHYY1kR2uwTZzeErHT97Se/kJw0kgE7Z5BFLL 0=; b=HZGpRHfHvSOaYuZXwHvQyCDoe1tZkZ68LUzHV+Olt43x q/vbUDjUwJBSVeIgCYCUE6jubpKQDBwvbQLgSGyaXOXi6T0xo8 7c6C5XUa3n5naqibg1M6jy09+O63CxD2A5vd79VEMqb0xTvJEi A8MDD3QSLDnPhpkFpU3uTYpk+sU= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 6b45_716c_64848819_702b_4f81_bb32_02e95f368d83; Fri, 06 Oct 2017 22:11:31 -0500 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 23:11:30 -0400 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 23:11:23 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Oct 2017 23:11:22 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 23:11:22 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sat, 7 Oct 2017 03:11:20 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.018; Sat, 7 Oct 2017 03:11:20 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" , "mohamed.boucadair@orange.com" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AdM866F1exiXOD0RS+2TvvngfvHPNAAHYE+AAC3w14AALEpYgAALE5wwAAKjs4AAAJFkQAANym6AAA3Ky0A= Date: Sat, 7 Oct 2017 03:11:20 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A050387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0506A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <098901d33ee2$5c3478b0$149d6a10$@jpshallow.com> In-Reply-To: <098901d33ee2$5c3478b0$149d6a10$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.69.122.17] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:lxB6+aVuOV8bOKtIclZ7LBUPexe7KCeCb9OFWJRvTvMPhY7gV7xngDaZAj7/DSz7S88musRegcqV1ob7hBogs80C4ZaTLUu0KDdaaiwM6+4Bacyn6mAHOYx0YGriCupLxHGgw2Fa/Jbe6pwUka8DHTOe/FxSqAZuue69iaA5g3qF5nSEibi/xYzIvhVVwQijrN7uK1ihpihM3i0VOB7RVEYYx5HRF9p4qDENIYH9XsZqIUPv0XwO31PDLqSK+YQylgYmsNlBk6so6kwpwimvl7c+ZNaAwzS/PPuVNnvgBMDSdHVhvCmW5TATKRboDRBum+iN6SvOFvRhoG8PUBf5kg==; 5:peZtcMBWmOcz9Xxw/4TNE53Ar+RhWGL0ecux+rAZRDYnIITFvyUpzECHwn04oPEEbunW4JD3kTpkupEtmHMEebYmNzsId4PCTwSYtqHam/AW9MQi122h5FA26Q1QeVk4Kih+yzE7/190NexJGvdUjA==; 24:t1ko66azAx0e9FLWDqVoGuI5MOWjX3J/qD5+JAZLvswbA78tOuLTn6MpZiix/ffixQrIh260mQugT8gvIDNs3esyiNYICocuSVoYsuy7qWM=; 7:ScKzV4h5fwkfOs2zuRdxe5vM0RdOSHUxKGaMZ++4hOqxme2467MVyL0ThGlD+9HkKnr3vco7h3lgIjg3b2LW6QrgPUJuoGOeUqQDXyc6B1DjPo/0gG8GwNKc8+9kiyNteLrUUKJgQ6Tnnl8sdQXgc6tgnZtHepVkO4Xv+w8YasBZBauhY9Q5OXf/Zs5SUwdXITOhOeUJJC2K19h7pidWwTvdHv+1vgdPGR2WpURFH5s= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bc62d73c-bfdf-49e7-59c8-08d50d31157e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(211171220733660)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 045315E1EE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(377454003)(32952001)(189002)(199003)(6116002)(9326002)(54896002)(81166006)(93886005)(8936002)(74316002)(6506006)(81156014)(77096006)(7736002)(33656002)(106356001)(54356999)(6436002)(72206003)(68736007)(105586002)(101416001)(189998001)(966005)(478600001)(2501003)(5660300001)(8676002)(25786009)(50986999)(76176999)(2900100001)(19609705001)(66066001)(6306002)(3280700002)(53936002)(2906002)(55016002)(110136005)(97736004)(2950100002)(2201001)(86362001)(9686003)(6246003)(229853002)(316002)(3660700001)(53946003)(80792005)(14454004)(790700001)(53546010)(236005)(99286003)(3846002)(102836003)(606006)(7696004)(85282002)(562404015)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17883722053B5A70EBA55359EA760DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2017 03:11:20.7016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6131> : inlines <6112> : streams <1766174> : uri <2512491> Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 03:11:42 -0000 --_000_DM5PR16MB17883722053B5A70EBA55359EA760DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, I meant heartbeat-interval will be defined as equivalent to MAX_TRANSMIT_WA= IT but not negotiated as heartbeat-interval is derived from the message tra= nsmission parameters. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, October 7, 2017 2:03 AM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org; mohamed.boucadair@orange.com Subject: RE: [Dots] Minimum heartbeat-interval Hi Guys, > Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-i= nterval). If heartbeat-interval is not defined / negotiated - what happens in peace t= ime? What rate should the heartbeats be sent at? If COAP Pings are timing out - yes, the length of time before the timeout i= s reported to the upper layers is dependent on max-retransmit, ack-timeout = and ack-random-factor at which point a COAP ping could get re-transmitted. = But does the peace time COAP Ping transmission rate have to be greater or= equal to the COAP layer reporting the "Ping" CON has failed? In war time, the next COAP Ping should be delayed until after the current C= OAP Ping has expired. Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, T= irumaleswar Reddy Sent: 06 October 2017 15:00 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-int= erval). -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, October 6, 2017 7:12 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval Tiru, We are on the same page for (1). I hope we will hear more voices on this be= fore we add some text to the draft to clarify missing points. Please see inline for (2). Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 6 octobre 2017 15:08 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] Minimum heartbeat-interval Hi Med, Please see inline [TR] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, October 6, 2017 12:40 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval Hi Tiru, all, Please see inline. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 5 octobre 2017 12:54 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Minimum heartbeat-interval http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). [Med] You are right about the configurable aspect, but the question from Jo= n is a good one. I interpret it in another way: - Should we rely solely on the missing-hb-allowed to detect a session pro= blem? [TR] If the DOTS agent does not receive a response to "CoAP ping" but recei= ves other type of messages from the peer DOTS agent then a counter incremen= ted each time there is no response to a "CoAP ping" till the counter value = hits missing-hb-allowed to determine the session is defunct can be reset to= zero. - Should we get rid of missing-hb-allowed, but rely on the retransmission= to declare failure or not? [TR] If DOTS agents only rely on the retransmission mechanism then a "CoAP = ping" message will only be retransmitted 4 times before concluding the sess= ion is disconnected in an interval of 93 seconds. The network under DDoS at= tack is likely to be congested (high packet loss and latency), hence missin= g-hb-allowed is used to send the "CoAP ping" more number of times (3 (ping)= + 3*4 (re-transmissions) =3D 15 times) with sufficient time interval (93*3= =3D 279 seconds) to determine the session is defunct. - What is the advantage of cumulating both missing-hb-allowed and the ret= ransmission procedure to declare a channel out? [TR] Please see above. 2) No, [Med] I agree that a heartbeat does not need to be fired when the first pin= g is still alive. We can clarify this in the draft. [TR] Thanks. if the DOTS agent wants to change the default heartbeat interval then the o= ther message transmission parameters will also have to be modified. [Med] I disagree here that the other parameters need to be changed. I don't= see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree= that we need to tweak heartbeat-interval as a function of MAX_TRANSMIT_WAI= T). As you know, MAX_TRANSMIT_WAIT can be derived from other parameters (AC= K_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR)). This i= s why it does not make sense to provide a configuration for MAX_TRANSMIT_WA= IT if the other parameters are provided. [TR] I did not get the above, the draft is not providing any new configurat= ion for MAX_TRANSMIT_WAIT [Med] I was talking about heartbeat-interval. . If let's say the DOTS agents decide to change the heartbeat interval to 4= 5 seconds then the max-retransmit has to be changed to 3 to arrive at 45 se= cond MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_= TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new heartb= eat interval). [Med] My comment is that if heartbeat-interval was dependent on transmissio= n parameters, then we do not need to configure it explicitly IN ADDITION to= the other transmission parameter. How can the heartbeat interval change without changing the message transmis= sion parameters ? [Med] I do see these two as separate parameters. The heartbeat-interval det= ermines the frequency of sending keeplaive messages. This is an additional = transmission parameter specific to heartbeat if you will. -Tiru 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med --_000_DM5PR16MB17883722053B5A70EBA55359EA760DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

I meant h= eartbeat-interval will be defined as equivalent to MAX_TRANSMIT_WAIT but no= t negotiated as heartbeat-interval is derived from the message transmission= parameters.

&nbs= p;

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Saturday, October 7, 2017 2:03 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org; mohamed.boucadair@orange.com
Subject: RE: [Dots] Minimum heartbeat-interval

 

Hi Guys= ,

&n= bsp;

> Thanks Med, agreed on (2) (= no need to negotiate and configure heartbeat-interval).

&n= bsp;

If hear= tbeat-interval is not defined / negotiated – what happens in peace ti= me?  What rate should the heartbeats be sent at?

&n= bsp;

If COAP= Pings are timing out – yes, the length of time before the timeout is= reported to the upper layers is dependent on max-retransmit, ack-timeout a= nd ack-random-factor at which point a COAP ping could get re-transmitted.   But does the peace time COAP Ping tr= ansmission rate have to be greater or equal to the COAP layer reporting the= “Ping” CON has failed?

&n= bsp;

In war = time, the next COAP Ping should be delayed until after the current COAP Pin= g has expired.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 October 2017 15:00
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Thanks Me= d, agreed on (2) (no need to negotiate and configure heartbeat-interval).

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, October 6, 2017 7:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] Minimum heartbeat-interval

 

Tiru,

 

We are on the same page for (1). I hope we will hear more voices on this before we add some tex= t to the draft to clarify missing points.

 

Please see inline for (2).

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 6 octobre 2017 15:08
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] Minimum heartbeat-interval=

 

Hi Med,

&nbs= p;

Please se= e inline [TR]

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, October 6, 2017 12:40 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] Minimum heartbeat-interval

 

Hi Tiru, all,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com<= span style=3D"font-size:10.0pt;font-family:"Tahoma",sans-serif;ms= o-fareast-language:FR">]
Envoy=E9 : jeudi 5 octobre 2017 12:54
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Minimum heartbeat-interval=

 

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html= /rfc7925 has tested NAT behavior with various routers and lists the tim= eout results. The majority of the devices (62%) have a timeout between 2 an= d 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is = 54 seconds.

 

Responses to the questions below

 

1) The max-retransmit parameter is negotiable and configurable,&nbs= p; DOTS agents can pick suitable values for max-retransmit parameter based = on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).

 

[Med] You are right= about the configurable aspect, but the question from Jon is a good one. I = interpret it in another way:

- &n= bsp; Should we rely solely on the missin= g-hb-allowed to detect a session problem?

&nbs= p;

[TR] If t= he DOTS agent does not receive a response to “CoAP ping” but re= ceives other type of messages from the peer DOTS agent then a counter incre= mented each time there is no response to a “CoAP ping” till the counter value hits missing-hb-allowed to determine th= e session is defunct can be reset to zero.

- &n= bsp; Should we get rid of missing-hb-all= owed, but rely on the retransmission to declare failure or not?<= /span>

&nbs= p;

[TR] If D= OTS agents only rely on the retransmission mechanism then a “CoAP pin= g” message will only be retransmitted 4 times before concluding the s= ession is disconnected in an interval of 93 seconds. The network under DDoS attack is likely to be congested (high packet loss = and latency), hence missing-hb-allowed is used to send the “CoAP ping= ” more number of times (3 (ping) + 3*4 (re-transmissions) =3D 15 = times) with sufficient time interval (93*3 =3D 279 seconds) to determine the session is defunct.

&nbs= p;

- &n= bsp; What is the advantage of cumulating= both missing-hb-allowed and the retransmission procedure to declare a chan= nel out?

&nbs= p;

[TR] Plea= se see above.

 

2) No,

[Med] I agree that = a heartbeat does not need to be fired when the first ping is still alive. W= e can clarify this in the draft.

&nbs= p;

[TR] Than= ks.

 

if the DOTS agent wants to change the default heartbeat interval th= en the other message transmission parameters will also have to be modified.

[Med] I disagree he= re that the other parameters need to be changed. I don’t see heartbea= t-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree that we need to tweak heartbeat-interval as a function of MAX_T= RANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from other par= ameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_F= ACTOR)). This is why it does not make sense to provide a configuration for MAX_TRANSMIT_WAIT if the other parame= ters are provided.

&nbs= p;

[TR] I di= d not get the above, the draft is not providing any new configuration for M= AX_TRANSMIT_WAIT

[Med] I was talking= about heartbeat-interval.

 

. If let&= #8217;s say the DOTS agents decide to change the heartbeat interval to 45 s= econds then the max-retransmit has to be changed to 3 to arrive at 45 secon= d MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be change= d to arrive at the new heartbeat interval).

[Med] My comment is= that if heartbeat-interval was dependent on transmission parameters, then = we do not need to configure it explicitly IN ADDITION to the other transmission parameter.  

 

How can t= he heartbeat interval change without changing the message transmission para= meters ?

[Med] I do see thes= e two as separate parameters. The heartbeat-interval determines the frequen= cy of sending keeplaive messages. This is an additional transmission parameter specific to heartbeat if you will.

&nbs= p;

-Tiru

&nbs= p;

 

3) The client will have to assume the session is disconnected (see = the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The he= artbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 

Med – In the below text, recommended value should be 93 secon= ds instead of 90 seconds (see https://tools= .ietf.org/html/rfc7252#section-4.8.2).

 

-Tiru<= /span>

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

&n= bsp;

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

&n= bsp;

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

&n= bsp;

Oct 04 10:53:51 DEBG sending C= oAP ping:

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to re= transmit queue (2281ms)

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:53:51 ALRT got RST f= or message 29548

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending C= oAP ping:

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to re= transmit queue (2938ms)

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:07 ALRT got RST f= or message 29549

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending C= oAP ping:

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to re= transmit queue (2156ms)

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:23 ALRT got RST f= or message 29550

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending C= oAP ping:

Oct 04 10:54:39 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to re= transmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #1

Oct 04 10:54:42 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #2

Oct 04 10:54:48 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #3

Oct 04 10:55:00 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #4

Oct 04 10:55:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up af= ter 4 attempts

&n= bsp;

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

&n= bsp;

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

&n= bsp;

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

&n= bsp;

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

&n= bsp;

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Scenari= o as Q3

&n= bsp;

Does th= e client re-use the old session that the heartbeats are failing on?

- The s= erver may have sent a session close, but it never got through

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

&n= bsp;

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

&n= bsp;

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow = (supjps-ietf@jpshallow.com= )
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during the interim meeting:= “A: (Jon Shallow): The minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with RFC8085 which= says the following:

 

   An application that needs to employ kee=
p-alive messages to deliver
   useful service over UDP in the presence=
 of middleboxes SHOULD NOT
        &nbs=
p;            &=
nbsp;           &nbs=
p;            ^^^^^^=
^^^^^^^^^^^^^^^^
   transmit them more frequently than once=
 every 15 seconds and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   use longer intervals when possible.&nbs=
p;

 

I suggest to add this NEW text to the signal-channel draft= to clarify the rationale for the recommended values:

 

NEW:

    &= nbsp; Note: heartbeat-interval should be tweaked to also assist DOTS

    &= nbsp; messages for NAT traversal (SIG-010 of

    &= nbsp; [I-D.ietf-dots-requirements]).  According to [RFC8085], keepaliv= e

    &= nbsp; messages must not be sent more frequently than once every 15

    &= nbsp; seconds and should use longer intervals when possible.

    &= nbsp; Furthermore, [RFC4787] recommends NATs to use a state timeout of 2

    &= nbsp; minutes or longer.  From that standpoint, this specification

    &= nbsp; recommends a minimum heartbeat-interval of 15 seconds and a

    &= nbsp; maximum heartbeat-interval of 240 seconds.  The recommended valu= e

    &= nbsp; of 90 seconds is selected to anticipate the expiry of NAT states,

    &= nbsp; while avoiding overloading the network with frequent keepalives<= /o:p>

    &= nbsp; for NAT state maintenance purposes.  Note that this recommended<= o:p>

    &= nbsp; value is close to the one recommended for MAX_TRANSMIT_WAIT, whose

    &= nbsp; value is derived from transmission parameters (Section 4.8.2 of<= /o:p>

      [RFC7252]).

 

Thoughts?

 

Cheers,

Med

--_000_DM5PR16MB17883722053B5A70EBA55359EA760DM5PR16MB1788namp_-- From nobody Fri Oct 6 20:28:20 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46343132076 for ; Fri, 6 Oct 2017 20:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 MntTfbqXEbUt for ; Fri, 6 Oct 2017 20:28:16 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 302C413292F for ; Fri, 6 Oct 2017 20:28:16 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507346888; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=J HIj7bP2RtheMDkk0fyjYx9KcPnywxCSs7iyHjxq05 8=; b=GdRfDNAyYwvTjpBes2EfdXjVUCXeLEBiiLO7ME+xeTzs vYxszhAg1WL7CUbBkYCJlPTQ27mwRDCKxwT2VFBhOxrBxhgTKT biUvr//CX8igJpvV2KF75S7iEZpBUKAGu20EHg3fO61jFfWRbW AE4NNCdl+S6y5S2zieXigDiZWd4= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 2ead_1c08_d79c664d_00fa_481e_b31b_42082ae9a57b; Fri, 06 Oct 2017 22:28:07 -0500 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 21:28:07 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 21:28:06 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Oct 2017 21:28:06 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 21:28:05 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sat, 7 Oct 2017 03:28:04 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.018; Sat, 7 Oct 2017 03:28:04 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEA= Date: Sat, 7 Oct 2017 03:28:04 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> In-Reply-To: <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [161.69.122.17] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:CVDYjUZEqRkNcIYSziQHM3VvpSwe9ReBOOeDnBStZx4EL099XIcEUzocBN0g6ZbMW7ATbrAbcdc9Mxz4k1M3/uzJklVQjaCFcRR1oAwbLUDvr3oW4PdnbkV2VAeEvKcVY4uBgS/zTEDYlB8DT6/dGit5oY1nl3BqfzptY9yBjH2Nx4BULbDok1DlN1vlSIZ0/CHEijzXlS5crIGi9TZcLPp8D3RlFHtcfCeNXa6/0U6CPQFE2zis2uoOxx5PoTsydgeB9+q6333Uw9uhPGQR/D4tSHKngpmnHotPo3aZCy+P9ZzveMrxSz01wd9WwA+A/H1K4dGj1uhpV3EI7AtUlw==; 5:bfnNTRGRw2rlBGvn4WxaBj8ZvOwj0rBXZFKJnleGlYd7j4imqW1lJdpYzrCKgGmhM88Du8cETUmOX8VrR75xmR5wcsiI6PasxNphLklp/gtfsus3pgDeK3ef7SKIHO0gIkUprP2Gf7j+tKFFFhlsHQ==; 24:QjyCMKaXbAxLB+Qn6V2iIglN8/nDOV7tOi4RYFGLsGDfoWzQYwrMcIjbOa09ps313bxoKfWOGawacmwlcHGU7xRB+dVijJWkDTpcYV3lTNo=; 7:O9f57dK+tgsyjQrk1KjEBQ1TnKAzkU1R/AIReC0kgtivACbrwASYCC591DkFrIzHAdhOp/Mzm6svpReBs9+y2hEfKb9GNCLNIrEupUYTL4VZNdzKtADAq7Uyw//Mzd60laiKiovaPoJ2BweTUP8Jje4s3rs5fwbQJ4q03xaQ38f938wuBLYEfJJ6ebAge1a8J9yakoaaXFE9dG3jAmz1H0+UFpEmGFJJNqdYm7nSUH4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 54ef643d-2e3d-4aaf-5cb3-08d50d336bb2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 045315E1EE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(32952001)(189002)(377454003)(199003)(101416001)(50986999)(106356001)(14454004)(6116002)(229853002)(54356999)(9686003)(5660300001)(86362001)(790700001)(6506006)(189998001)(53546010)(68736007)(54896002)(236005)(102836003)(55016002)(2950100002)(76176999)(2900100001)(77096006)(6306002)(7696004)(99286003)(3846002)(6436002)(3280700002)(19609705001)(33656002)(93886005)(2501003)(81166006)(316002)(81156014)(2906002)(25786009)(8676002)(105586002)(80792005)(97736004)(110136005)(7736002)(53936002)(66066001)(3660700001)(6246003)(2201001)(478600001)(8936002)(72206003)(74316002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17888F977A2C3A28C8D3727FEA760DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2017 03:28:04.2731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6131> : inlines <6112> : streams <1766177> : uri <2512501> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 03:28:18 -0000 --_000_DM5PR16MB17888F977A2C3A28C8D3727FEA760DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gY2FzZSBvZiBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksIHdoeSBkb2VzIHRoZSBET1RTIHNl cnZlciBuZWVkIHRvIGtub3cgd2hpY2gg4oCcRE9UUyBjbGllbnTigJ0gaGFzIGNvbnZleWVkIHRo ZSBtaXRpZ2F0aW9uIHJlcXVlc3QgPw0KRm9yIGV4YW1wbGUsIHRoZSBET1RTIGNsaWVudCBjb3Vs ZCBiZSBhIEREb1MgZGV0ZWN0b3Igb3IgYW4gQXBwbGljYXRpb24gc2VydmVyLCBhbmQgdGhlIGNs aWVudC1zaWRlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHJlc29sdmUgdGhlIGNvbmZsaWN0aW5nIG1p dGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBjbGllbnRzLCBhZ2dyZWdhdGUgdGhlIG1p dGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBjbGllbnQgYW5kIHNlbmQgdGhlIHVwZGF0 ZWQgbWl0aWdhdGlvbiByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4NCg0KLVRpcnUNCg0KRnJv bTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KU2VudDog RnJpZGF5LCBPY3RvYmVyIDYsIDIwMTcgNzo0MiBQTQ0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tOyBkb3RzQGlldGYub3JnOyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNA YXJib3IubmV0Pg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMN Cg0KSGkgVGlydSwNCg0KVW5sZXNzIEkgYW0gbWlzc2luZyBzb21ldGhpbmcsIGhvdyBkb2VzIHRo ZSBDbGllbnQgc2lkZSBvZiBET1RTIEdXIGNvbnZleSB0byB0aGUgdXBzdHJlYW0gc2VydmVyIGEg dW5pcXVlIOKAnGNsaWVudC1pZOKAnSB3aGljaCBpcyBkaWZmZXJlbnQgdG8gdGhlIGltcGxpZWQg Y2xpZW50IGlkIGFzIGRlcml2ZWQgZnJvbSB0aGUgUEtJIGNlcnRpZmljYXRlIHRoYXQgdGhlIERP VFMgR1figJlDbGllbnQgdXNlcy9wcmVzZW50cyB3aGVuIGNvbW11bmljYXRpbmcgdG8gdGhlIHNl cnZlcj8NClRvIG1lLCB0aGVyZSBuZWVkcyB0byBiZSBhbiBvcHRpb24gc3VjaCBhcyDigJxvcmln aW5hbC1jbGllbnQtaWTigJ0gb3Ig4oCcY2xpZW50LWlk4oCdICh3aGljaCBpcyBjb25mdXNpbmcg d2hlbiBhbHNvIHJlZmVycmluZyB0byB0aGUgY2xpZW50IGlkZW50aXR5IGFzIGRlcml2ZWQgZnJv bSB0aGUgKERPVFMgR1cpIENsaWVudOKAmXMgUEtJIGNlcnRpZmljYXRlKSBhcyBhIHBhcnQgb2Yg dGhlIHByb3RvY29sLg0KDQpJIGFncmVlIHRoYXQgdGhlIERPVFMgR1cgY2FuIGdlbmVyYXRlIGl0 cyBvd24gdW5pcXVlIGNsaWVudC1pZCB0byBzdG9wIG11bHRpcGxlIGVudHJpZXMgYmVpbmcgbmVl ZGVkLg0KDQpJIGFncmVlIHRoYXQgaXMgbm90IGEgZ29vZCB0aGluZyB0byDigJxsZWFr4oCdIG91 dCBpbnRlcm5hbCBpbmZvcm1hdGlvbiB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR1csIHNv IG15IFJFUVVJUkVEIGRvZXMgbm90IG1ha2Ugc2Vuc2UuDQoNClJlZ2FyZHMNCg0KSm9uDQpQUyDi gJMgSSBhbSBoYXZpbmcgdG8gZGVhbCB3aXRoIG90aGVyIHN0dWZmIGF0IHByZXNlbnQg4oCTIEkg d2lsbCBnZXQgYmFjayBsYXRlciBvbiB0aGUgb3RoZXIgaXNzdWVzIHVuZGVyIGRpc2N1c3Npb24N Cg0KRnJvbTogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSBbbWFpbHRvOiBUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBtY2FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2Fm ZWUuY29tPl0NClNlbnQ6IDA2IE9jdG9iZXIgMjAxNyAxNDo1OA0KVG86IG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBKb24g U2hhbGxvdzsgJ0RvYmJpbnMsIFJvbGFuZCc7IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpJ IGRvbuKAmXQgc2VlIGEgbmVlZCBmb3IgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZl eSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiDigJxE T1RTIGNsaWVudCBpZGVudGl0eeKAnSBsb29rcyByZXF1aXJlZCBvbmx5IGZvciB0aGUgc2VydmVy LXNpZGUgRE9UUyBnYXRld2F5cy4gSW4gY2FzZSBvZiBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXks IGl0IGNhbiBjb252ZXkgdGhlIGNsaWVudC1pZCBnZW5lcmF0ZWQgZnJvbSB0aGUg4oCcRE9UUyBj bGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiBUaGUgRE9UUyBnYXRld2F5IGNh biBnZW5lcmF0ZSBhIHVuaXF1ZSBjbGllbnQtaWQgYW5kIGRvZXMgbm90IGhhdmUgdG8gc2VuZCBh biBhcnJheSBvZiBjbGllbnQtaWRzIHRvIHRoZSBET1RTIHNlcnZlciB0byByZXNvbHZlIGNsYXNo ZXMuDQoNCi1UaXJ1DQo= --_000_DM5PR16MB17888F977A2C3A28C8D3727FEA760DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQg MiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBVSSIsc2Fucy1zZXJpZjt9 DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxl cyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUg ZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnAuVGV4dGVk ZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxsZXMNCgl7bXNvLXN0eWxl LW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxl cyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9 DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5JbiBjYXNlIG9mIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgd2h5IGRvZXMgdGhlIERPVFMg c2VydmVyIG5lZWQgdG8ga25vdyB3aGljaCDigJxET1RTIGNsaWVudOKAnSBoYXMgY29udmV5ZWQg dGhlIG1pdGlnYXRpb24gcmVxdWVzdCA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgZXhhbXBsZSwgdGhlIERPVFMgY2xpZW50 IGNvdWxkIGJlIGEgRERvUyBkZXRlY3RvciBvciBhbiBBcHBsaWNhdGlvbiBzZXJ2ZXIsIGFuZCB0 aGUgY2xpZW50LXNpZGUgZ2F0ZXdheSB3aWxsIGhhdmUgdG8gcmVzb2x2ZSB0aGUgY29uZmxpY3Rp bmcgbWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIHRoZQ0KIERPVFMgY2xpZW50cywgYWdncmVnYXRl IHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50IGFuZCBzZW5kIHRo ZSB1cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29t cG9zZSI+PC9zcGFuPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1 cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3Rv YmVyIDYsIDIwMTcgNzo0MiBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBS ZWRkeSAmbHQ7VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSZndDs7IG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb207IGRvdHNAaWV0Zi5vcmc7IFJvbGFuZCBEb2JiaW5zICZsdDty ZG9iYmluc0BhcmJvci5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9U UyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I aSBUaXJ1LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5Vbmxlc3MgSSBhbSBtaXNzaW5nIHNvbWV0aGluZywgaG93IGRv ZXMgdGhlIENsaWVudCBzaWRlIG9mIERPVFMgR1cgY29udmV5IHRvIHRoZSB1cHN0cmVhbSBzZXJ2 ZXIgYSB1bmlxdWUg4oCcY2xpZW50LWlk4oCdIHdoaWNoIGlzIGRpZmZlcmVudCB0byB0aGUgaW1w bGllZA0KIGNsaWVudCBpZCBhcyBkZXJpdmVkIGZyb20gdGhlIFBLSSBjZXJ0aWZpY2F0ZSB0aGF0 IHRoZSBET1RTIEdX4oCZQ2xpZW50IHVzZXMvcHJlc2VudHMgd2hlbiBjb21tdW5pY2F0aW5nIHRv IHRoZSBzZXJ2ZXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UbyBtZSwgdGhlcmUg bmVlZHMgdG8gYmUgYW4gb3B0aW9uIHN1Y2ggYXMg4oCcb3JpZ2luYWwtY2xpZW50LWlk4oCdIG9y IOKAnGNsaWVudC1pZOKAnSAod2hpY2ggaXMgY29uZnVzaW5nIHdoZW4gYWxzbyByZWZlcnJpbmcg dG8gdGhlIGNsaWVudCBpZGVudGl0eSBhcw0KIGRlcml2ZWQgZnJvbSB0aGUgKERPVFMgR1cpIENs aWVudOKAmXMgUEtJIGNlcnRpZmljYXRlKSBhcyBhIHBhcnQgb2YgdGhlIHByb3RvY29sLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIGFncmVlIHRoYXQgdGhlIERPVFMgR1cgY2FuIGdlbmVyYXRlIGl0cyBvd24gdW5p cXVlIGNsaWVudC1pZCB0byBzdG9wIG11bHRpcGxlIGVudHJpZXMgYmVpbmcgbmVlZGVkLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIGFncmVlIHRoYXQgaXMgbm90IGEgZ29vZCB0aGluZyB0byDigJxsZWFr4oCdIG91 dCBpbnRlcm5hbCBpbmZvcm1hdGlvbiB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR1csIHNv IG15IFJFUVVJUkVEIGRvZXMgbm90IG1ha2Ugc2Vuc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Sm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QUyDigJMgSSBhbSBo YXZpbmcgdG8gZGVhbCB3aXRoIG90aGVyIHN0dWZmIGF0IHByZXNlbnQg4oCTIEkgd2lsbCBnZXQg YmFjayBsYXRlciBvbiB0aGUgb3RoZXIgaXNzdWVzIHVuZGVyIGRpc2N1c3Npb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeSBbbWFpbHRvOg0KPGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5 X0tvbmRhQG1jYWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQG1jYWZlZS5jb208L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDA2IE9jdG9iZXIgMjAxNyAxNDo1ODxicj4NCjxiPlRvOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyBKb24gU2hhbGxvdzsgJ0RvYmJpbnMsIFJvbGFuZCc7 DQo8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBkb27igJl0IHNlZSBhIG5lZWQgZm9yIGNsaWVu dC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR5 4oCdIHRvIHRoZSBET1RTIHNlcnZlci4g4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gbG9va3Mg cmVxdWlyZWQgb25seSBmb3IgdGhlIHNlcnZlci1zaWRlIERPVFMNCiBnYXRld2F5cy4gSW4gY2Fz ZSBvZiBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IGNhbiBjb252ZXkgdGhlIGNsaWVudC1p ZCBnZW5lcmF0ZWQgZnJvbSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERP VFMgc2VydmVyLiBUaGUgRE9UUyBnYXRld2F5IGNhbiBnZW5lcmF0ZSBhIHVuaXF1ZSBjbGllbnQt aWQgYW5kIGRvZXMgbm90IGhhdmUgdG8gc2VuZCBhbiBhcnJheSBvZiBjbGllbnQtaWRzIHRvIHRo ZSBET1RTIHNlcnZlciB0bw0KIHJlc29sdmUgY2xhc2hlcy4gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi1UaXJ1 PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB17888F977A2C3A28C8D3727FEA760DM5PR16MB1788namp_-- From nobody Sat Oct 7 00:14:34 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08755132D8A for ; Sat, 7 Oct 2017 00:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 1u643ApLzT3j for ; Sat, 7 Oct 2017 00:14:31 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 2E243132153 for ; Sat, 7 Oct 2017 00:14:31 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507360470; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=k A4Iy9ZmkjwFrYBh6BRSMTer7h2chsTNHkGiUS21S7 s=; b=qX950A9SMPFU9Le4aXArh+GXWQMBs5JO1+5+abqvyRHC PUL4aM2wu9WZ0Qz+PSCDJQ+DrpD5D+BXPY00QzTxI4Nfayl0xE 0Re/ds3MenDl0PysA2V8N0+gbsmguCnPQg8shh498vLfrS9/0T 9nBTmnYZ/8HteORLcKMgeyvDV8Y= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 1a70_669e_89dbedf6_0af7_4340_91bd_bed1d3b458ec; Sat, 07 Oct 2017 02:14:29 -0500 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 7 Oct 2017 01:14:26 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 21:33:01 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Oct 2017 21:33:01 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Oct 2017 21:33:01 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sat, 7 Oct 2017 03:33:00 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.018; Sat, 7 Oct 2017 03:33:00 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "'Dobbins, Roland'" , "dots@ietf.org" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAAFOlIkA= Date: Sat, 7 Oct 2017 03:33:00 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> In-Reply-To: <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [161.69.122.17] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:n5bYPbrNRKkOZ0xXgvRCUgdsypid+kjOidatjxBYuTmgiviW567aXeTcXkFiZhd1P6Qs9BHtnlwVD1ZCUW0D1eKWtG/snHaUuFg6FT5jMP5npXcgQ0UK/WiO3mPTquek8M37TTlkAcgVTktuCIbUhx4liy32BnAk95NJ9rLOqJJ8PRcfKzIR6+dYrOeRz23nspHPRarKMCr+LyDLwsVWFNup5se1jiMMBfn1ioiFaU5o49BB+H0jbQm28x0vaKpuSzB3Cj7Rm0eWG/vSeIQ7Y1QrWcpYTeq76nnRLNxgppiTwkZ/Ye1Wmyb/6VUIWhf1HGMNVg/LNFF4kwRBGNaMnQ==; 5:E0q6hudPIn50Caxj7T9Qn3JXsq3B0UweQ2F0vqHO7zr/MqZk5zzcLVpYVBxAw9bnsQuGCgjj5iEf4iMVhmJ/5ETMDThyB2drgMizsd1Xi5rJJg6JVxE8QHJA7yO0ck942rTWQIcJfs309xCgpcxEQA==; 24:oyMBzB2R3jn5GaOHckAd6BKU9cXuVktnZ5jcoegwjp4x6h5fkz1UmOANdRkJPjnxeSWTwmpNj3yIudtWkCL7F4sIg1xQPr4fsUU78jRI/+s=; 7:rzJxAI0YfqOsTAnkVHYHOGnLTA1mW7/R8GEJQSE+YNQGJMFP6A1nVN7do5MHq6+n3ZPVwmZo0TXn+F4avyCrPWLR0AamqzqEQ+t0Hitu+JkG5lbJGUNdawdym6nqpEp3Yx59JcX52/U2MDi18QvXLtLM5dt4/x7tN8rgGETJhsIWJ+lJTs79pVWzZYkD1O9xXlWazSPkoR61ytKaC4a3tYMCvDpO+WXsu2pkHMCvV6g= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 41814da7-1d43-4e7a-660b-08d50d341c1e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 045315E1EE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(32952001)(80792005)(97736004)(110136005)(105586002)(5890100001)(7736002)(53936002)(93886005)(33656002)(2501003)(19609705001)(3280700002)(2906002)(25786009)(81156014)(8676002)(81166006)(316002)(6246003)(74316002)(72206003)(478600001)(8936002)(66066001)(3660700001)(9686003)(5660300001)(790700001)(189998001)(6506006)(86362001)(101416001)(50986999)(54356999)(6116002)(229853002)(106356001)(14454004)(99286003)(7696004)(6306002)(6436002)(3846002)(102836003)(77096006)(54896002)(68736007)(2950100002)(76176999)(55016002)(2900100001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178841EF5116177BDB2C0BC6EA760DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2017 03:33:00.2757 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6131> : inlines <6112> : streams <1766200> : uri <2512582> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 07:14:33 -0000 --_000_DM5PR16MB178841EF5116177BDB2C0BC6EA760DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W0FuZCBzaG91bGQgbm90IHdlIGJlIHBvc3RpbmcgdG8gL3Jlc3Rjb25mL2RhdGEvaWV0Zi1kb3Rz LWFjY2Vzcy1jb250cm9sLWxpc3QgYW55d2F5P10NCg0KW1RSXSBZZXMsIHdpbGwgdXBkYXRlIGRy YWZ0Lg0KDQpUaGUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0OmFjY2Vzcy1saXN0cyBpcyBtb3Jl IGNvbXBsaWNhdGVkLiAgV2l0aCB0aGUgaW50cm9kdWN0aW9uIG9mIOKAmGNvbnRhaW5lciBpbnRl cmZhY2Vz4oCZIGluIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xNCB0aGUgdGV4dCBpbiBn ZW5lcmFsIGluIGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwgbmVlZHMgdXBkYXRpbmcuICBU aGlzIGNoYW5nZSBpbiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTQgZ2l2ZXMgdXMgdGhl IGFiaWxpdHkgdG8gYXR0YWNoIGEgc3BlY2lmaWMgc2V0IG9mIHNvcnRlZCBBQ0xzIHRvIGFuIGlu dGVyZmFjZSwgYnV0IHN0aWxsIGRvZXMgbm90IGVhc2lseSBhc3NvY2lhdGUgYSBzZXQgb2YgQUNM IGRlZmluaXRpb25zIHdpdGggYSBwYXJ0aWN1bGFyIGNsaWVudC4NCg0KW1RSXSBQbGVhc2UgcHJv dmlkZSBtb3JlIGRldGFpbHMgb24gdGhlIHVwZGF0ZXMgcmVxdWlyZWQgdG8gdGhlIERPVFMgZGF0 YSBjaGFubmVsIGRyYWZ0Lg0KDQpDaGVlcnMsDQotVGlydQ0K --_000_DM5PR16MB178841EF5116177BDB2C0BC6EA760DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltBbmQgc2hv dWxkIG5vdCB3ZSBiZSBwb3N0aW5nIHRvIC9yZXN0Y29uZi9kYXRhL2lldGYtZG90cy1hY2Nlc3Mt Y29udHJvbC1saXN0IGFueXdheT9dPG86cD48L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9z ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5bVFJdIFllcywgd2lsbCB1cGRhdGUgZHJhZnQuPG86cD48L286 cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgaWV0 Zi1hY2Nlc3MtY29udHJvbC1saXN0OmFjY2Vzcy1saXN0cyBpcyBtb3JlIGNvbXBsaWNhdGVkLiZu YnNwOyBXaXRoIHRoZSBpbnRyb2R1Y3Rpb24gb2Yg4oCYY29udGFpbmVyIGludGVyZmFjZXPigJkg aW4gZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTE0DQogdGhlIHRleHQgaW4gZ2VuZXJhbCBp biBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsIG5lZWRzIHVwZGF0aW5nLiZuYnNwOyBUaGlz IGNoYW5nZSBpbiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTQgZ2l2ZXMgdXMgdGhlIGFi aWxpdHkgdG8gYXR0YWNoIGEgc3BlY2lmaWMgc2V0IG9mIHNvcnRlZCBBQ0xzIHRvIGFuIGludGVy ZmFjZSwgYnV0IHN0aWxsIGRvZXMgbm90IGVhc2lseSBhc3NvY2lhdGUgYSBzZXQgb2YgQUNMIGRl ZmluaXRpb25zIHdpdGgNCiBhIHBhcnRpY3VsYXIgY2xpZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1RSXSBQbGVhc2UgcHJvdmlk ZSBtb3JlIGRldGFpbHMgb24gdGhlIHVwZGF0ZXMgcmVxdWlyZWQgdG8gdGhlIERPVFMgZGF0YSBj aGFubmVsIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9z ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4tVGlydTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB178841EF5116177BDB2C0BC6EA760DM5PR16MB1788namp_-- From nobody Sat Oct 7 01:37:14 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E6C1344C6 for ; Sat, 7 Oct 2017 01:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfa3qvh_0Wfm for ; Sat, 7 Oct 2017 01:37:10 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 AFDE01344C9 for ; Sat, 7 Oct 2017 01:37:08 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e0kbZ-0000lA-MA; Sat, 07 Oct 2017 09:37:05 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , , "Roland Dobbins" References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> In-Reply-To: Date: Sat, 7 Oct 2017 09:37:06 +0100 Message-ID: <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09EE_01D33F4F.D6FDA630" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIAJQ6kjUASRe9X+it0caAA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 08:37:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_09EE_01D33F4F.D6FDA630 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru ------=_NextPart_000_09EE_01D33F4F.D6FDA630 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

This discussion goes beyond just the mitigation request.=C2=A0 We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client.=C2=A0 =

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)      = The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)      = The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)      = The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely =C2=A0associated with Client = Identity derived from the DOTS GW Client = certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).=C2=A0 This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.=C2=A0 The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.=C2=A0 Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 07 October 2017 04:28
To: Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 =

-Tiru<= /o:p>

 =

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, October 6, 2017 7:42 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= Konda, = Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 06 October 2017 14:58
To: = mohamed.boucadair@orange.com= ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: = [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 =

-Tiru

<= /html> ------=_NextPart_000_09EE_01D33F4F.D6FDA630-- From nobody Sat Oct 7 01:48:52 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF82E134582 for ; Sat, 7 Oct 2017 01:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfFMYalrt3up for ; Sat, 7 Oct 2017 01:48:48 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 497F413457F for ; Sat, 7 Oct 2017 01:48:48 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e0kms-0000lc-OY; Sat, 07 Oct 2017 09:48:46 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> <00a101d32d46$b2f30cf0$18d926d0$@jpshallow.com> <037c01d33a2c$ed764700$c862d500$@jpshallow.com> <040401d33ac9$85542c80$8ffc8580$@jpshallow.com> <060201d33c52$ca5ca390$5f15eab0$@jpshallow.com> <097101d33edc$0770b330$16521990$@jpshallow.com> In-Reply-To: Date: Sat, 7 Oct 2017 09:48:47 +0100 Message-ID: <0a0301d33f49$171486a0$453d93e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJWDLbdGWgIliMeta88DlSb7Xyh6wERxjbqAVIVJZ8CskQHRgGAczJ7AlDJcXkCdZkf6AHJEO5BAduRrnICidnXI6FGG7/w Content-Language: en-gb Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 08:48:50 -0000 Hi Tiru, https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08 NumericDate The "NumericDate" term has the same meaning, syntax, and processing rules as the "NumericDate" term defined in Section 2 of JWT [RFC7519], except that the CBOR numeric date representation (from Section 2.4.1 of [RFC7049]) is used. The encoding is modified so that the leading tag 1 (epoch-based date/time) MUST be omitted. Omitting the leading tag 1 then means that we actually are defining it as a float8 in the CBOR stream. Any reason as to why we cannot just define it as a float8 and state in the definition that is the number of seconds since 1 Jan 1970 UTC? Or, we state that the leading tag 1 is omitted in the CBOR representation. Regards Jon -----Original Message----- From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com] Sent: 07 October 2017 04:08 To: Jon Shallow; dots@ietf.org Subject: RE: [Dots] Coding and Interoperability Challenges > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Saturday, October 7, 2017 1:18 AM > To: Konda, Tirumaleswar Reddy ; > dots@ietf.org > Subject: RE: [Dots] Coding and Interoperability Challenges > > Hi Tiru > > >> > >> So, should it be displayed (in JSON) as UTC, local timezone or > >> simply > seconds? > >> > >> Mitigation-start: 2017-10-03T10:15:30-05:00 Or > >> Mitigation-start: 2017-10-03T15:15:30Z Or > >> Mitigation-start: 1507040181.567890 > > > Mitigation-start: 1507040181.567890 (represented in JSON number format). > > > -Tiru > > If you could add this " Mitigation-start: 1507040181.567890" into the > spec as part of Fig 10, this would be great. > > However Tagged CBOR -> JSON is fine, but JSON -> CBOR will not create > the tagged entry in CBOR. Good point, we can follow the approach taken by https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08 for NumericDate to address this problem. -Tiru > > Regards > > Jon From nobody Sat Oct 7 02:35:13 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6471346A6 for ; Sat, 7 Oct 2017 02:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkSlyf2EaTnU for ; Sat, 7 Oct 2017 02:35:06 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 3E5F51346CA for ; Sat, 7 Oct 2017 02:35:06 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e0lVg-0000n2-9p; Sat, 07 Oct 2017 10:35:04 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A050387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0506A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <098901d33ee2$5c3478b0$149d6a10$@jpshallow.com> In-Reply-To: Date: Sat, 7 Oct 2017 10:35:05 +0100 Message-ID: <0a0801d33f4f$8e9df840$abd9e8c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A09_01D33F57.F0671B30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFSg1IOmvyw/QR4DyHE01ic1cgMDAGpyfFOAh5uDMMCAHhKFQHQoSRQAj9UiokCbRRdiQJr8V49AerdsIOjVKUxYA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 09:35:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0A09_01D33F57.F0671B30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 I confess to being troubled when considering tuning the various max-retransmit, ack-timeout and ack-random-factor values to get = heartbeats behaving as required, as this will also affect anything else using CON = for the requests. =20 With ack-timeout =3D 2, ack-random-factor =3D 1.5 and max-retransmit =3D = 4 (the defaults) and loss of response Heartbeat Ping 3 seconds Ping retry #1 6 seconds Ping retry #2 12 seconds Ping retry #3 24 seconds Ping retry #4 48 seconds Heartbeat Ping Timeout (after 93 seconds) reported to upper layers =20 In terms of NAT (or even firewall session with no NAT) keep-alive, we = are doing this with a value of 3 seconds up to 48 seconds. I am making the assumption that the next Heartbeat Ping request (under response loss conditions) almost immediately follows the Heartbeat Ping Timeout, the cycles of which give up after missing-hb-allowed is = exceeded and the session is declared as dead. =20 When there is no loss of response =20 Heartbeat Ping Small number of milli seconds Ping Response (RST) MAX_TRANSMIT_WAIT (93 seconds) Heartbeat Ping Small number of milli seconds Ping Response (RST) =85 =20 I propose that instead of MAX_TRANSMIT_WAIT (93 seconds), we should use = the derived 48 second gap (between Ping Retry #4 and Heartbeat Ping Timeout) when there is no loss of response for repeating Ping. Thoughts? =20 The reason for this is that you state below =93the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds.=94 =20 A potential workaround to this discussion is that the spec states =93To = make sure that Heartbeats work correctly, any firewall rule (whether NAT=92d = or not) on a firewall sitting between the DOTS client and DOTS Server that enables the DOTS signal channel to traverse the device MUST have an idle session timeout value greater than the derived MAX_TRANSMIT_WAIT=94=20 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 07 October 2017 04:11 To: Jon Shallow; dots@ietf.org; mohamed.boucadair@orange.com Subject: Re: [Dots] Minimum heartbeat-interval =20 Hi Jon, =20 I meant heartbeat-interval will be defined as equivalent to MAX_TRANSMIT_WAIT but not negotiated as heartbeat-interval is derived = from the message transmission parameters.=20 =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:03 AM To: Konda, Tirumaleswar Reddy ; dots@ietf.org; mohamed.boucadair@orange.com Subject: RE: [Dots] Minimum heartbeat-interval =20 Hi Guys, =20 > Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-interval). =20 If heartbeat-interval is not defined / negotiated =96 what happens in = peace time? What rate should the heartbeats be sent at? =20 If COAP Pings are timing out =96 yes, the length of time before the = timeout is reported to the upper layers is dependent on max-retransmit, ack-timeout = and ack-random-factor at which point a COAP ping could get re-transmitted. = But does the peace time COAP Ping transmission rate have to be greater or = equal to the COAP layer reporting the =93Ping=94 CON has failed? =20 In war time, the next COAP Ping should be delayed until after the = current COAP Ping has expired. =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy Sent: 06 October 2017 15:00 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval =20 Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-interval). =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, October 6, 2017 7:12 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval =20 Tiru, =20 We are on the same page for (1). I hope we will hear more voices on this before we add some text to the draft to clarify missing points.=20 =20 Please see inline for (2). =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 6 octobre 2017 15:08 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] Minimum heartbeat-interval =20 Hi Med, =20 Please see inline [TR] =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, October 6, 2017 12:40 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval =20 Hi Tiru, all,=20 =20 Please see inline.=20 =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy [ = mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : jeudi 5 octobre 2017 12:54 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Minimum heartbeat-interval =20 http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds.=20 =20 Responses to the questions below=20 =20 1) The max-retransmit parameter is negotiable and configurable, DOTS = agents can pick suitable values for max-retransmit parameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).=20 =20 [Med] You are right about the configurable aspect, but the question from = Jon is a good one. I interpret it in another way:=20 - Should we rely solely on the missing-hb-allowed to detect a session problem? =20 [TR] If the DOTS agent does not receive a response to =93CoAP ping=94 = but receives other type of messages from the peer DOTS agent then a counter incremented each time there is no response to a =93CoAP ping=94 till the = counter value hits missing-hb-allowed to determine the session is defunct can be reset to zero. - Should we get rid of missing-hb-allowed, but rely on the = retransmission to declare failure or not? =20 [TR] If DOTS agents only rely on the retransmission mechanism then a = =93CoAP ping=94 message will only be retransmitted 4 times before concluding the session is disconnected in an interval of 93 seconds. The network under = DDoS attack is likely to be congested (high packet loss and latency), hence missing-hb-allowed is used to send the =93CoAP ping=94 more number of = times (3 (ping) + 3*4 (re-transmissions) =3D 15 times) with sufficient time = interval (93*3 =3D 279 seconds) to determine the session is defunct.=20 =20 - What is the advantage of cumulating both missing-hb-allowed and the retransmission procedure to declare a channel out? =20 [TR] Please see above. =20 2) No, [Med] I agree that a heartbeat does not need to be fired when the first = ping is still alive. We can clarify this in the draft.=20 =20 [TR] Thanks.=20 =20 if the DOTS agent wants to change the default heartbeat interval then = the other message transmission parameters will also have to be modified.=20 [Med] I disagree here that the other parameters need to be changed. I = don=92t see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I = agree that we need to tweak heartbeat-interval as a function of MAX_TRANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from = other parameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR)). This is why it does not make sense to provide a configuration for MAX_TRANSMIT_WAIT if the other parameters are = provided.=20 =20 [TR] I did not get the above, the draft is not providing any new configuration for MAX_TRANSMIT_WAIT [Med] I was talking about heartbeat-interval. =20 . If let=92s say the DOTS agents decide to change the heartbeat interval = to 45 seconds then the max-retransmit has to be changed to 3 to arrive at 45 second MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new heartbeat interval). [Med] My comment is that if heartbeat-interval was dependent on = transmission parameters, then we do not need to configure it explicitly IN ADDITION = to the other transmission parameter. =20 =20 How can the heartbeat interval change without changing the message transmission parameters ? [Med] I do see these two as separate parameters. The heartbeat-interval determines the frequency of sending keeplaive messages. This is an additional transmission parameter specific to heartbeat if you will. =20 -Tiru =20 =20 3) The client will have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1= ) and initiate (D)TLS session resumption=20 4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The = heartbeat expires only after 273 seconds (3 =93CoAP ping=94 confirmable messages, = each=20 =93CoAP ping=94 re-transmitted 4 times).=20 =20 Med =96 In the below text, recommended value should be 93 seconds = instead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2).=20 =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval =20 Hi Mohamed, =20 In principal I agree with your suggested updates =96 the minimum of 10s = was an off the cuff response, to handle the =93broken=94 NAT timing = implementations out there. =20 =20 The Heartbeat mechanism does raise a few questions in my mind which do = need to be thought through. On a DOTS server, using a heartbeat interval of = 15 secs, with the client going away circa 10:54:30, I get =20 Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS: sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: give up after 4 attempts =20 Here we see the 91 seconds (dependant on the max-retransmit value being = 4) 10:56:09 =96 10:54:39. There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 = before retry transmission #4). =20 Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that = we do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to = be in peace time) and heartbeats, not mitigation requests =20 Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds =96 say 60 seconds and = the first heartbeat ping is still active, should a second heartbeat be fired off? - I think not, but the text then needs to get updated to state the = interval is used whenever there is not a pending heartbeat response outstanding. =20 Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Heartbeat checks are being initiated by the client. The client gets a heartbeat timeout on the session. The client subsequently needs to send = a PUT mitigate request. =20 Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. =20 Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Scenario as Q3 =20 Does the client re-use the old session that the heartbeats are failing = on? - The server may have sent a session close, but it never got through =20 Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 When the heartbeats are initiated by the server, and the heartbeat times out, the session is =93bad=94, but the current mitigation request = continues until it expires. The client may have kicked off his heartbeats at a different time, and = there likely will be a sending frequency drift over time, so the client may = think the session is still active, the server not, and the client decides it = is time to send a non-confirmable PUT to refresh the mitigation as it is = about to expire or possibly another PUT for a different IP that has just = started to get hammered =96 hence heartbeat failures. =20 Alternatively the client decides that the reason for =93bad=94 session = (from the client=92s perspective) is an attack stopping traffic getting through = and needs to do a PUT on the existing session. =20 So server receives a PUT (refresh or for a new IP) on a session that has heartbeat expired. The session contained all the negotiated PKI session keys etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in = peace time. - I believe the session on the server needs to be kept hanging around = for some time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may = answer how to keep =93bad=94 session hanging around] =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com) Subject: [Dots] Minimum heartbeat-interval =20 Dear all,=20 =20 Jon made the following comment during the interim meeting: =93A: (Jon Shallow): The minimum for the heartbeat should be 10s=94 =20 Actually, the use of 10s is not aligned with RFC8085 which says the following:=20 =20 An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. =20 =20 I suggest to add this NEW text to the signal-channel draft to clarify = the rationale for the recommended values:=20 =20 NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). =20 Thoughts?=20 =20 Cheers, Med ------=_NextPart_000_0A09_01D33F57.F0671B30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I confess to being = troubled when considering tuning the various max-retransmit, ack-timeout and = ack-random-factor values to get heartbeats behaving as required, as this = will also affect anything else using CON for the = requests.

 

With ack-timeout =3D 2, = ack-random-factor =3D 1.5 and max-retransmit =3D 4 (the defaults) and = loss of response

Heartbeat Ping

3 = seconds

Ping retry #1

6 = seconds

Ping retry #2

12 = seconds

Ping retry #3

24 = seconds

Ping retry #4

48 = seconds

Heartbeat Ping Timeout (after 93 seconds) = reported to upper layers

 

In terms of NAT (or even = firewall session with no NAT) keep-alive, we are doing this with a value = of 3 seconds up to 48 seconds.

I am making the = assumption that the next Heartbeat Ping request (under response loss = conditions) almost immediately follows the Heartbeat Ping Timeout, the = cycles of which give up after missing-hb-allowed is exceeded and the = session is declared as dead.

 

When there is no loss of = response

 

Heartbeat = Ping

Small number of milli = seconds

Ping Response (RST)

MAX_TRANSMIT_WAIT (93 = seconds)

Heartbeat Ping

Small number of milli = seconds

Ping Response (RST)

…

 

I propose that instead = of MAX_TRANSMIT_WAIT (93 seconds), we = should use the derived 48 second gap (between Ping Retry #4 and = Heartbeat Ping Timeout) when there is no loss of response for repeating = Ping.=A0 Thoughts?

 

The reason for this is that you = state below “the minimum = timeout value observed when packets are exchanged b/w peers in both = directions is 54 seconds.”

 

A potential = workaround to this discussion is that the spec states “To make = sure that Heartbeats work correctly, any firewall rule (whether = NAT’d or not) on a firewall sitting between the DOTS client and = DOTS Server that enables the DOTS signal channel to traverse the device = MUST have an idle session timeout value greater than the derived = MAX_TRANSMIT_WAIT” =

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:11
To: Jon Shallow; dots@ietf.org; = mohamed.boucadair@orange.com
Subject: Re: [Dots] Minimum = heartbeat-interval

 

Hi = Jon,

 

I meant heartbeat-interval will be = defined as equivalent to MAX_TRANSMIT_WAIT but not negotiated as = heartbeat-interval is derived from the message transmission parameters. =

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, October 7, 2017 2:03 AM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org; mohamed.boucadair@orange.com=
Subject: RE: [Dots] Minimum = heartbeat-interval

 

Hi = Guys,

 

> Thanks Med, agreed on = (2) (no need to negotiate and configure = heartbeat-interval).

 

If heartbeat-interval is = not defined / negotiated – what happens in peace time?  What = rate should the heartbeats be sent at?

 

If COAP Pings are timing = out – yes, the length of time before the timeout is reported to = the upper layers is dependent on max-retransmit, ack-timeout and = ack-random-factor at which point a COAP ping could get re-transmitted. =   But does the peace time COAP Ping transmission rate have to = be greater or equal to the COAP layer reporting the “Ping” = CON has failed?

 

In war time, the next = COAP Ping should be delayed until after the current COAP Ping has = expired.

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots= -bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 06 October 2017 15:00
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Minimum heartbeat-interval

 

Thanks Med, agreed on = (2) (no need to negotiate and configure = heartbeat-interval).

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, October 6, 2017 7:12 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] Minimum heartbeat-interval

 

Tiru,

 

We are on the same page for (1). I hope we will hear more voices on this before we add = some text to the draft to clarify missing points. =

 

Please see inline for (2).

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 6 octobre 2017 15:08
=C0 : BOUCADAIR Mohamed = IMT/OLN; Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] Minimum = heartbeat-interval

 

Hi Med,

 

Please see inline = [TR]

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, October 6, 2017 12:40 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] Minimum heartbeat-interval

 

Hi = Tiru, all,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-l= anguage:FR'>]
Envoy=E9 : jeudi 5 octobre 2017 = 12:54
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org
Objet : RE: [Dots] Minimum = heartbeat-interval

 

http://c= onferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/= rfc7925 has tested NAT behavior with various routers and lists the = timeout results. The majority of the devices (62%) have a timeout = between 2 and 2.5 minutes and the minimum timeout value observed when = packets are exchanged b/w peers in both directions is 54 seconds. =

 

Responses to the = questions below

 

1) The = max-retransmit parameter is negotiable and configurable,  DOTS = agents can pick suitable values for max-retransmit parameter based on = the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the = MAX_TRANSMIT_WAIT to 45 seconds).

&n= bsp;

[Med] You are right about = the configurable aspect, but the question from Jon is a good one. I = interpret it in another way:

-   = Should we rely solely on = the missing-hb-allowed to detect a session = problem?

 

[TR] If the DOTS agent does not = receive a response to “CoAP ping” but receives other type of = messages from the peer DOTS agent then a counter incremented each time = there is no response to a “CoAP ping” till the counter value = hits missing-hb-allowed to determine the session is defunct can be reset = to zero.

-   = Should we get rid of = missing-hb-allowed, but rely on the retransmission to declare failure or = not?

 

[TR] If DOTS agents only rely on = the retransmission mechanism then a “CoAP ping” message will = only be retransmitted 4 times before concluding the session is = disconnected in an interval of 93 seconds. The network under DDoS attack = is likely to be congested (high packet loss and latency), hence = missing-hb-allowed is used to send the “CoAP ping” more = number of times (3 (ping) + 3*4 (re-transmissions) =3D 15 times) with = sufficient time interval (93*3 =3D 279 seconds) to determine the session = is defunct.

 

-   = What is the advantage of = cumulating both missing-hb-allowed and the retransmission procedure to = declare a channel out?

 

[TR] Please see = above.

 

=

2) No,

[Med] I agree that a = heartbeat does not need to be fired when the first ping is still alive. = We can clarify this in the draft.

 

[TR] Thanks. =

 

=

if the DOTS agent = wants to change the default heartbeat interval then the other message = transmission parameters will also have to be modified. =

[Med] I disagree here that = the other parameters need to be changed. I don’t see = heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree = that we need to tweak heartbeat-interval as a function of = MAX_TRANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from = other parameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * = ACK_RANDOM_FACTOR)). This is why it does not make sense to provide a = configuration for MAX_TRANSMIT_WAIT if the other parameters are = provided.

 

[TR] I did not get the above, the = draft is not providing any new configuration for MAX_TRANSMIT_WAIT

[Med] I was talking about = heartbeat-interval.

 

=

. If let’s say the DOTS = agents decide to change the heartbeat interval to 45 seconds then the = max-retransmit has to be changed to 3 to arrive at 45 second = MAX_TRANSMIT_WAIT value (or other message transmission parameters = ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new = heartbeat interval).

[Med] My comment is that if = heartbeat-interval was dependent on transmission parameters, then we do = not need to configure it explicitly IN ADDITION to the other = transmission parameter.  

 

=

How can the heartbeat interval = change without changing the message transmission parameters = ?

[Med] I do see these two as = separate parameters. The heartbeat-interval determines the frequency of = sending keeplaive messages. This is an additional transmission parameter = specific to heartbeat if you will.

 

-Tiru

 

 

=

3) The client will = have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#sec= tion-2.2.1) and initiate (D)TLS session resumption =

4) If heartbeat = expires then the DOTS server will close the (D)TLS session, the client = will have to initiate (D)TLS session resumption. The heartbeat expires = only after 273 seconds (3 “CoAP ping” confirmable messages, = each
“CoAP ping” re-transmitted 4 times). =

 

Med – In the = below text, recommended value should be 93 seconds instead of 90 seconds = (see https://tools.= ietf.org/html/rfc7252#section-4.8.2).

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Wednesday, October 4, = 2017 5:36 PM
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] Minimum heartbeat-interval

 

Hi = Mohamed,

 

In principal I agree = with your suggested updates – the minimum of 10s was an off the = cuff response, to handle the “broken” NAT timing = implementations out there. 

 

The Heartbeat mechanism = does raise a few questions in my mind which do need to be thought = through.  On a DOTS server, using a heartbeat interval of 15 secs, = with the client going away circa 10:54:30, I get

 

Oct 04 10:53:51 DEBG sending CoAP = ping:

Oct 04 = 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to retransmit queue = (2281ms)

Oct 04 = 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message = 29548

Oct 04 = 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending CoAP = ping:

Oct 04 = 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to retransmit queue = (2938ms)

Oct 04 = 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message = 29549

Oct 04 = 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending CoAP = ping:

Oct 04 = 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to retransmit queue = (2156ms)

Oct 04 = 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message = 29550

Oct 04 = 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending CoAP = ping:

Oct 04 = 10:54:39 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to retransmit queue = (2813ms)

Oct 04 = 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #1

Oct 04 10:54:42 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #2

Oct 04 10:54:48 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #3

Oct 04 10:55:00 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #4

Oct 04 10:55:23 DEBG *  192.168.0.189:5684 = <-> 192.168.0.1:54477 (if1) DTLS: sent 41 = bytes

Oct 04 = 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: give up after 4 attempts

 

Here we see the 91 = seconds (dependant on the max-retransmit value being 4) 10:56:09 – = 10:54:39.  There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 = before retry transmission #4).

 

Question = 1

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

Should the = max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON is only used for signal configuration = (infrequent, likely only to be in peace time) and heartbeats, not = mitigation requests

 

Question = 2

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

If the heartbeat = interval is less than 91 seconds – say 60 seconds and the first = heartbeat ping is still active, should a second heartbeat be fired = off?

- I think not, but the text then needs to get = updated to state the interval is used whenever there is not a pending = heartbeat response outstanding.

 

Question = 3

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

 

Heartbeat checks are = being initiated by the client.  The client gets a heartbeat timeout = on the session.  The client subsequently needs to send a PUT = mitigate request.

 

Does the client set up a = new session?

- Difficult as we are unlikely to be in peace = time

- PKI exchanges are likely to = fail

- the client just needs to send a = non-confirmable PUT.

 

Question = 4

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

 

Scenario as = Q3

 

Does the client re-use = the old session that the heartbeats are failing = on?

- The server may have sent a session close, but = it never got through

 

Question = 4

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

When the heartbeats are = initiated by the server, and the heartbeat times out, the session is = “bad”, but the current mitigation request continues until it = expires.

The client may have kicked off his heartbeats at = a different time, and there likely will be a sending frequency drift = over time, so the client may think the session is still active, the = server not, and the client decides it is time to send a non-confirmable = PUT to refresh the mitigation as it is about to expire or possibly = another PUT for a different IP that has just started to get hammered = – hence heartbeat failures. 

Alternatively the client = decides that the reason for “bad” session (from the = client’s perspective) is an attack stopping traffic getting = through and needs to do a PUT on the existing = session.

 

So server receives a PUT = (refresh or for a new IP) on a session that has heartbeat expired.  = The session contained all the negotiated PKI session keys etc.  = What should happen here?

- as the heartbeats are failing, it is safe to = assume we are not in peace time.

- I believe the session = on the server needs to be kept hanging around for some time post = heartbeat time-out. For how long?

- the server may be = seeing the client heartbeat messages [this may answer how to keep = “bad” session hanging around]

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots= -bounces@ietf.org] On Behalf Of ietf-supjps-moha= med.boucadair@orange.com
Sent: 04 October 2017 = 09:35
To: dots@ietf.org; = Jon Shallow (supjps-ietf@jpshallow.com)<= br>Subject: [Dots] Minimum = heartbeat-interval

 

Dear all, =

 

Jon = made the following comment during the interim meeting: = “A: (Jon Shallow): The minimum for the = heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with RFC8085 which says = the following:

 

   An application that needs to =
employ keep-alive messages to deliver
   useful service over UDP in =
the presence of middleboxes SHOULD NOT
       &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;  ^^^^^^^^^^^^^^^^^^^^^^
   transmit them more frequently =
than once every 15 seconds and SHOULD
 =
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^
   use longer intervals when =
possible. 

 

I = suggest to add this NEW text to the signal-channel draft to clarify the = rationale for the recommended values:

 

NEW:

      Note: heartbeat-interval should = be tweaked to also assist DOTS

      messages for NAT traversal = (SIG-010 of

      = [I-D.ietf-dots-requirements]).  According to [RFC8085], = keepalive

      messages must not be sent more = frequently than once every 15

      seconds and should use longer = intervals when possible.

      Furthermore, [RFC4787] = recommends NATs to use a state timeout of 2

      minutes or longer.  From = that standpoint, this specification

      recommends a minimum = heartbeat-interval of 15 seconds and a

      maximum heartbeat-interval of = 240 seconds.  The recommended value

      of 90 seconds is selected to = anticipate the expiry of NAT states,

      while avoiding overloading the = network with frequent keepalives

      for NAT state maintenance = purposes.  Note that this recommended

      value is close to the one = recommended for MAX_TRANSMIT_WAIT, whose

      value is derived from = transmission parameters (Section 4.8.2 of

      [RFC7252]).

 

Thoughts?

 

Cheers,

Med

------=_NextPart_000_0A09_01D33F57.F0671B30-- From nobody Sat Oct 7 04:09:10 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E59913489D for ; Sat, 7 Oct 2017 04:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 ohu13wiwQzFG for ; Sat, 7 Oct 2017 04:09:08 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0134.outbound.protection.outlook.com [104.47.37.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01467134899 for ; Sat, 7 Oct 2017 04:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lcyCHdvwjia5J2lFpODv6oaDjWteM9dJAwdIHDJx9Jg=; b=i12TmfgyWeYBP/y6BFZaSamhn7f2Cjf6rFHsSqQJTc1wLEp2qiAsDPfo/xFGw3vsyXBn1U7d5oeMhuU+oka7r6xDe+3RH0cNH+llljALKX3LKEjkB0pNhT368d4qs8ZFb75L0THpAe8ShXmYxgKPU0/gdmHNb8pkV7j+THmPRlU= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1040.prod.exchangelabs.com (10.160.129.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Sat, 7 Oct 2017 11:09:06 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::f4d3:7c95:465c:e5b]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::f4d3:7c95:465c:e5b%15]) with mapi id 15.20.0077.018; Sat, 7 Oct 2017 11:09:06 +0000 From: "Dobbins, Roland" To: "Konda, Tirumaleswar Reddy" CC: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAPOhQAAAcGbIAAA6FpPgAD9IKAACn2sgAADUrUAAAAfhAAABvQXwAAEBoE/Q== Date: Sat, 7 Oct 2017 11:09:06 +0000 Message-ID: <06EB9E68-F101-4809-8BF1-9C6FCDC6071E@arbor.net> References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; x-originating-ip: [184.82.237.231] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1040; 6:UBDkW+e7QfRtVRGhF85SvDhHzz6kumTQ67mWi4mv5Qmv2Edb4GndSC9PMUaAEQVeectB4ybKO2bcgkqOxsHDaq2r9mkFfK8vzKG4+2jfM6Sqm6vupJWpSNbNlEvRfl0NlVijiUxRMNUy9zCcjNioXzWyAgQoUIHsFjCEcKkHOKZeJv+cearMQELxVaIr9AV2aeWZuT1zFData//6JRNrgJweq3rVHRV4PreYitWu7B7N8GJP5LttuqSmLVS5n+KJZYju0Bl8W/t7yquYeyznt9LbaCAitB4Zoyo99JgOwTXHjyyYji5dWbvfEux+NFaGBLlDIMqXt/VLnQJ/yZH5Rg==; 5:1Ec0XbhAlQ+SsQ8vD/gd7s+p4aDtJlq6tf+9IURLGG/igjdZUhKJT6gfJn//yHZmgGG0Wo9j9Eu+T3gnXUaBOXwUkl0gdITvaT/EzMlSkXmo/szXGwq56R1PeUpMb03oearuWpbrRhRjUA22iEeoXg==; 24:0VfO5keLJelJpzaZFBdyTy+E5JNctlNsoRugkXoxmrMvuvbj2iNj2CT+djdJXuu71n9aFzpd96wMHfkfMdnqobSh9756m+JDeI8/eOf7ZkA=; 7:vztXeuTikvBKXEuC9Z/OpfDgnyyzYhTSC57NJLmoyYvy7Xuy1+EaC/cO+14abDblP87XjUit7SAwuMF2isgj1fTD9Pu7t9XWj1dCA2rtoGNSRWtGo7D5btrDUZzRoDb5mQ1gvoVPJDBjvcgjpo+X3sGuYOIAPRK8PL8QFg2IErBtYlCHvQ8W8vySA2fdCX0UWPK93R70s0HAFjk7iyDcpiWir4Wv3JYfhW/IGIapgwA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d2b1f7e7-7e62-40e3-c630-08d50d73d3bf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR0101MB1040; x-ms-traffictypediagnostic: DM2PR0101MB1040: x-exchange-antispam-report-test: UriScan:(158342451672863)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1040; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1040; x-forefront-prvs: 045315E1EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(24454002)(199003)(189002)(316002)(6246003)(54356999)(81166006)(53936002)(189998001)(2900100001)(2950100002)(6512007)(99286003)(54896002)(6116002)(105586002)(106356001)(50986999)(76176999)(229853002)(3280700002)(2906002)(236005)(33656002)(4326008)(101416001)(68736007)(36756003)(5250100002)(7736002)(3660700001)(14454004)(6436002)(8936002)(8676002)(66066001)(83716003)(25786009)(86362001)(5660300001)(6916009)(82746002)(3846002)(54906003)(102836003)(97736004)(81156014)(93886005)(6506006)(53546010)(478600001)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1040; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_06EB9E68F10148098BF19C6FCDC6071Earbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2017 11:09:06.5879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1040 Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 11:09:09 -0000 --_000_06EB9E68F10148098BF19C6FCDC6071Earbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIE9jdCA3LCAyMDE3LCBhdCAxMDoyOCwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8 VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbT4+IHdyb3RlOg0KDQpJbiBjYXNlIG9mIGNsaWVudC1zaWRlIERP VFMgZ2F0ZXdheSwgd2h5IGRvZXMgdGhlIERPVFMgc2VydmVyIG5lZWQgdG8ga25vdyB3aGljaCDi gJxET1RTIGNsaWVudOKAnSBoYXMgY29udmV5ZWQgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCA/DQoN CkJlY2F1c2UgdGhlcmUgbWF5IGJlIG1pdGlnYXRpb24gc3BlY2lmaWNzLCBwb2xpY3ksIGFuZC9v ciBjb250cmFjdHVhbCBvYmxpZ2F0aW9ucyB3aGljaCBhcmUgY2xpZW50LXNwZWNpZmljLg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUm9sYW5kIERvYmJpbnMgPHJkb2Ji aW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pj4NCg== --_000_06EB9E68F10148098BF19C6FCDC6071Earbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gT2N0IDcsIDIwMTcs IGF0IDEwOjI4LCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDs8YSBocmVmPSJtYWlsdG86 VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+VGlydW1hbGVzd2FyUmVkZHlfS29u ZGFATWNBZmVlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PkluIGNhc2Ugb2YgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5 LCB3aHkgZG9lcyB0aGUgRE9UUyBzZXJ2ZXIgbmVlZCB0byBrbm93IHdoaWNoIOKAnERPVFMgY2xp ZW504oCdIGhhcyBjb252ZXllZCB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0ID88L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxicj4NCjxkaXY+QmVjYXVzZSB0aGVyZSBtYXkgYmUgbWl0aWdhdGlvbiBzcGVj aWZpY3MsIHBvbGljeSwgYW5kL29yIGNvbnRyYWN0dWFsIG9ibGlnYXRpb25zIHdoaWNoIGFyZSBj bGllbnQtc3BlY2lmaWMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBzdHls ZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxzcGFuIHN0eWxl PSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFu OiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyIHN0eWxl PSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFu OiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyI+DQo8L3NwYW4+DQo8ZGl2IHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlv bjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPlJvbGFuZCBEb2JiaW5zICZsdDs8YSBo cmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0 Ozwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_06EB9E68F10148098BF19C6FCDC6071Earbornet_-- From nobody Mon Oct 9 06:09:28 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A68013243A for ; Mon, 9 Oct 2017 06:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 3toXPl8cVEeY for ; Mon, 9 Oct 2017 06:09:18 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 938CF134293 for ; Mon, 9 Oct 2017 06:09:17 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507554533; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=c BpJZPyIV6G6scgRJvLJizzrJbg6ExEZgmL86HcRm2 4=; b=WREt/BngIh9l8bseUH5gCjXNexuPmeMF02G4PNXSWz3B VuEtYco6c6isq7NYawcpTS3atWzsbrjfbI0ixhPEk9lvqdAaWf wnMu1HO/XVQhKiE22iN8ZDaH29CbzcvvgTisVFyXzzJ2mc8b66 PNjTb+qIPtPHa8kB24j8sNpOToU= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 1c7f_4966_5ec7ea62_9138_470e_a2d1_b6fa3a5d47f7; Mon, 09 Oct 2017 08:08:52 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 07:08:51 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Oct 2017 07:08:51 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 07:08:50 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 9 Oct 2017 13:08:49 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.019; Mon, 9 Oct 2017 13:08:49 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" , "mohamed.boucadair@orange.com" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AdM866F1exiXOD0RS+2TvvngfvHPNAAHYE+AAC3w14AALEpYgAALE5wwAAKjs4AAAJFkQAANym6AAA3Ky0AADYHagABr7oPg Date: Mon, 9 Oct 2017 13:08:49 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A050387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0506A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <098901d33ee2$5c3478b0$149d6a10$@jpshallow.com> <0a0801d33f4f$8e9df840$abd9e8c0$@jpshallow.com> In-Reply-To: <0a0801d33f4f$8e9df840$abd9e8c0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.90.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:BmXwQ/Kyj8WXA94MRHYCPeiQQtT8faysdAAopeW/OO6cu4vBwJS7djaMI5iqKvoblf52pH2zCquJTaSvO4eVSuRrdNl0D9isgRsi3BugU6Ip+qSVwDkLd6M0nlRyhwSAy3/gPauU+iFy1iPNs/Ye0CXwXjNPqypag7eXgUdf+lRUFBlZi1nTAtb/XObYdWpPCHyIenrOEoEOfIDMuc7uFjsS0QE0cvkzCPZbgxbcl3BVv/PIHJ4hDN1RzyfZe8fQ4wj9YefK45Ak2a62NonjQU10ds85hcpLYBDEC2UasvSTMfoz9sC6Gz0BzcBP6uZa32fEAlPp8LIU3eC+56qYcQ==; 5:oGnFSVHLiwIACGVXbo/9JT2VQVyx+8njpv9IQf5aqi3O9OE8uFjWFMlcc1DIUAE3mG75jvB740Ru3Cpti1zQ3kCnmNYnfeAdk1/RKiS/DVQbx9dKHtivs53xj7bb06mv5cjpPgqAEXMU7jhwXLXnrA==; 24:tXudivkMAe95R2hnMcKGiwkNiDYpS6IPee2/9IeeStLdwJybhAIrPxUCzuyRyB8yWL/T9+BpseoUBt5S4QE7NmBlC2kcGBZhbTNz39rpVm4=; 7:zL7U5mcodShWT/Mh09nVNp3Pq99bKOST75zfaaPsgGnTeu64By/hZILTKslLXdK+fROE0m8n+FoeJiG8VT78T219/9aeJjZ57456UZKkL051kizP6Rcs1j1je2swT38h7+fRZUbBDMx7ZEQk4BOfIrNvtkjrhb6nwsh+8FR1CQ93Vko5T+Q46DNrH9HmZPbgHnsKyKJV8FRmgOlengUhfksH3pBCCjh6eW7scPTgEag= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 17d0f7c4-058a-4736-3f54-08d50f16e1d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(211171220733660)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(32952001)(377454003)(189002)(199003)(6506006)(77096006)(6436002)(53546010)(80792005)(2900100001)(5660300001)(2950100002)(606006)(14454004)(9686003)(72206003)(966005)(478600001)(53936002)(54896002)(236005)(99286003)(55016002)(97736004)(6306002)(6246003)(7696004)(19609705001)(81166006)(8676002)(7736002)(81156014)(2906002)(8936002)(3280700002)(2201001)(2501003)(3660700001)(33656002)(74316002)(25786009)(106356001)(6116002)(102836003)(105586002)(229853002)(93886005)(86362001)(3846002)(790700001)(316002)(53946003)(68736007)(66066001)(101416001)(50986999)(189998001)(110136005)(54356999)(76176999)(85282002)(562404015)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788AAB977C5FAEF4C6688FEEA740DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2017 13:08:49.3960 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6132> : inlines <6112> : streams <1766506> : uri <2513741> Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 13:09:26 -0000 --_000_DM5PR16MB1788AAB977C5FAEF4C6688FEEA740DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see inline [TR] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, October 7, 2017 3:05 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org; mohamed.boucadair@orange.com Subject: RE: [Dots] Minimum heartbeat-interval Hi Tiru, I confess to being troubled when considering tuning the various max-retrans= mit, ack-timeout and ack-random-factor values to get heartbeats behaving as= required, as this will also affect anything else using CON for the request= s. With ack-timeout =3D 2, ack-random-factor =3D 1.5 and max-retransmit =3D 4 = (the defaults) and loss of response Heartbeat Ping 3 seconds Ping retry #1 6 seconds Ping retry #2 12 seconds Ping retry #3 24 seconds Ping retry #4 48 seconds Heartbeat Ping Timeout (after 93 seconds) reported to upper layers In terms of NAT (or even firewall session with no NAT) keep-alive, we are d= oing this with a value of 3 seconds up to 48 seconds. I am making the assumption that the next Heartbeat Ping request (under resp= onse loss conditions) almost immediately follows the Heartbeat Ping Timeout= , the cycles of which give up after missing-hb-allowed is exceeded and the = session is declared as dead. When there is no loss of response Heartbeat Ping Small number of milli seconds Ping Response (RST) MAX_TRANSMIT_WAIT (93 seconds) Heartbeat Ping Small number of milli seconds Ping Response (RST) ... I propose that instead of MAX_TRANSMIT_WAIT (93 seconds), we should use the= derived 48 second gap (between Ping Retry #4 and Heartbeat Ping Timeout) w= hen there is no loss of response for repeating Ping. Thoughts? The reason for this is that you state below "the minimum timeout value obse= rved when packets are exchanged b/w peers in both directions is 54 seconds.= " A potential workaround to this discussion is that the spec states "To make = sure that Heartbeats work correctly, any firewall rule (whether NAT'd or no= t) on a firewall sitting between the DOTS client and DOTS Server that enabl= es the DOTS signal channel to traverse the device MUST have an idle session= timeout value greater than the derived MAX_TRANSMIT_WAIT" Proposed text looks good. In addition to the above change, max-retransmit c= an be reduced from 4 to 3 to reduce MAX_TRANSMIT_WAIT from 93 seconds to 45= seconds. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 07 October 2017 04:11 To: Jon Shallow; dots@ietf.org; mohamed.boucadair@ora= nge.com Subject: Re: [Dots] Minimum heartbeat-interval Hi Jon, I meant heartbeat-interval will be defined as equivalent to MAX_TRANSMIT_WA= IT but not negotiated as heartbeat-interval is derived from the message tra= nsmission parameters. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, October 7, 2017 2:03 AM To: Konda, Tirumaleswar Reddy >; dots@ietf.org; mo= hamed.boucadair@orange.com Subject: RE: [Dots] Minimum heartbeat-interval Hi Guys, > Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-i= nterval). If heartbeat-interval is not defined / negotiated - what happens in peace t= ime? What rate should the heartbeats be sent at? If COAP Pings are timing out - yes, the length of time before the timeout i= s reported to the upper layers is dependent on max-retransmit, ack-timeout = and ack-random-factor at which point a COAP ping could get re-transmitted. = But does the peace time COAP Ping transmission rate have to be greater or= equal to the COAP layer reporting the "Ping" CON has failed? In war time, the next COAP Ping should be delayed until after the current C= OAP Ping has expired. Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, T= irumaleswar Reddy Sent: 06 October 2017 15:00 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-int= erval). -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, October 6, 2017 7:12 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval Tiru, We are on the same page for (1). I hope we will hear more voices on this be= fore we add some text to the draft to clarify missing points. Please see inline for (2). Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 6 octobre 2017 15:08 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] Minimum heartbeat-interval Hi Med, Please see inline [TR] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, October 6, 2017 12:40 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] Minimum heartbeat-interval Hi Tiru, all, Please see inline. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 5 octobre 2017 12:54 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Minimum heartbeat-interval http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). [Med] You are right about the configurable aspect, but the question from Jo= n is a good one. I interpret it in another way: - Should we rely solely on the missing-hb-allowed to detect a session pro= blem? [TR] If the DOTS agent does not receive a response to "CoAP ping" but recei= ves other type of messages from the peer DOTS agent then a counter incremen= ted each time there is no response to a "CoAP ping" till the counter value = hits missing-hb-allowed to determine the session is defunct can be reset to= zero. - Should we get rid of missing-hb-allowed, but rely on the retransmission= to declare failure or not? [TR] If DOTS agents only rely on the retransmission mechanism then a "CoAP = ping" message will only be retransmitted 4 times before concluding the sess= ion is disconnected in an interval of 93 seconds. The network under DDoS at= tack is likely to be congested (high packet loss and latency), hence missin= g-hb-allowed is used to send the "CoAP ping" more number of times (3 (ping)= + 3*4 (re-transmissions) =3D 15 times) with sufficient time interval (93*3= =3D 279 seconds) to determine the session is defunct. - What is the advantage of cumulating both missing-hb-allowed and the ret= ransmission procedure to declare a channel out? [TR] Please see above. 2) No, [Med] I agree that a heartbeat does not need to be fired when the first pin= g is still alive. We can clarify this in the draft. [TR] Thanks. if the DOTS agent wants to change the default heartbeat interval then the o= ther message transmission parameters will also have to be modified. [Med] I disagree here that the other parameters need to be changed. I don't= see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree= that we need to tweak heartbeat-interval as a function of MAX_TRANSMIT_WAI= T). As you know, MAX_TRANSMIT_WAIT can be derived from other parameters (AC= K_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR)). This i= s why it does not make sense to provide a configuration for MAX_TRANSMIT_WA= IT if the other parameters are provided. [TR] I did not get the above, the draft is not providing any new configurat= ion for MAX_TRANSMIT_WAIT [Med] I was talking about heartbeat-interval. . If let's say the DOTS agents decide to change the heartbeat interval to 4= 5 seconds then the max-retransmit has to be changed to 3 to arrive at 45 se= cond MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_= TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new heartb= eat interval). [Med] My comment is that if heartbeat-interval was dependent on transmissio= n parameters, then we do not need to configure it explicitly IN ADDITION to= the other transmission parameter. How can the heartbeat interval change without changing the message transmis= sion parameters ? [Med] I do see these two as separate parameters. The heartbeat-interval det= ermines the frequency of sending keeplaive messages. This is an additional = transmission parameter specific to heartbeat if you will. -Tiru 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med --_000_DM5PR16MB1788AAB977C5FAEF4C6688FEEA740DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please se= e inline [TR]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Saturday, October 7, 2017 3:05 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org; mohamed.boucadair@orange.com
Subject: RE: [Dots] Minimum heartbeat-interval

 

Hi Tiru= ,

&n= bsp;

I confe= ss to being troubled when considering tuning the various max-retransmit, ac= k-timeout and ack-random-factor values to get heartbeats behaving as requir= ed, as this will also affect anything else using CON for the requests.

&n= bsp;

With ac= k-timeout =3D 2, ack-random-factor =3D 1.5 and max-retransmit =3D 4 (the de= faults) and loss of response

Heartbe= at Ping

3 secon= ds

Ping re= try #1

6 secon= ds

Ping re= try #2

12 seco= nds

Ping re= try #3

24 seco= nds

Ping re= try #4

48 seco= nds

Heartbe= at Ping Timeout (after 93 seconds) reported to upper layers

&n= bsp;

In term= s of NAT (or even firewall session with no NAT) keep-alive, we are doing th= is with a value of 3 seconds up to 48 seconds.

I am ma= king the assumption that the next Heartbeat Ping request (under response lo= ss conditions) almost immediately follows the Heartbeat Ping Timeout, the c= ycles of which give up after missing-hb-allowed is exceeded and the session is declared as dead.

&n= bsp;

When th= ere is no loss of response

&n= bsp;

Heartbe= at Ping

Small n= umber of milli seconds

Ping Re= sponse (RST)

MAX_TRANS= MIT_WAIT (93 seconds)

Heartbe= at Ping

Small n= umber of milli seconds

Ping Re= sponse (RST)

…=

&n= bsp;

I propo= se that instead of MAX_TRANSMIT_WAIT (93 sec= onds), we should use the derived 48 second gap (between Ping Retry #4 and H= eartbeat Ping Timeout) when there is no loss of response for repeating Ping= .  Thoughts?

&nbs= p;

The reaso= n for this is that you state below “the minimum timeout value observed when p= ackets are exchanged b/w peers in both directions is 54 seconds.”

 

A potential workaround to this discussion is that the spec states &= #8220;To make sure that Heartbeats work correctly, any firewall rule (wheth= er NAT’d or not) on a firewall sitting between the DOTS client and DOTS Server that enables the DOTS signal channel to tr= averse the device MUST have an idle session timeout value greater than the = derived MAX_TRANSMIT_WAIT” =

&nbs= p;

Proposed = text looks good. In addition to the above change, max-retransmit can be red= uced from 4 to 3 to reduce MAX_TRANSMIT_WAIT from 93 seconds to 45 seconds.=

&nbs= p;

-Tiru

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 04:11
To: Jon Shallow; dots@ietf.org;= mohamed.boucadair@orange.com
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Jon,

&nbs= p;

I meant h= eartbeat-interval will be defined as equivalent to MAX_TRANSMIT_WAIT but no= t negotiated as heartbeat-interval is derived from the message transmission= parameters.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Saturday, October 7, 2017 2:03 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org; mohamed.boucadair@orange.com
Subject: RE: [Dots] Minimum heartbeat-interval

 

Hi Guys= ,

&n= bsp;

> Thanks Med, agreed on (2) (= no need to negotiate and configure heartbeat-interval).

&n= bsp;

If hear= tbeat-interval is not defined / negotiated – what happens in peace ti= me?  What rate should the heartbeats be sent at?

&n= bsp;

If COAP= Pings are timing out – yes, the length of time before the timeout is= reported to the upper layers is dependent on max-retransmit, ack-timeout a= nd ack-random-factor at which point a COAP ping could get re-transmitted.   But does the peace time COAP Ping tr= ansmission rate have to be greater or equal to the COAP layer reporting the= “Ping” CON has failed?

&n= bsp;

In war = time, the next COAP Ping should be delayed until after the current COAP Pin= g has expired.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 October 2017 15:00
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Thanks Me= d, agreed on (2) (no need to negotiate and configure heartbeat-interval).

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, October 6, 2017 7:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] Minimum heartbeat-interval

 

Tiru,

 

We are on the same page for (1). I hope we will hear more voices on this before we add some tex= t to the draft to clarify missing points.

 

Please see inline for (2).

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 6 octobre 2017 15:08
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] Minimum heartbeat-interval=

 

Hi Med,

&nbs= p;

Please se= e inline [TR]

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, October 6, 2017 12:40 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] Minimum heartbeat-interval

 

Hi Tiru, all,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com<= span style=3D"font-size:10.0pt;font-family:"Tahoma",sans-serif;ms= o-fareast-language:FR">]
Envoy=E9 : jeudi 5 octobre 2017 12:54
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Minimum heartbeat-interval=

 

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html= /rfc7925 has tested NAT behavior with various routers and lists the tim= eout results. The majority of the devices (62%) have a timeout between 2 an= d 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is = 54 seconds.

 

Responses to the questions below

 

1) The max-retransmit parameter is negotiable and configurable,&nbs= p; DOTS agents can pick suitable values for max-retransmit parameter based = on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).

 

[Med] You are right= about the configurable aspect, but the question from Jon is a good one. I = interpret it in another way:

- &n= bsp; Should we rely solely on the missin= g-hb-allowed to detect a session problem?

&nbs= p;

[TR] If t= he DOTS agent does not receive a response to “CoAP ping” but re= ceives other type of messages from the peer DOTS agent then a counter incre= mented each time there is no response to a “CoAP ping” till the counter value hits missing-hb-allowed to determine th= e session is defunct can be reset to zero.

- &n= bsp; Should we get rid of missing-hb-all= owed, but rely on the retransmission to declare failure or not?<= /span>

&nbs= p;

[TR] If D= OTS agents only rely on the retransmission mechanism then a “CoAP pin= g” message will only be retransmitted 4 times before concluding the s= ession is disconnected in an interval of 93 seconds. The network under DDoS attack is likely to be congested (high packet loss = and latency), hence missing-hb-allowed is used to send the “CoAP ping= ” more number of times (3 (ping) + 3*4 (re-transmissions) =3D 15 = times) with sufficient time interval (93*3 =3D 279 seconds) to determine the session is defunct.

&nbs= p;

- &n= bsp; What is the advantage of cumulating= both missing-hb-allowed and the retransmission procedure to declare a chan= nel out?

&nbs= p;

[TR] Plea= se see above.

 

2) No,

[Med] I agree that = a heartbeat does not need to be fired when the first ping is still alive. W= e can clarify this in the draft.

&nbs= p;

[TR] Than= ks.

 

if the DOTS agent wants to change the default heartbeat interval th= en the other message transmission parameters will also have to be modified.

[Med] I disagree he= re that the other parameters need to be changed. I don’t see heartbea= t-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree that we need to tweak heartbeat-interval as a function of MAX_T= RANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from other par= ameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_F= ACTOR)). This is why it does not make sense to provide a configuration for MAX_TRANSMIT_WAIT if the other parame= ters are provided.

&nbs= p;

[TR] I di= d not get the above, the draft is not providing any new configuration for M= AX_TRANSMIT_WAIT

[Med] I was talking= about heartbeat-interval.

 

. If let&= #8217;s say the DOTS agents decide to change the heartbeat interval to 45 s= econds then the max-retransmit has to be changed to 3 to arrive at 45 secon= d MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be change= d to arrive at the new heartbeat interval).

[Med] My comment is= that if heartbeat-interval was dependent on transmission parameters, then = we do not need to configure it explicitly IN ADDITION to the other transmission parameter.  

 

How can t= he heartbeat interval change without changing the message transmission para= meters ?

[Med] I do see thes= e two as separate parameters. The heartbeat-interval determines the frequen= cy of sending keeplaive messages. This is an additional transmission parameter specific to heartbeat if you will.

&nbs= p;

-Tiru

&nbs= p;

 

3) The client will have to assume the session is disconnected (see = the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The he= artbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 

Med – In the below text, recommended value should be 93 secon= ds instead of 90 seconds (see https://tools= .ietf.org/html/rfc7252#section-4.8.2).

 

-Tiru<= /span>

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

&n= bsp;

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

&n= bsp;

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

&n= bsp;

Oct 04 10:53:51 DEBG sending C= oAP ping:

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to re= transmit queue (2281ms)

Oct 04 10:53:51 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:53:51 ALRT got RST f= or message 29548

Oct 04 10:53:51 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending C= oAP ping:

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to re= transmit queue (2938ms)

Oct 04 10:54:07 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:07 ALRT got RST f= or message 29549

Oct 04 10:54:07 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending C= oAP ping:

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to re= transmit queue (2156ms)

Oct 04 10:54:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes=

Oct 04 10:54:23 ALRT got RST f= or message 29550

Oct 04 10:54:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending C= oAP ping:

Oct 04 10:54:39 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to re= transmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #1

Oct 04 10:54:42 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #2

Oct 04 10:54:48 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #3

Oct 04 10:55:00 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmis= sion #4

Oct 04 10:55:23 DEBG *  1= 92.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.16= 8.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up af= ter 4 attempts

&n= bsp;

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

&n= bsp;

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

&n= bsp;

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

&n= bsp;

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

&n= bsp;

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Scenari= o as Q3

&n= bsp;

Does th= e client re-use the old session that the heartbeats are failing on?

- The s= erver may have sent a session close, but it never got through

&n= bsp;

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

&n= bsp;

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

&n= bsp;

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow = (supjps-ietf@jpshallow.com= )
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during the interim meeting:= “A: (Jon Shallow): The minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with RFC8085 which= says the following:

 

   An application that needs to employ kee=
p-alive messages to deliver
   useful service over UDP in the presence=
 of middleboxes SHOULD NOT
        &nbs=
p;            &=
nbsp;           &nbs=
p;            ^^^^^^=
^^^^^^^^^^^^^^^^
   transmit them more frequently than once=
 every 15 seconds and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   use longer intervals when possible.&nbs=
p;

 

I suggest to add this NEW text to the signal-channel draft= to clarify the rationale for the recommended values:

 

NEW:

    &= nbsp; Note: heartbeat-interval should be tweaked to also assist DOTS

    &= nbsp; messages for NAT traversal (SIG-010 of

    &= nbsp; [I-D.ietf-dots-requirements]).  According to [RFC8085], keepaliv= e

    &= nbsp; messages must not be sent more frequently than once every 15

    &= nbsp; seconds and should use longer intervals when possible.

    &= nbsp; Furthermore, [RFC4787] recommends NATs to use a state timeout of 2

    &= nbsp; minutes or longer.  From that standpoint, this specification

    &= nbsp; recommends a minimum heartbeat-interval of 15 seconds and a

    &= nbsp; maximum heartbeat-interval of 240 seconds.  The recommended valu= e

    &= nbsp; of 90 seconds is selected to anticipate the expiry of NAT states,

    &= nbsp; while avoiding overloading the network with frequent keepalives<= /o:p>

    &= nbsp; for NAT state maintenance purposes.  Note that this recommended<= o:p>

    &= nbsp; value is close to the one recommended for MAX_TRANSMIT_WAIT, whose

    &= nbsp; value is derived from transmission parameters (Section 4.8.2 of<= /o:p>

      [RFC7252]).

 

Thoughts?

 

Cheers,

Med

--_000_DM5PR16MB1788AAB977C5FAEF4C6688FEEA740DM5PR16MB1788namp_-- From nobody Mon Oct 9 06:15:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E6E134316 for ; Mon, 9 Oct 2017 06:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 DypDSNkEnqCv for ; Mon, 9 Oct 2017 06:15:47 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 5A18A134529 for ; Mon, 9 Oct 2017 06:15:44 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507554938; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=W ADOoYOS8A4UIIm3K7ofXLa/lsCkkVHJZ6Lir+vaCj U=; b=dF2hJ0AJwYj507t2bdeOVfCr57WVdHuRMAweMjUV//22 rgN2mshS8A2AOcaQL/YbcHkcT7w+MtfgGcDF3N0XGjAzUy06fI OI/em7xY4or+6VQuXztnRQUVZZW+sKUN1SsiOv/5kWmtX16u6b u79mZtMZnGlRaeTKLCdLBzr0CmY= Received: from DNVEXAPP1N04.corpzone.internalzone.com (dnvexapp1n04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 1c7f_5288_0df5313f_84a2_4a1c_ad22_6d111062174b; Mon, 09 Oct 2017 08:15:37 -0500 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 07:15:20 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Oct 2017 07:15:20 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 07:15:20 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 9 Oct 2017 13:15:19 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.019; Mon, 9 Oct 2017 13:15:19 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Coding and Interoperability Challenges Thread-Index: AdMouv44Udo0NFExSCOHW+HXkRNTEQERxjbqAVIVJZ8CskQHRqGgxiVwoaSKVGC8uS4jAP/8yNewgAhJpAD//4ZJ0IABU9WA//ySqgA= Date: Mon, 9 Oct 2017 13:15:19 +0000 Message-ID: References: <070601d328ba$ffbbc440$ff334cc0$@jpshallow.com> <00a101d32d46$b2f30cf0$18d926d0$@jpshallow.com> <037c01d33a2c$ed764700$c862d500$@jpshallow.com> <040401d33ac9$85542c80$8ffc8580$@jpshallow.com> <060201d33c52$ca5ca390$5f15eab0$@jpshallow.com> <097101d33edc$0770b330$16521990$@jpshallow.com> <0a0301d33f49$171486a0$453d93e0$@jpshallow.com> In-Reply-To: <0a0301d33f49$171486a0$453d93e0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.90.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:J8ge3c2fuugLpZvfzuB4XJ/rJhOboaDyYjcz+cAcC8jE8s9Kv0FHKtPFs3J2aSnAatqTsINbpimcoMtBQjzipR5cSM3DdKGxZFGPPxMsw+zYW0T8TooYYWyw592WcKHHK26hytnVl3G75f8r37Gl6clHNPq6KQn0tmhRZuFMTo8714NsXYZa7a5Nse8wuasRbQmbz4hbcN8X2C5xPBM+Ijdtk5Y0vwMGpvhM+jdG5bXnTmFjjXgBLAWiF9wgzzKjg9o00LGBamtA2u4m75UguF3bhE/O8ikt/wfvMU5YL6H8galAtwAYrQpRINm/Lmkjt4vVcrK3AFo3OTNRlTzvXw==; 5:hfYtjYFLrDjHS70FtEHsP0LOIVniWbqzOlxyoQ3NfZnWdLjBJDmlYSs49pgx0bByhja2tx9h18X7D1TTQjoP4j2ZZ9hdVecQAEBqi1m3JGg3RJEyj6uwE22a9URFC+zVtq15QYXcJoJBVGpU6hL6GA==; 24:J99gBwHVrio2JWZZRfLZHfI2aUTZvFEPPw+tGV2j+lmQQfOjqd+TFvN0R6OemJY+Hhe38CjplEv40Q+z08KC5zXZEfRzhr8hJd/vD86yUSk=; 7:yS81PAtiXQMNEg27iRX5Oh4komlUhy1CvVAULaM0ZzuIKE2Ar6WgWwgUp2GKPE02zEZdKkC3PZnXxhx0WZWcG2M1opyhj5DyVhekk68Mi+pasoi2sTfI51oVFLK1cQVGa4WyUepMpvMhKjHRtBSLKnts2UsAOlfxwsj3zGOHnLnwCjgK4+eSDy68D4ENv/8dSgTVmaJYeff1nSSixwiVP4ldU2cZtrIlQAb5PMjf6Vw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a8043ad2-a6a2-4088-b38f-08d50f17ca3a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(13464003)(377454003)(189002)(32952001)(25786009)(189998001)(68736007)(966005)(77096006)(55016002)(76176999)(2900100001)(101416001)(54356999)(86362001)(3660700001)(478600001)(6506006)(5660300001)(305945005)(9686003)(33656002)(14454004)(3280700002)(50986999)(229853002)(2501003)(110136005)(53936002)(7696004)(2950100002)(316002)(74316002)(6306002)(72206003)(7736002)(99286003)(2906002)(102836003)(6116002)(3846002)(105586002)(80792005)(53546010)(81166006)(81156014)(106356001)(6246003)(93886005)(8676002)(97736004)(66066001)(6436002)(8936002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2017 13:15:19.3441 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6132> : inlines <6113> : streams <1766506> : uri <2513744> Archived-At: Subject: Re: [Dots] Coding and Interoperability Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 13:15:49 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Saturday, October 7, 2017 2:19 PM > To: Konda, Tirumaleswar Reddy ; > dots@ietf.org > Subject: Re: [Dots] Coding and Interoperability Challenges >=20 > Hi Tiru, >=20 > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08 >=20 > NumericDate > The "NumericDate" term has the same meaning, syntax, and > processing rules as the "NumericDate" term defined in Section 2 of > JWT [RFC7519], except that the CBOR numeric date representation > (from Section 2.4.1 of [RFC7049]) is used. The encoding is > modified so that the leading tag 1 (epoch-based date/time) MUST be > omitted. >=20 > Omitting the leading tag 1 then means that we actually are defining it as= a > float8 in the CBOR stream. Any reason as to why we cannot just define it= as a > float8 and state in the definition that is the number of seconds since 1 = Jan > 1970 UTC? >=20 > Or, we state that the leading tag 1 is omitted in the CBOR representation= . Both options work for me, we can follow the approach taken by draft-ietf-ac= e-cbor-web-token (i.e. omit leading tag 1). -Tiru >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Konda, Tirumaleswar Reddy [mailto: > TirumaleswarReddy_Konda@mcafee.com] >=20 > Sent: 07 October 2017 04:08 > To: Jon Shallow; dots@ietf.org > Subject: RE: [Dots] Coding and Interoperability Challenges >=20 > > -----Original Message----- > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Sent: Saturday, October 7, 2017 1:18 AM > > To: Konda, Tirumaleswar Reddy > ; > > dots@ietf.org > > Subject: RE: [Dots] Coding and Interoperability Challenges > > > > Hi Tiru > > > > >> > > >> So, should it be displayed (in JSON) as UTC, local timezone or > > >> simply > > seconds? > > >> > > >> Mitigation-start: 2017-10-03T10:15:30-05:00 Or > > >> Mitigation-start: 2017-10-03T15:15:30Z Or > > >> Mitigation-start: 1507040181.567890 > > > > > Mitigation-start: 1507040181.567890 (represented in JSON number > format). > > > > > -Tiru > > > > If you could add this " Mitigation-start: 1507040181.567890" into the > > spec as part of Fig 10, this would be great. > > > > However Tagged CBOR -> JSON is fine, but JSON -> CBOR will not create > > the tagged entry in CBOR. >=20 > Good point, we can follow the approach taken by > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08 for > NumericDate to address this problem. >=20 > -Tiru >=20 > > > > Regards > > > > Jon >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Oct 9 06:16:46 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C45413452C for ; Mon, 9 Oct 2017 06:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 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_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 B6Tvo6LmMd2F for ; Mon, 9 Oct 2017 06:16:42 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 A25FD134316 for ; Mon, 9 Oct 2017 06:16:40 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507554993; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=9 6ulnBDGQ3QAPc3BE1OhCQg44GVtVmEsHko2A+dC3w c=; b=T2lyxWOKaheuKwCz0cyT/SnPcoTTFc0YgkR3OW1DtsFV v4PuzSuGz5QPT3V0dfqAnHNZLziIkUJLSNr9DRpyq2WbqYOysQ oKsHyHyyTQgHSzTiqko7rmBt26EANu3EX9madNtgHJhjkK1YXs /DBuH2btRZSrLnspvlE6BWIrTP4= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 2ca8_90f9_956f700e_f8bc_442c_b8b5_85d0a8f69d5b; Mon, 09 Oct 2017 08:16:31 -0500 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 09:16:26 -0400 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 09:16:25 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Oct 2017 09:16:25 -0400 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 09:16:24 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 9 Oct 2017 13:16:23 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.019; Mon, 9 Oct 2017 13:16:23 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAACVilgAAudXoAAD1YawA== Date: Mon, 9 Oct 2017 13:16:23 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0507C1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <097301d33edf$be7ba640$3b72f2c0$@jpshallow.com> In-Reply-To: <097301d33edf$be7ba640$3b72f2c0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.90.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:GNY6xv0gz+SJymz5DB4Emn3rH+a6JBpZ4q7eVZ+LpkYpMYGliWAh/9kvbIEsbjcv6JT54A67fj7mhGQj7G3sDG5QTwjb92zeonG0uj7zWX5onPO7ZRouXFL5NntLhtDVBpT5/0Xdzx2XqRemv2MX/xByOVKav07r/q8UKCWEDu1AGs5xjN/aACWCgDZqgoSB+xagZOf3rdUfz3PEx+OPJLDXE44rT6phJj8o7Y9kDs72sTfDA2djrb6FcQ1weElIRJwyOQK5U+q5VpJ5vqJi5KT5kTYpxsEWtf0ErfZDqjUYqCYMXPJkVZo20QQ0Wa06KSKQFgV7PHEBuvEJSOGzHQ==; 5:hW7guHLP5uxHlEkksrbBAu8+b9zP3fUQroVbNWKYQZ4MFfbP0OD5HNpFj7gQWqmFsW85bsUx2fP7OWf+hh/jWdwzJq1wtbAnlQ/0W0bOP+BQ7aCidOPFz5V7yUeCBJqZLK/rrSIjaLgNFyq3HhhiYg==; 24:gRHhefTBSRcmb59eniPGGhTEocFXsQXGeB6guESIOYejS+/zY8Y2Ct/UztkKh81g+/MsYt1M14jrrh6MnP7JVOhBFOhquaDWt9S1bjN40q0=; 7:eZ+7+bMAHTnRTXHPqQJLngGeBGsJL0QcbK2cp6fPPmKlDwp/JGXNPf+MDJm//vcjFUH0Pi0tM9HsNFb6d4/j/Ocsd2exA8/HQLtDvSkiff9TwnM4qUVkGrMpnfncB5vqrtbmLrtdDAqFAEqgGSAcoNkUs7HvuV1CFgLiS4Ak+bzOchg/x/OOoC4CCROYA5NZgjYFjB7V5ZxSAkkUqqE3kqtFRzA8U/zwoNGTh2U0df0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 283886c6-75e6-437f-ab62-08d50f17f095 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(79290750141951)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(199003)(377454003)(189002)(24454002)(53754006)(32952001)(25786009)(189998001)(68736007)(77096006)(55016002)(76176999)(2900100001)(101416001)(236005)(54356999)(86362001)(3660700001)(478600001)(6506006)(2201001)(5660300001)(9686003)(33656002)(14454004)(3280700002)(50986999)(229853002)(2501003)(790700001)(110136005)(53936002)(5890100001)(53386004)(7696004)(2950100002)(316002)(74316002)(6306002)(72206003)(54896002)(53946003)(7736002)(99286003)(606006)(2906002)(102836003)(6116002)(3846002)(105586002)(80792005)(53546010)(81166006)(81156014)(106356001)(6246003)(19609705001)(93886005)(8676002)(97736004)(66066001)(6436002)(8936002)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788BC0992A54750205325EDEA740DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2017 13:16:23.5025 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6132> : inlines <6113> : streams <1766506> : uri <2513744> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 13:16:44 -0000 --_000_DM5PR16MB1788BC0992A54750205325EDEA740DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W0pvbl0gQWdyZWVkIHRoYXQgc3VwcG9ydCBmb3IgdGhpcyBhZGRpdGlvbmFsIHBhcmFtZXRlciBp cyByZXF1aXJlZCBhbmQgaXQgbmVlZHMgdG8gYmUgY29udmV5ZWQgYXQgdGhlIENCT1IgLyBSRVNU Q09ORiBsYXllciDigJMgd2hpY2ggSSBpbml0aWFsbHkgc3VnZ2VzdGVkIChiYWRseSkgYXMg4oCc b3JpZ2luYWwtY2xpZW50LWlk4oCdLg0KDQpZZXMsIHdlIGNhbiBhZGQgYW4gb3B0aW9uYWwgYWRk aXRpb25hbCBwYXJhbWV0ZXIgdG8gdGhlIHlhbmcgbW9kZWxzIChtYW5kYXRvcnkgb25seSBmb3Ig dGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheXMgdG8gY29udmV5IHRvIHRoZSBET1RTIHNlcnZl cikuDQoNCi1UaXJ1DQoNCkZyb206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBKb24gU2hhbGxvdw0KU2VudDogU2F0dXJkYXksIE9jdG9iZXIgNywgMjAx NyAxOjQ1IEFNDQpUbzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSBB bGwsDQoNCkNvbW1lbnQgaW5saW5lLg0KDQpSZWdhcmRzDQoNCkpvbg0KDQpGcm9tOiBEb3RzIFtt YWlsdG86IGRvdHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn Pl0gT24gQmVoYWxmIE9mIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpTZW50OiAwNiBPY3RvYmVyIDIwMTcgMTU6NDUNClRv OiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5OyBKb24gU2hhbGxvdzsgJ0RvYmJpbnMsIFJvbGFu ZCc7IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Rv dHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpSZS0sDQoNClBsZWFzZSBzZWUgaW5saW5l Lg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IFttYWls dG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0NCkVudm95w6kgOiB2ZW5kcmVk aSA2IG9jdG9icmUgMjAxNyAxNTo1OA0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBK b24gU2hhbGxvdzsgJ0RvYmJpbnMsIFJvbGFuZCc7IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNA aWV0Zi5vcmc+DQpPYmpldCA6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoN CkkgZG9u4oCZdCBzZWUgYSBuZWVkIGZvciBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgdG8gY29u dmV5IHRoZSDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuDQpb TWVkXSBBZ3JlZS4NCltKb25dIEJ1dCB3ZSBkbyBuZWVkIHRvIHRyYW5zZmVyIHNvbWV0aGluZyBp biB0aGlzIHNlc3Npb24g4oCTIHRoZSB1bmlxdWUgY2xpZW50LWlkIOKAkyBzZWUgYmVsb3cNCg0K DQrigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSBsb29rcyByZXF1aXJlZCBvbmx5IGZvciB0aGUg c2VydmVyLXNpZGUgRE9UUyBnYXRld2F5cy4NCltNZWRdIFllcy4NCg0KSW4gY2FzZSBvZiBzZXJ2 ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IGNhbiBjb252ZXkgdGhlIGNsaWVudC1pZCBnZW5lcmF0 ZWQgZnJvbSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVy LiBUaGUgRE9UUyBnYXRld2F5IGNhbiBnZW5lcmF0ZSBhIHVuaXF1ZSBjbGllbnQtaWQgYW5kIGRv ZXMgbm90IGhhdmUgdG8gc2VuZCBhbiBhcnJheSBvZiBjbGllbnQtaWRzIHRvIHRoZSBET1RTIHNl cnZlciB0byByZXNvbHZlIGNsYXNoZXMuDQpbTWVkXSBXaGF0ZXZlciB0aGUgbWVjaGFuaXNtIHVz ZWQgdG8gZ2VuZXJhdGUgdGhhdCBpZCwgd2Ugd2lsbCBuZWVkIGEgY2hhbm5lbCB0byBjb252ZXkg aXQgdG8gdGhlIHNlcnZlci4gT2J2aW91c2x5LCBpdCBjYW5ub3QgYmUgZXh0cmFjdGVkIGZyb20g dGhlIGlkZW50aXR5IG9mIHRoZSBnYXRld2F5IGl0c2VsZiBiZWNhdXNlIGl0IGFnZ3JlZ2F0ZXMg bWFueSBjbGllbnRzICh0aGF0IGJlbG9uZ3MgdG8gZGlzdGluY3Qgc3Vic2NyaWJlcnMpLiBUaGVy ZSBpcyBhIHJvb20gZm9yIGFuIG9wdGlvbmFsIHBhcmFtZXRlciBmb3IgdGhpcy4NCg0KW0pvbl0g QWdyZWVkIHRoYXQgc3VwcG9ydCBmb3IgdGhpcyBhZGRpdGlvbmFsIHBhcmFtZXRlciBpcyByZXF1 aXJlZCBhbmQgaXQgbmVlZHMgdG8gYmUgY29udmV5ZWQgYXQgdGhlIENCT1IgLyBSRVNUQ09ORiBs YXllciDigJMgd2hpY2ggSSBpbml0aWFsbHkgc3VnZ2VzdGVkIChiYWRseSkgYXMg4oCcb3JpZ2lu YWwtY2xpZW50LWlk4oCdLg0KDQotVGlydQ0KDQpGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NClNlbnQ6IEZyaWRheSwgT2N0b2Jl ciA2LCAyMDE3IDE6MDcgUE0NClRvOiBKb24gU2hhbGxvdyA8c3VwanBzLWlldGZAanBzaGFsbG93 LmNvbTxtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbT4+OyAnRG9iYmlucywgUm9sYW5k JyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+PjsgZG90c0Bp ZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBH YXRld2F5cyBDaGFsbGVuZ2VzDQoNClJlLSwNCg0KSSBkaXNhZ3JlZSB3aXRoIHRoZSBmb2xsb3dp bmcgOg0KDQogICAgICAgICAgICAgICAgdHlwZSBzdHJpbmc7DQogICAgICAgICAgICAgICAgZGVz Y3JpcHRpb24gIk9yaWdpbmFsIENsaWVudCBJRCByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uLCBS RVFVSVJFRCBhbmQgYWRkZWQgd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdhdGV3YXkuIjsN CiAgICAgICAgICAgICB9DQoNCkEgZ2F0ZXdheSBtYXkgYmUgaW5zdHJ1Y3RlZCB0aGUgcmV2ZWFs IHRoZSBvcmlnaW5hbCBjbGllbnQgaWRlbnRpdHkgb25seSBpbiBzb21lIGRlcGxveW1lbnRzIChu b3QgYWxsKTsgb3RoZXJ3aXNlIGl0IGlzIHRoZSBnYXRld2F5IGlkZW50aWZ5IHRoYXQgaXMgdXNl ZCBieSB0aGUgcmVtb3RlIHNlcnZlci4gVGhlIGdhdGV3YXkgaWRlbnRpdHkgaXMgZXh0cmFjdGVk IGZyb20gdGhlIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzLg0KDQpBIGNvbmZpZ3VyYWJsZSBw YXJhbWV0ZXIgdG8gZW5hYmxlL2Rpc2FibGUgdGhhdCB0aGUgb3JpZ2luYWwgY2xpZW50IGlkZW50 aXR5IGlzIHBhc3NlZCwgbWF5IGJlIGNvbnNpZGVyZWQgKGRpc2FibGVkIGJ5IGRlZmF1bHQsIElN TykuIFRoZSBvcmlnaW5hbCBjbGllbnQgaWRlbnRpdHkgaXMgdGhlcmVmb3JlIG9wdGlvbmFsLCBu b3QgbWFuZGF0b3J5Lg0KDQpCVFcsIGl0IG1heSBiZSB3b3J0aCB0byBjb25zaWRlciBhIGRlZGlj YXRlZCBZQU5HIG1vZHVsZSBmb3IgRE9UUyBnYXRld2F5cy4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRl IDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKb24g U2hhbGxvdw0KRW52b3nDqSA6IGpldWRpIDUgb2N0b2JyZSAyMDE3IDEzOjM1DQrDgCA6ICdEb2Ji aW5zLCBSb2xhbmQnOyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KT2JqZXQg OiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpBcyB0aGUgdXNlIG9mIOKA nG9yaWdpbmFsLWNsaWVudC1pZOKAnSBpcyBhICptdXN0KiwgdGhlbiBJIHByb3Bvc2UgdGhlIGZv bGxvd2luZyBjaGFuZ2VzLiAgSXQgaXMgZGVmaW5lZCBhcyBhbiBhcnJheSBzaG91bGQgdGhlcmUg YmUgYSBjbGllbnQtaWQgbmFtZSBjbGFzaCBhbmQgYSBzZWNvbmQgKG9yIG1vcmUpIGVudHJ5IG5l ZWRzIHRvIGJlIGFkZGVkIGJ5IGEgRE9UUyBHYXRld2F5IGluIGEgbG9uZyBjaGFpbi4gIEluIG5v cm1hbCB1c2UsIGl0IGlzIGV4cGVjdGVkIHRoYXQgdGhlcmUgd2lsbCBvbmx5IGJlIG9uZSBlbnRy eSwgZXZlbiB0aG91Z2ggc2V2ZXJhbCBET1RTIEdhdGV3YXlzIGhhdmUgYmVlbiBwYXNzZWQgdGhy b3VnaC4NCg0KVGhlIGZvbGxvd2luZyBZQU5HIGNoYW5nZXMgbmVlZCB0byBiZSBtYWRlIHRvIHRo ZSBzaWduYWwgc3BlYyBhbmQgYXNzb2NpYXRlZCByZWZlcmVuY2VzIHVwZGF0ZWQNCg0KICAgVGhp cyBkb2N1bWVudCBkZWZpbmVzIHRoZSBZQU5HIG1vZHVsZSAiaWV0Zi1kb3RzLXNpZ25hbCIsIHdo aWNoIGhhcw0KICAgdGhlIGZvbGxvd2luZyB0cmVlIHN0cnVjdHVyZToNCg0KICAgbW9kdWxlOiBp ZXRmLWRvdHMtc2lnbmFsDQogICAgICAgKy0tcncgbWl0aWdhdGlvbi1zY29wZQ0KICAgICAgICAg ICstLXJ3IHNjb3BlKiBbbWl0aWdhdGlvbi1pZF0NCiAgICAgICAgICAgICArLS1ydyBtaXRpZ2F0 aW9uLWlkICAgICAgICAgaW50MzINCiAgICAgICAgICAgICArLS1ydyBvcmlnaW5hbC1jbGllbnQt aWQqICAgc3RyaW5nDQogICAgICAgICAgICAgKy0tcncgdGFyZ2V0LWlwKiAgICAgICAgICAgIGlu ZXQ6aXAtYWRkcmVzcw0KICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wcmVmaXgqICAgICAgICBp bmV0OmlwLXByZWZpeA0KICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wb3J0LXJhbmdlKiBbbG93 ZXItcG9ydCB1cHBlci1wb3J0XQ0KICAgICAgICAgICAgIHwgICstLXJ3IGxvd2VyLXBvcnQgICAg aW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgIHwgICstLXJ3IHVwcGVyLXBvcnQgICAgaW5l dDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wcm90b2NvbCogICAgICB1 aW50OA0KICAgICAgICAgICAgICstLXJ3IGZxZG4qICAgICAgICAgICAgICAgICBpbmV0OmRvbWFp bi1uYW1lDQogICAgICAgICAgICAgKy0tcncgdXJpKiAgICAgICAgICAgICAgICAgIGluZXQ6dXJp DQogICAgICAgICAgICAgKy0tcncgYWxpYXMtbmFtZSogICAgICAgICAgIHN0cmluZw0KICAgICAg ICAgICAgICstLXJ3IGxpZmV0aW1lPyAgICAgICAgICAgICBpbnQzMg0KDQotLS0tDQogICAgIGNv bnRhaW5lciBtaXRpZ2F0aW9uLXNjb3BlIHsNCiAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAg ICAgICAgICJUb3AgbGV2ZWwgY29udGFpbmVyIGZvciBhIG1pdGlnYXRpb24gcmVxdWVzdC4iOw0K DQogICAgICAgICAgbGlzdCBzY29wZSB7DQogICAgICAgICAgICAga2V5IG1pdGlnYXRpb24taWQ7 DQogICAgICAgICAgICAgZGVzY3JpcHRpb24gIklkZW50aWZpZXIgZm9yIHRoZSBtaXRpZ2F0aW9u IHJlcXVlc3QuIjsNCiAgICAgICAgICAgICBsZWFmIG1pdGlnYXRpb24taWQgew0KICAgICAgICAg ICAgICAgIHR5cGUgaW50MzI7DQogICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIk1pdGlnYXRp b24gcmVxdWVzdCBpZGVudGlmaWVyLiI7DQogICAgICAgICAgICAgfQ0KICAgICAgICAgICAgIGxp c3Qgb3JpZ2luYWwtY2xpZW50LWlkIHsNCiAgICAgICAgICAgICAgICB0eXBlIHN0cmluZzsNCiAg ICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiT3JpZ2luYWwgQ2xpZW50IElEIHJlcXVlc3Rpbmcg dGhlIG1pdGlnYXRpb24sIFJFUVVJUkVEIGFuZCBhZGRlZCB3aGVuIHBhc3NpbmcgdGhyb3VnaCBh IERPVFMgR2F0ZXdheS4iOw0KICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICBsZWFmLWxpc3Qg dGFyZ2V0LWlwIHsNCiAgICAgICAgICAgICAgICB0eXBlIGluZXQ6aXAtYWRkcmVzczsNCiAgICAg ICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICAgICJJUHY0IG9yIElQdjYg YWRkcmVzcyBpZGVudGlmeWluZyB0aGUgdGFyZ2V0LiI7DQogICAgICAgICAgICAgfQ0KLS0tLQ0K ICAgICAgIHNpZ25hbC1jb25maWcNCiAgICAgICAgICArLS1ydyBzZXNzaW9uLWlkPyAgICAgICAg ICAgaW50MzINCiAgICAgICAgICArLS1ydyBvcmlnaW5hbC1jbGllbnQtaWQqICAgc3RyaW5nDQog ICAgICAgICAgKy0tcncgaGVhcnRiZWF0LWludGVydmFsPyAgIGludDE2DQogICAgICAgICAgKy0t cncgbWlzc2luZy1oYi1hbGxvd2VkPyAgIGludDE2DQogICAgICAgICAgKy0tcncgbWF4LXJldHJh bnNtaXQ/ICAgICAgIGludDE2DQogICAgICAgICAgKy0tcncgYWNrLXRpbWVvdXQ/ICAgICAgICAg IGludDE2DQogICAgICAgICAgKy0tcncgYWNrLXJhbmRvbS1mYWN0b3I/ICAgIGRlY2ltYWw2NA0K ICAgICAgICAgICstLXJ3IHRyaWdnZXItbWl0aWdhdGlvbj8gICBCb29sZWFuDQotLS0NCiAgICAg Y29udGFpbmVyIHNpZ25hbC1jb25maWcgew0KICAgICAgICAgIGRlc2NyaXB0aW9uICJUb3AgbGV2 ZWwgY29udGFpbmVyIGZvciBET1RTIHNpZ25hbCBjaGFubmVsIHNlc3Npb24NCiAgICAgICAgICAg ICAgICAgICAgICAgY29uZmlndXJhdGlvbi4iOw0KDQogICAgICAgICAgbGVhZiBzZXNzaW9uLWlk IHsNCiAgICAgICAgICAgICAgdHlwZSBpbnQzMjsNCiAgICAgICAgICAgICAgZGVzY3JpcHRpb24g IkFuIGlkZW50aWZpZXIgZm9yIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICBzZXNzaW9uIGNvbmZpZ3VyYXRpb24gZGF0YS4iOw0KICAgICAgICAgIH0N CiAgICAgICAgICBsaXN0IG9yaWdpbmFsLWNsaWVudC1pZCB7DQogICAgICAgICAgICAgIHR5cGUg c3RyaW5nOw0KICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiT3JpZ2luYWwgQ2xpZW50IElEIHJl cXVlc3RpbmcgdGhlIG1pdGlnYXRpb24sIFJFUVVJUkVEIGFuZCBhZGRlZCB3aGVuIHBhc3Npbmcg dGhyb3VnaCBhIERPVFMgR2F0ZXdheS4iOw0KICAgICAgICAgIH0NCg0KICAgICAgICAgIGxlYWYg aGVhcnRiZWF0LWludGVydmFsIHsNCg0KLS0tDQpUaGUgZm9sbG93aW5nIFlBTkcgY2hhbmdlcyBu ZWVkIHRvIGJlIG1hZGUgdG8gdGhlIGRhdGEgc3BlYyBhbmQgYXNzb2NpYXRlZCByZWZlcmVuY2Vz IHVwZGF0ZWQNCg0KICAgbW9kdWxlOiBpZXRmLWRvdHMtZGF0YS1jaGFubmVsLWlkZW50aWZpZXIN CiAgICAgICArLS1ydyBpZGVudGlmaWVyDQogICAgICAgICAgKy0tcncgYWxpYXMqIFthbGlhcy1u YW1lXQ0KICAgICAgICAgICAgICstLXJ3IGFsaWFzLW5hbWUgICAgICAgICAgIHN0cmluZw0KICAg ICAgICAgICAgICstLXJ3IG9yaWdpbmFsLWNsaWVudC1pZCogIHN0cmluZw0KICAgICAgICAgICAg ICstLXJ3IHRhcmdldC1pcCogICAgICAgICAgIGluZXQ6aXAtYWRkcmVzcw0KICAgICAgICAgICAg ICstLXJ3IHRhcmdldC1wcmVmaXgqICAgICAgIGluZXQ6aXAtcHJlZml4DQogICAgICAgICAgICAg Ky0tcncgdGFyZ2V0LXBvcnQtcmFuZ2UqIFtsb3dlci1wb3J0IHVwcGVyLXBvcnRdDQogICAgICAg ICAgICAgfCAgKy0tcncgbG93ZXItcG9ydCAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAg ICAgfCAgKy0tcncgdXBwZXItcG9ydCAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAgICAg Ky0tcncgdGFyZ2V0LXByb3RvY29sKiAgICAgdWludDgNCiAgICAgICAgICAgICArLS1ydyBmcWRu KiAgICAgICAgICAgICAgICBpbmV0OmRvbWFpbi1uYW1lDQogICAgICAgICAgICAgKy0tcncgdXJp Kg0KLS0tDQogICAgIGNvbnRhaW5lciBpZGVudGlmaWVyIHsNCiAgICAgICAgICBkZXNjcmlwdGlv biAidG9wIGxldmVsIGNvbnRhaW5lciBmb3IgaWRlbnRpZmllcnMiOw0KICAgICAgICAgICAgICBs aXN0IGFsaWFzIHsNCiAgICAgICAgICAgICAgICAgICBrZXkgYWxpYXMtbmFtZTsNCiAgICAgICAg ICAgICAgICAgICBkZXNjcmlwdGlvbiAibGlzdCBvZiBpZGVudGlmaWVycyI7DQogICAgICAgICAg ICAgICAgICAgbGVhZiBhbGlhcy1uYW1lIHsNCiAgICAgICAgICAgICAgICAgICAgICB0eXBlIHN0 cmluZzsNCiAgICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiYWxpYXMgbmFtZSI7DQog ICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgIGxpc3Qgb3JpZ2luYWwtY2xp ZW50LWlkIHsNCiAgICAgICAgICAgICAgICAgICAgICAgdHlwZSBzdHJpbmc7DQogICAgICAgICAg ICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJPcmlnaW5hbCBDbGllbnQgSUQgcmVxdWVzdGluZyB0 aGUgbWl0aWdhdGlvbiwgUkVRVUlSRUQgYW5kIGFkZGVkIHdoZW4gcGFzc2luZyB0aHJvdWdoIGEg RE9UUyBHYXRld2F5LiI7DQogICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAg IGxlYWYtbGlzdCB0YXJnZXQtaXAgew0KLS0tDQpUaGUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0 OmFjY2Vzcy1saXN0cyBpcyBtb3JlIGNvbXBsaWNhdGVkLiAgV2l0aCB0aGUgaW50cm9kdWN0aW9u IG9mIOKAmGNvbnRhaW5lciBpbnRlcmZhY2Vz4oCZIGluIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1t b2RlbC0xNCB0aGUgdGV4dCBpbiBnZW5lcmFsIGluIGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5u ZWwgbmVlZHMgdXBkYXRpbmcuICBUaGlzIGNoYW5nZSBpbiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wt bW9kZWwtMTQgZ2l2ZXMgdXMgdGhlIGFiaWxpdHkgdG8gYXR0YWNoIGEgc3BlY2lmaWMgc2V0IG9m IHNvcnRlZCBBQ0xzIHRvIGFuIGludGVyZmFjZSwgYnV0IHN0aWxsIGRvZXMgbm90IGVhc2lseSBh c3NvY2lhdGUgYSBzZXQgb2YgQUNMIGRlZmluaXRpb25zIHdpdGggYSBwYXJ0aWN1bGFyIGNsaWVu dC4NCg0KTXkgc3VnZ2VzdGlvbiBpcyB0aGF0IHdlIGFkZCBpbiBhbiBhZGRpdGlvbmFsIEpTT04g ZW50cnkgYXMgZm9sbG93cywgd2l0aCB0aGUgWUFORyBtb2R1bGUgbW9kdWxlIGlldGYtZG90cy1h Y2Nlc3MtY29udHJvbC1saXN0IHVwZGF0ZWQgKG15IFlBTkcgaXMgbm90IGN1cnJlbnRseSB1cCB0 byBkb2luZyB0aGF0KSB0aGF0IGRlZmluZXMgd2hhdCB3ZSBhcmUgZG9pbmcuDQoNCiAgUE9TVCAv cmVzdGNvbmYvZGF0YS9pZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QgSFRUUC8xLjENCiAgSG9zdDog d3d3LmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuZXhhbXBsZS5jb20+DQogIENvbnRlbnQtRm9ybWF0 OiAiYXBwbGljYXRpb24veWFuZy5hcGkranNvbiINCiAgew0KICAgIm9yaWdpbmFsLWNsaWVudC1p ZCIgOiBbInN0cmluZyIgXSwNCiAgICJpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Q6YWNjZXNzLWxp c3RzIjogew0KICAgICAgImFjbCI6IFsNCg0KW0FuZCBzaG91bGQgbm90IHdlIGJlIHBvc3Rpbmcg dG8gL3Jlc3Rjb25mL2RhdGEvaWV0Zi1kb3RzLWFjY2Vzcy1jb250cm9sLWxpc3QgYW55d2F5P10N Cg0KUmVnYXJkcw0KDQpKb24NCkZyb206IERvdHMgW21haWx0bzogZG90cy1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRG9iYmlucywg Um9sYW5kDQpTZW50OiAwNSBPY3RvYmVyIDIwMTcgMTA6NDINClRvOiBkb3RzQGlldGYub3JnPG1h aWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENo YWxsZW5nZXMNCg0KDQoNCk9uIE9jdCA1LCAyMDE3LCBhdCAxNDo1OCwgSm9uIFNoYWxsb3cgPHN1 cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20+ PiB3cm90ZToNClBlcmhhcHMgIm9yaWdpbmFsLWNsaWVudC1pZCIgd291bGQgYmUgYSBiZXR0ZXIg bmFtZSAtIGluIGEgc2ltaWxhciBzb3J0IG9mIHdheSB0aGF0IHRoZSAiWC1Gb3J3YXJkaW5nLUZv cjoiIGhlYWRlciBwcm92aWRlcyB0aGUgb3JpZ2luYWwgSVAgbWFraW5nIHRoZSBIVFRQIHJlcXVl c3Qgd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBsb2FkLWJhbGFuY2VyIG9yIFNTTCB0ZXJtaW5hdG9y Lg0KDQpUaGlzIGlzIGhvdyBpdCAqbXVzdCogd29yaywgYWdyZWVkOyBJIHJlbWVtYmVyIGRpc2N1 c3NpbmcgdGhpcyB0b3BpYyBhdCBvbmUgb2YgdGhlIFdHIG1lZXRpbmdzLCBzcGVjaWZpY2FsbHku DQoNCklmIGl0IHNvbWVob3cgd2FzIGRyb3BwZWQsIHdlIG5lZWQgdG8gZml4IGl0LiAgR2F0ZXdh eXMgYXJlIGEgbmVjZXNzYXJ5IGluaXRpYWwgY2FwYWJpbGl0eSwgYXMgaXMgcHJlc2VydmluZyBE T1RTIGNsaWVudCBJRHMgYWNyb3NzIHRoZW0uDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9i Ymluc0BhcmJvci5uZXQ+Pg0K --_000_DM5PR16MB1788BC0992A54750205325EDEA740DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIg MiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlNlZ29lIFVJIixzYW5zLXNl cmlmO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUg YnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJU ZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0KcC5U ZXh0ZWRlYnVsbGVzLCBsaS5UZXh0ZWRlYnVsbGVzLCBkaXYuVGV4dGVkZWJ1bGxlcw0KCXttc28t c3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIjsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUg YnVsbGVzIENhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls ZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9y bWFsO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9u dC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0pvbl0gQWdyZWVkIHRo YXQgc3VwcG9ydCBmb3IgdGhpcyBhZGRpdGlvbmFsIHBhcmFtZXRlciBpcyByZXF1aXJlZCBhbmQg aXQgbmVlZHMgdG8gYmUgY29udmV5ZWQgYXQgdGhlIENCT1IgLyBSRVNUQ09ORiBsYXllciDigJMg d2hpY2ggSSBpbml0aWFsbHkgc3VnZ2VzdGVkIChiYWRseSkNCiBhcyDigJxvcmlnaW5hbC1jbGll bnQtaWTigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlllcywgd2UgY2FuIGFkZCBhbiBvcHRpb25hbCBhZGRp dGlvbmFsIHBhcmFtZXRlciB0byB0aGUgeWFuZyBtb2RlbHMgKG1hbmRhdG9yeSBvbmx5IGZvciB0 aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5cyB0byBjb252ZXkgdG8gdGhlIERPVFMgc2VydmVy KS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4tVGlydTxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PG86cD48 L286cD48L2E+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls RW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBEb3RzIFs8YSBocmVmPSJt YWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9uIFNoYWxsb3c8YnI+DQo8Yj5TZW50OjwvYj4g U2F0dXJkYXksIE9jdG9iZXIgNywgMjAxNyAxOjQ1IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENo YWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFsbCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Q29tbWVudCBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IERv dHMgW21haWx0bzoNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZiI+ZG90cy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZiI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5tb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGI+U2VudDo8 L2I+IDA2IE9jdG9iZXIgMjAxNyAxNTo0NTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxl c3dhciBSZWRkeTsgSm9uIFNoYWxsb3c7ICdEb2JiaW5zLCBSb2xhbmQnOyA8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5kb3RzQGlldGYub3JnPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10g RE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+UmUtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNlIHNlZSBpbmxpbmUuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBLb25kYSwg VGlydW1hbGVzd2FyIFJlZGR5IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJl ZGR5X0tvbmRhQE1jQWZlZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5tYWlsdG86VGlydW1hbGVzd2Fy UmVkZHlfS29uZGFATWNBZmVlLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4N CjxiPkVudm95w6kmbmJzcDs6PC9iPiB2ZW5kcmVkaSA2IG9jdG9icmUgMjAxNyAxNTo1ODxicj4N CjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgSm9uIFNoYWxsb3c7 ICdEb2JiaW5zLCBSb2xhbmQnOyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmIj5kb3RzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+ PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxl bmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+SSBkb27igJl0IHNlZSBhIG5lZWQgZm9yIGNsaWVudC1zaWRlIERPVFMgZ2F0 ZXdheSB0byBjb252ZXkgdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RT IHNlcnZlci4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVk XSBBZ3JlZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PltKb25dIEJ1dCB3ZSBkbyBuZWVkIHRvIHRyYW5zZmVyIHNvbWV0aGluZyBpbiB0aGlzIHNlc3Np b24g4oCTIHRoZSB1bmlxdWUgY2xpZW50LWlkIOKAkyBzZWUgYmVsb3c8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gbG9va3MgcmVx dWlyZWQgb25seSBmb3IgdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheXMuPHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFllcy4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5 IHRoZSBjbGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR5 4oCdIHRvIHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1 bmlxdWUgY2xpZW50LWlkDQogYW5kIGRvZXMgbm90IGhhdmUgdG8gc2VuZCBhbiBhcnJheSBvZiBj bGllbnQtaWRzIHRvIHRoZSBET1RTIHNlcnZlciB0byByZXNvbHZlIGNsYXNoZXMuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+W01lZF0gV2hhdGV2ZXIgdGhlIG1lY2hhbmlzbSB1c2VkIHRvIGdlbmVyYXRlIHRoYXQgaWQs IHdlIHdpbGwgbmVlZCBhIGNoYW5uZWwgdG8gY29udmV5IGl0IHRvIHRoZSBzZXJ2ZXIuIE9idmlv dXNseSwgaXQgY2Fubm90IGJlIGV4dHJhY3RlZCBmcm9tIHRoZSBpZGVudGl0eSBvZiB0aGUgZ2F0 ZXdheQ0KIGl0c2VsZiBiZWNhdXNlIGl0IGFnZ3JlZ2F0ZXMgbWFueSBjbGllbnRzICh0aGF0IGJl bG9uZ3MgdG8gZGlzdGluY3Qgc3Vic2NyaWJlcnMpLiBUaGVyZSBpcyBhIHJvb20gZm9yIGFuIG9w dGlvbmFsIHBhcmFtZXRlciBmb3IgdGhpcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+W0pvbl0gQWdyZWVkIHRoYXQgc3VwcG9ydCBmb3IgdGhpcyBhZGRpdGlvbmFsIHBhcmFt ZXRlciBpcyByZXF1aXJlZCBhbmQgaXQgbmVlZHMgdG8gYmUgY29udmV5ZWQgYXQgdGhlIENCT1Ig LyBSRVNUQ09ORiBsYXllciDigJMgd2hpY2ggSSBpbml0aWFsbHkgc3VnZ2VzdGVkIChiYWRseSkN CiBhcyDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gRG90cyBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPjwvc3Bhbj48YSBocmVmPSJt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4N CjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgNiwgMjAxNyAxOjA3IFBNPGJyPg0KPGI+VG86 PC9iPiBKb24gU2hhbGxvdyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsgJ0RvYmJpbnMsIFJvbGFuZCcNCiAmbHQ7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+cmRvYmJpbnNAYXJib3IubmV0PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7DQo8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ZG90 c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UmUtLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+SSBkaXNhZ3JlZSB3aXRoIHRoZSBmb2xsb3dpbmcmbmJz cDs6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgc3RyaW5nOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtPcmln aW5hbCBDbGllbnQgSUQgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbiwgUkVRVUlSRUQgYW5kIGFk ZGVkIHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHYXRld2F5LiZxdW90Ozs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ QSBnYXRld2F5IG1heSBiZSBpbnN0cnVjdGVkIHRoZSByZXZlYWwgdGhlIG9yaWdpbmFsIGNsaWVu dCBpZGVudGl0eSBvbmx5IGluIHNvbWUgZGVwbG95bWVudHMgKG5vdCBhbGwpOyBvdGhlcndpc2Ug aXQgaXMgdGhlIGdhdGV3YXkgaWRlbnRpZnkgdGhhdCBpcyB1c2VkIGJ5IHRoZSByZW1vdGUNCiBz ZXJ2ZXIuIFRoZSBnYXRld2F5IGlkZW50aXR5IGlzIGV4dHJhY3RlZCBmcm9tIHRoZSBhdXRoZW50 aWNhdGlvbiBjcmVkZW50aWFscy4gPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkEgY29uZmln dXJhYmxlIHBhcmFtZXRlciB0byBlbmFibGUvZGlzYWJsZSB0aGF0IHRoZSBvcmlnaW5hbCBjbGll bnQgaWRlbnRpdHkgaXMgcGFzc2VkLCBtYXkgYmUgY29uc2lkZXJlZCAoZGlzYWJsZWQgYnkgZGVm YXVsdCwgSU1PKS4gVGhlIG9yaWdpbmFsIGNsaWVudCBpZGVudGl0eSBpcyB0aGVyZWZvcmUNCiBv cHRpb25hbCwgbm90IG1hbmRhdG9yeS4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5CVFcsIGl0IG1heSBiZSB3b3J0aCB0byBjb25zaWRlciBhIGRlZGljYXRlZCBZQU5HIG1v ZHVsZSBmb3IgRE9UUyBnYXRld2F5cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmIj4gRG90cyBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0 Zi5vcmciPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRm Lm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5dDQo8Yj5EZSBsYSBwYXJ0 IGRlPC9iPiBKb24gU2hhbGxvdzxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSA1IG9j dG9icmUgMjAxNyAxMzozNTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gJ0RvYmJpbnMsIFJvbGFuZCc7 IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmIj5kb3RzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYi Pjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxs ZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+QXMgdGhlIHVzZSBvZiDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0gaXMgYSAqPGI+bXVz dDwvYj4qLCB0aGVuIEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIGNoYW5nZXMuJm5ic3A7IEl0IGlz IGRlZmluZWQgYXMgYW4gYXJyYXkgc2hvdWxkIHRoZXJlIGJlIGEgY2xpZW50LWlkDQogbmFtZSBj bGFzaCBhbmQgYSBzZWNvbmQgKG9yIG1vcmUpIGVudHJ5IG5lZWRzIHRvIGJlIGFkZGVkIGJ5IGEg RE9UUyBHYXRld2F5IGluIGEgbG9uZyBjaGFpbi4mbmJzcDsgSW4gbm9ybWFsIHVzZSwgaXQgaXMg ZXhwZWN0ZWQgdGhhdCB0aGVyZSB3aWxsIG9ubHkgYmUgb25lIGVudHJ5LCBldmVuIHRob3VnaCBz ZXZlcmFsIERPVFMgR2F0ZXdheXMgaGF2ZSBiZWVuIHBhc3NlZCB0aHJvdWdoLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5UaGUgZm9sbG93aW5nIFlBTkcgY2hhbmdlcyBuZWVkIHRvIGJlIG1hZGUgdG8gdGhlIHNpZ25h bCBzcGVjIGFuZCBhc3NvY2lhdGVkIHJlZmVyZW5jZXMgdXBkYXRlZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgWUFORyBtb2R1bGUgJnF1b3Q7aWV0Zi1kb3RzLXNp Z25hbCZxdW90Oywgd2hpY2ggaGFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IHRoZSBmb2xsb3dpbmcgdHJlZSBzdHJ1Y3R1cmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG1vZHVsZTogaWV0Zi1kb3Rz LXNpZ25hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tcncgbWl0aWdhdGlvbi1zY29wZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmIzQzOy0tcncgc2NvcGUqIFttaXRpZ2F0aW9uLWlkXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbWl0aWdhdGlvbi1pZCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQzMjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgb3JpZ2luYWwtY2xpZW50LWlkKiZuYnNwOyZu YnNwOyBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst LXJ3IHRhcmdldC1pcCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDppcC1hZGRyZXNzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyB0YXJnZXQtcHJlZml4KiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmV0OmlwLXByZWZpeDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+JiM0MzstLXJ3IHRhcmdldC1wb3J0LXJhbmdlKiBbbG93ZXItcG9ydCB1cHBl ci1wb3J0XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7 LS1ydyBsb3dlci1wb3J0Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6cG9ydC1udW1iZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgdXBwZXItcG9y dCZuYnNwOyZuYnNwOyZuYnNwOyBpbmV0OnBvcnQtbnVtYmVyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+JiM0MzstLXJ3IHRhcmdldC1wcm90b2NvbCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3 IGZxZG4qJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6ZG9tYWlu LW5hbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHVy aSombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDp1cmk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGFsaWFzLW5h bWUqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHN0cmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0tcncgbGlmZXRpbWU/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludDMyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0tLS08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIG1p dGlnYXRpb24tc2NvcGUgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtUb3AgbGV2ZWwgY29udGFpbmVy IGZvciBhIG1pdGlnYXRpb24gcmVxdWVzdC4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpc3Qgc2NvcGUgezxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBrZXkgbWl0aWdhdGlvbi1pZDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7SWRlbnRpZmllciBmb3Ig dGhlIG1pdGlnYXRpb24gcmVxdWVzdC4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGxlYWYgbWl0aWdhdGlvbi1pZCB7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgaW50MzI7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZGVzY3JpcHRpb24gJnF1b3Q7TWl0aWdhdGlv biByZXF1ZXN0IGlkZW50aWZpZXIuJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpc3Qgb3JpZ2lu YWwtY2xpZW50LWlkIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj50 eXBlIHN0cmluZzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7T3JpZ2luYWwgQ2xpZW50IElEIHJlcXVlc3Rp bmcgdGhlIG1pdGlnYXRpb24sIFJFUVVJUkVEIGFuZCBhZGRlZCB3aGVuIHBhc3NpbmcgdGhyb3Vn aCBhIERPVFMgR2F0ZXdheS4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZi1saXN0 IHRhcmdldC1pcCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHR5cGUgaW5ldDppcC1hZGRyZXNzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDtJUHY0IG9yIElQdjYgYWRkcmVzcyBpZGVudGlmeWluZyB0aGUgdGFyZ2V0 LiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaWduYWwtY29uZmlnPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICYjNDM7LS1ydyBzZXNzaW9uLWlkPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQzMjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmIzQzOy0tcncgb3JpZ2luYWwtY2xpZW50LWlkKiZuYnNwOyZuYnNwOyBzdHJpbmcmbmJz cDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1ydyBoZWFydGJlYXQtaW50ZXJ2 YWw/Jm5ic3A7Jm5ic3A7IGludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBtaXNz aW5nLWhiLWFsbG93ZWQ/Jm5ic3A7Jm5ic3A7IGludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7LS1ydyBtYXgtcmV0cmFuc21pdD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgaW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGFjay10aW1lb3V0PyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQxNjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWNrLXJhbmRvbS1mYWN0b3I/Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRlY2ltYWw2NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdHJpZ2dl ci1taXRpZ2F0aW9uPyZuYnNwOyZuYnNwOyBCb29sZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgY29udGFpbmVyIHNpZ25hbC1jb25maWcgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlw dGlvbiAmcXVvdDtUb3AgbGV2ZWwgY29udGFpbmVyIGZvciBET1RTIHNpZ25hbCBjaGFubmVsIHNl c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uZmlndXJh dGlvbi4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGxlYWYgc2Vzc2lvbi1pZCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHR5cGUgaW50MzI7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9uICZxdW90O0FuIGlkZW50aWZpZXIgZm9yIHRoZSBET1RT IHNpZ25hbCBjaGFubmVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlc3Npb24gY29uZmlndXJhdGlvbiBkYXRhLiZxdW90 Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfSZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7bGlzdCBvcmlnaW5hbC1jbGllbnQtaWQgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB0eXBlIHN0cmluZzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7T3JpZ2luYWwgQ2xpZW50IElEIHJl cXVlc3RpbmcgdGhlIG1pdGlnYXRpb24sIFJFUVVJUkVEIGFuZCBhZGRlZCB3aGVuIHBhc3Npbmcg dGhyb3VnaCBhIERPVFMgR2F0ZXdheS4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBoZWFy dGJlYXQtaW50ZXJ2YWwgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlRoZSBmb2xsb3dpbmcgWUFORyBjaGFuZ2VzIG5lZWQgdG8gYmUgbWFkZSB0byB0aGUg ZGF0YSBzcGVjIGFuZCBhc3NvY2lhdGVkIHJlZmVyZW5jZXMgdXBkYXRlZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBtb2R1 bGU6IGlldGYtZG90cy1kYXRhLWNoYW5uZWwtaWRlbnRpZmllcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgaWRlbnRp ZmllcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWxpYXMqIFthbGlhcy1uYW1lXTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWxpYXMtbmFt ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst LXJ3IG9yaWdpbmFsLWNsaWVudC1pZCombmJzcDsgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyB0YXJnZXQtaXAqJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6aXAtYWRkcmVz czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdGFyZ2V0 LXByZWZpeCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDppcC1wcmVm aXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzOy0tcncgdGFyZ2V0LXBvcnQtcmFuZ2UqIFts b3dlci1wb3J0IHVwcGVyLXBvcnRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsgJiM0MzstLXJ3IGxvd2VyLXBvcnQmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDpwb3J0 LW51bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7 LS1ydyB1cHBlci1wb3J0Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6cG9ydC1udW1iZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj4mIzQzOy0tcncgdGFyZ2V0LXByb3RvY29sKiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm IzQzOy0tcncgZnFkbiombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDpkb21h aW4tbmFtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncg dXJpKjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS0tPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnRhaW5lciBpZGVudGlmaWVyIHs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7dG9wIGxldmVsIGNvbnRhaW5lciBm b3IgaWRlbnRpZmllcnMmcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGxpc3QgYWxpYXMgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBrZXkgYWxpYXMtbmFtZTs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7bGlzdCBvZiBpZGVudGlmaWVycyZx dW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBhbGlhcy1uYW1lIHs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBzdHJpbmc7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uICZxdW90O2FsaWFzIG5hbWUmcXVvdDs7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGlzdCBvcmlnaW5hbC1jbGllbnQtaWQgezxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIHN0cmluZzs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7 T3JpZ2luYWwgQ2xpZW50IElEIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24sIFJFUVVJUkVEIGFu ZCBhZGRlZCB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR2F0ZXdheS4mcXVvdDs7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZi1saXN0IHRhcmdldC1pcCB7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlRoZSBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Q6YWNjZXNzLWxpc3RzIGlzIG1vcmUg Y29tcGxpY2F0ZWQuJm5ic3A7IFdpdGggdGhlIGludHJvZHVjdGlvbiBvZiDigJhjb250YWluZXIg aW50ZXJmYWNlc+KAmSBpbiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTQNCiB0aGUgdGV4 dCBpbiBnZW5lcmFsIGluIGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwgbmVlZHMgdXBkYXRp bmcuJm5ic3A7IFRoaXMgY2hhbmdlIGluIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xNCBn aXZlcyB1cyB0aGUgYWJpbGl0eSB0byBhdHRhY2ggYSBzcGVjaWZpYyBzZXQgb2Ygc29ydGVkIEFD THMgdG8gYW4gaW50ZXJmYWNlLCBidXQgc3RpbGwgZG9lcyBub3QgZWFzaWx5IGFzc29jaWF0ZSBh IHNldCBvZiBBQ0wgZGVmaW5pdGlvbnMgd2l0aA0KIGEgcGFydGljdWxhciBjbGllbnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPk15IHN1Z2dlc3Rpb24gaXMgdGhhdCB3ZSBhZGQgaW4gYW4gYWRkaXRpb25hbCBKU09O IGVudHJ5IGFzIGZvbGxvd3MsIHdpdGggdGhlIFlBTkcgbW9kdWxlIG1vZHVsZSBpZXRmLWRvdHMt YWNjZXNzLWNvbnRyb2wtbGlzdCB1cGRhdGVkIChteSBZQU5HIGlzDQogbm90IGN1cnJlbnRseSB1 cCB0byBkb2luZyB0aGF0KSB0aGF0IGRlZmluZXMgd2hhdCB3ZSBhcmUgZG9pbmcuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDsgUE9TVCAvcmVzdGNvbmYvZGF0YS9pZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QgSFRUUC8xLjE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj5Ib3N0Og0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuZXhhbXBsZS5j b20iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij53d3cuZXhhbXBsZS5jb208L3NwYW4+PC9hPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyBDb250 ZW50LUZvcm1hdDogJnF1b3Q7YXBwbGljYXRpb24veWFuZy5hcGkmIzQzO2pzb24mcXVvdDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj57PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZxdW90O29y aWdpbmFsLWNsaWVudC1pZCZxdW90OyA6IFsmcXVvdDtzdHJpbmcmcXVvdDsgXSwNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2lldGYtYWNjZXNzLWNvbnRy b2wtbGlzdDphY2Nlc3MtbGlzdHMmcXVvdDs6IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YWNsJnF1b3Q7OiBbPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PltBbmQgc2hvdWxkIG5vdCB3ZSBiZSBwb3N0aW5nIHRvIC9yZXN0Y29uZi9kYXRhL2lldGYtPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj5kb3RzPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LWFjY2Vzcy1jb250cm9s LWxpc3QNCiBhbnl3YXk/XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmIj4gRG90cyBbbWFpbHRvOg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkb3RzLWJv dW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OyxzYW5zLXNlcmlmIj5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRvYmJpbnMsIFJv bGFuZDxicj4NCjxiPlNlbnQ6PC9iPiAwNSBPY3RvYmVyIDIwMTcgMTA6NDI8YnI+DQo8Yj5Ubzo8 L2I+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYi PmRvdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PGJyPg0KT24gT2N0IDUsIDIwMTcsIGF0IDE0OjU4 LCBKb24gU2hhbGxvdyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNo YWxsb3cuY29tIj48c3BhbiBsYW5nPSJFTi1HQiI+c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+UGVyaGFwcyAmcXVvdDtvcmlnaW5hbC1jbGllbnQtaWQmcXVvdDsgd291bGQgYmUgYSBi ZXR0ZXIgbmFtZSAtIGluIGEgc2ltaWxhciBzb3J0IG9mIHdheSB0aGF0IHRoZSAmcXVvdDtYLUZv cndhcmRpbmctRm9yOiZxdW90OyBoZWFkZXIgcHJvdmlkZXMgdGhlIG9yaWdpbmFsIElQIG1ha2lu ZyB0aGUgSFRUUCByZXF1ZXN0IHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgbG9hZC1iYWxhbmNlciBv ciBTU0wgdGVybWluYXRvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPlRoaXMgaXMgaG93IGl0ICptdXN0KiB3b3JrLCBhZ3JlZWQ7IEkgcmVtZW1iZXIg ZGlzY3Vzc2luZyB0aGlzIHRvcGljIGF0IG9uZSBvZiB0aGUgV0cgbWVldGluZ3MsIHNwZWNpZmlj YWxseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPklm IGl0IHNvbWVob3cgd2FzIGRyb3BwZWQsIHdlIG5lZWQgdG8gZml4IGl0LiAmbmJzcDtHYXRld2F5 cyBhcmUgYSBuZWNlc3NhcnkgaW5pdGlhbCBjYXBhYmlsaXR5LCBhcyBpcyBwcmVzZXJ2aW5nIERP VFMgY2xpZW50IElEcyBhY3Jvc3MgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlJvbGFuZCBEb2JiaW5zICZs dDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+PHNwYW4gbGFuZz0i RU4tR0IiPnJkb2JiaW5zQGFyYm9yLm5ldDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tR0IiPiZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR16MB1788BC0992A54750205325EDEA740DM5PR16MB1788namp_-- From nobody Mon Oct 9 06:27:04 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8A8133011 for ; Mon, 9 Oct 2017 06:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 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_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 Ee5bolFKrK2E for ; Mon, 9 Oct 2017 06:27:00 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 E2DB9133032 for ; Mon, 9 Oct 2017 06:26:59 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507555615; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=k 5Bo2Mhlu+t/FLf1zOInPzjRg7RaY+oMiUakMo+ake s=; b=ZQIYDgrBQOH6K/YcW6ia5NiwDNDZjeDXLAZUdqgUiPSD Oo3JaoZz5VoFoiJkuoeqeF4iNgHDX+vV7Y7ZtevSG+LRr3CKdJ +Lx1l//LEAuB6oRh4bN4PPt3vX6HiC7W0XGzhwR3TjVEQ5mjw0 GnRHt9rG21IGG7CHfR8d2gnua/U= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 2c99_0941_598d2716_429d_492b_b778_8559b762dee7; Mon, 09 Oct 2017 08:26:55 -0500 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 09:26:48 -0400 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 09:26:47 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Oct 2017 09:26:47 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 09:26:47 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 9 Oct 2017 13:26:46 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.019; Mon, 9 Oct 2017 13:26:46 +0000 From: "Konda, Tirumaleswar Reddy" To: "Dobbins, Roland" CC: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAAEIgJAABpKYTw Date: Mon, 9 Oct 2017 13:26:46 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com>, <06EB9E68-F101-4809-8BF1-9C6FCDC6071E@arbor.net> In-Reply-To: <06EB9E68-F101-4809-8BF1-9C6FCDC6071E@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.90.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:da6WC9nl35Pd2vgen7lDclFIYD9ZLMbJfKO1B3ppSuSqPHrkhKAadIqW4WwjEyJIidbclCEHow+GE8uvWMG6PqkUFaWEJ9TizolIghQ1ojiKt/yLdJa5hQLGM61gUpP3RPwH4WZpEH1xuxah4YQPfUsVJqha43LdpzxhN4chkL+gmXVZ2DbxkNgmzvDVwbEYolmsnFCC63zg/pQUw4SD9hSrQzim3BTWwOH+fhQb8Y8OUBt7bQdRo+9THRub62ttmsSSkMU+nYesk7KQh9AtNfiDOTxzsYaZ1b+6tn3z/vs8epEzASFA9K94YJBvVm0qsUKUdc4noO3m63W63RCBKQ==; 5:CXDFi6LxpfWeeVw0rsgLl62qQ5ZTtKcIltBbMs5s1fNFK1kduUXQ1sUEsZxlakALCOvFYmzd4j9RmVBOAdwAiRuI9RoH+njP/TOZq/7L9u/TPuxMtv8aggAkoU6xep/dEKthiTG2NC8znNBFw/xBsA==; 24:lvbrko/dKhoeocMhJ7uFTrSouZjeL3YKn/9SkcwSmD8hw6JIan0FCF/pMMgUcK044mBGXpOF6bOl9IAHQc9Jz/GxJ1P/BTXoV6lKPGLvZUc=; 7:qZCVq7RL3OTQFLt7I5HTOLCBjtbLnqzzPskoFp8pqbDdIFSH7LnvjFuG46ACPSmfK6CgPcZmam1J0yDsn9ISO7Rk2rACWUVef/KyZRbSdf57CAnYVqEUKot6zYA9lyqTMHQVgzE8hIcr1YavnWQsdEngIM6Oj7+F670iMaL/Q/9sz90r3HmA/D7mqQwITQ+VNRTtPwOxcCjDIggc1LEMZYW5QMZP4EjMYQVAvWpkz4s= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 926be0b2-9382-48af-4d1d-08d50f1963d1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(32952001)(199003)(24454002)(377454003)(189002)(2906002)(3846002)(6116002)(102836003)(99286003)(80792005)(105586002)(2950100002)(7696004)(316002)(72206003)(54896002)(6306002)(7736002)(74316002)(93886005)(19609705001)(8676002)(97736004)(66066001)(6436002)(8936002)(6916009)(106356001)(81166006)(81156014)(53546010)(6246003)(101416001)(236005)(54356999)(55016002)(2900100001)(76176999)(86362001)(4326008)(3660700001)(77096006)(189998001)(68736007)(25786009)(790700001)(53936002)(54906003)(478600001)(5660300001)(6506006)(3280700002)(229853002)(50986999)(9686003)(33656002)(14454004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788E875CEB8C922A8ABE3D1EA740DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2017 13:26:46.5115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6132> : inlines <6113> : streams <1766508> : uri <2513748> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 13:27:02 -0000 --_000_DM5PR16MB1788E875CEB8C922A8ABE3D1EA740DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogRG9iYmlucywgUm9sYW5kIFttYWlsdG86cmRvYmJpbnNAYXJib3IubmV0XQ0KU2VudDog U2F0dXJkYXksIE9jdG9iZXIgNywgMjAxNyA0OjM5IFBNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dh ciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCkNjOiBKb24gU2hh bGxvdyA8c3VwanBzLWlldGZAanBzaGFsbG93LmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb207IGRvdHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBD aGFsbGVuZ2VzDQoNCg0KDQpPbiBPY3QgNywgMjAxNywgYXQgMTA6MjgsIEtvbmRhLCBUaXJ1bWFs ZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRp cnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PiB3cm90ZToNCkluIGNhc2Ugb2YgY2xp ZW50LXNpZGUgRE9UUyBnYXRld2F5LCB3aHkgZG9lcyB0aGUgRE9UUyBzZXJ2ZXIgbmVlZCB0byBr bm93IHdoaWNoIOKAnERPVFMgY2xpZW504oCdIGhhcyBjb252ZXllZCB0aGUgbWl0aWdhdGlvbiBy ZXF1ZXN0ID8NCg0KQmVjYXVzZSB0aGVyZSBtYXkgYmUgbWl0aWdhdGlvbiBzcGVjaWZpY3MsIHBv bGljeSwgYW5kL29yIGNvbnRyYWN0dWFsIG9ibGlnYXRpb25zIHdoaWNoIGFyZSBjbGllbnQtc3Bl Y2lmaWMuDQoNCkFncmVlZCwgYnV0IHRoZSBhYm92ZSBzdGF0ZW1lbnQgaXMgb25seSB0cnVlIGZv ciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgYnV0IG5vdCBmb3IgY2xpZW50LXNpZGUgRE9UUyBn YXRld2F5LiBUaGUgRE9UUyBjbGllbnRzIGFuZCBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgYmVs b25nIHRvIHRoZSBzYW1lIGRvbWFpbiwgdGhlIERPVFMgY2xpZW50IHdpbGwgb25seSBiZSBhdXRo b3JpemVkIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSBi dXQgbm90IHdpdGggdGhlIERPVFMgc2VydmVyLiBET1RTIGNsaWVudHMgY2Fubm90IGJ5LXBhc3Mg dGhlIERPVFMgZ2F0ZXdheSBhbmQgc2lnbmFsIGNvbmZsaWN0aW5nIHJ1bGVzIHRvIHRoZSBET1RT IHNlcnZlci4NCg0KLVRpcnUNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0Bh cmJvci5uZXQ+Pg0K --_000_DM5PR16MB1788E875CEB8C922A8ABE3D1EA740DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IERvYmJpbnMsIFJvbGFuZCBbbWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5l dF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3IDQ6MzkgUE08 YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0O1RpcnVtYWxlc3dh clJlZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKb24gU2hhbGxvdyAm bHQ7c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSZndDs7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb207IGRvdHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RT IEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gT2N0IDcsIDIwMTcsIGF0 IDEwOjI4LCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDs8YSBocmVmPSJtYWlsdG86VGly dW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+VGlydW1hbGVzd2FyUmVkZHlfS29uZGFA TWNBZmVlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBjYXNlIG9mIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdh eSwgd2h5IGRvZXMgdGhlIERPVFMgc2VydmVyIG5lZWQgdG8ga25vdyB3aGljaCDigJxET1RTIGNs aWVudOKAnSBoYXMgY29udmV5ZWQgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCA/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlY2F1c2UgdGhlcmUg bWF5IGJlIG1pdGlnYXRpb24gc3BlY2lmaWNzLCBwb2xpY3ksIGFuZC9vciBjb250cmFjdHVhbCBv YmxpZ2F0aW9ucyB3aGljaCBhcmUgY2xpZW50LXNwZWNpZmljLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFncmVlZCwgYnV0 IHRoZSBhYm92ZSBzdGF0ZW1lbnQgaXMgb25seSB0cnVlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdh dGV3YXkgYnV0IG5vdCBmb3IgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5LiBUaGUgRE9UUyBjbGll bnRzIGFuZCBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgYmVsb25nIHRvIHRoZQ0KIHNhbWUgZG9t YWluLCB0aGUgRE9UUyBjbGllbnQgd2lsbCBvbmx5IGJlIGF1dGhvcml6ZWQgdG8gY29tbXVuaWNh dGUgd2l0aCB0aGUgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IGJ1dCBub3Qgd2l0aCB0aGUgRE9U UyBzZXJ2ZXIuIERPVFMgY2xpZW50cyBjYW5ub3QgYnktcGFzcyB0aGUgRE9UUyBnYXRld2F5IGFu ZCBzaWduYWwgY29uZmxpY3RpbmcgcnVsZXMgdG8gdGhlIERPVFMgc2VydmVyLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxiciBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFu dC1lYXN0LWFzaWFuOiBub3JtYWw7Zm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWwiPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9sYW5kIERv YmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiPnJkb2JiaW5zQGFy Ym9yLm5ldDwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB1788E875CEB8C922A8ABE3D1EA740DM5PR16MB1788namp_-- From nobody Mon Oct 9 06:34:56 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2BE1331F2 for ; Mon, 9 Oct 2017 06:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 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_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 4JXrYkt1vgCt for ; Mon, 9 Oct 2017 06:34:48 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 381731332CE for ; Mon, 9 Oct 2017 06:34:48 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507556078; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=M LnGGQJTOP10ZdL2sPT73NsSMNEqquesjbOyJKx0uS 0=; b=osOY81EnOyXJE/ClEam8z43I5OlUGIRvk8YUpbpieUVl 85Y6aW9DNfwrMDhr6RSQeqh/kOlkSIPPF/3g/BU6d4BFvWEXYU Z+p8uI/9MN3bzWRfJkNU8U96blytcr2CBGBiMFxJNKJKAT/Lsc pFUAzrvxPJ1nMxpbdHi9uMKbDRM= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 4a48_00d4_0843229e_2c51_45e9_a8a8_c9dd2510bdd5; Mon, 09 Oct 2017 08:34:36 -0500 Received: from MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 09:34:32 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Oct 2017 09:34:32 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 09:34:31 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 9 Oct 2017 13:34:30 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.019; Mon, 9 Oct 2017 13:34:30 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAACzkMAABuu0fg Date: Mon, 9 Oct 2017 13:34:30 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> In-Reply-To: <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.90.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:olzvJr87KQtEM4jF8VaP/3NHDJVbQ/h7zclujEGVP91g5do8rX0SSmsMOLWuwaq3RgCS1WJSmLfCgpn+Y7p6bQy9htOaA1yiZOaqF9fp/aKDFIE9Vq6vlZ0kzESO2VKpBnkn/NGT2cGYdXWMhbYcnC2Oi1mqj95wjpfEJOHiP2A7WfGNeGpAjBgnE7oq6mfPJ7FL+la1ccfy2D+lXHoGVfWiR2NMDrBNswaK2wnR0yIh00r3eHI7P7XxTKpcEpaNbROkdx+/V1eBRUkRXmRVXfHsw4mpKHmxI4dA45nrSK5m+YhjT1xuBnTpQscKHvyNOLHLI+mmEzUOP1fb+8QGwg==; 5:0P9IiZF0QUCPY81F/fhpZ63Di7eV5qpjJuZOdmza2hJd0M7HKFV0vxwKJYqwRGKgIrbZyNMbWcQpVsB8jr1jYuyLa9xmhlwQ56Crb6VgWIxX4zwstpAt7GypH7nzwO0/PJ8MpON5w71ctJy7S51Rig==; 24:nI9M5C9f1BaOSt0ZZPGbZeny5PuDCsTG2NOJ1BmqPNVgz2UQh7/uqmZ9OX816RiZEiuoLySE89vJU/3DRwo8jPYS2Q5/p2BCeHAr3rU0a+Q=; 7:aBVp2Jfg+oMHmwGm1HMlfLv1cKsu7I7k3M3ctQc6eCSlN3MvBOhz3AW3gKEnpHZDgJz8SjuO0Q3ZBqLMGmTTElEEDHUJxizVrszioW04qNvGQH+IRmM/zOeNj1ljuFP7vBn3lMw9CH0eFi8dvSDyqXjmg+Wgzbjt5b2qwuWxtt46i8s8PcXSyX1LOqXG8SMp6cOYtZYfoYwzqFfnGar8bzLVA65mXmjKZPB6xOFn8TY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f050033c-48b6-4bb8-dba1-08d50f1a7865 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(32952001)(199003)(51444003)(377454003)(189002)(2906002)(3846002)(6116002)(102836003)(99286003)(80792005)(105586002)(2950100002)(7696004)(316002)(72206003)(54896002)(6306002)(7736002)(74316002)(93886005)(19609705001)(8676002)(97736004)(66066001)(6436002)(8936002)(106356001)(81166006)(81156014)(53546010)(6246003)(101416001)(236005)(54356999)(55016002)(2900100001)(76176999)(86362001)(3660700001)(77096006)(189998001)(68736007)(25786009)(790700001)(2501003)(110136005)(53936002)(478600001)(9326002)(5660300001)(6506006)(2201001)(3280700002)(229853002)(50986999)(9686003)(33656002)(14454004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178801766101A1EB1F4E4718EA740DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2017 13:34:30.4738 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6132> : inlines <6113> : streams <1766508> : uri <2513750> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 13:34:53 -0000 --_000_DM5PR16MB178801766101A1EB1F4E4718EA740DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uLA0KDQpJIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJsZSBmb3Ig c2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xpZW50IGlk ZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gQnV0IGZvciB0aGUgY2xpZW50LXNpZGUgRE9U UyBnYXRld2F5LCBpdCBzaG91bGQgcmVzb2x2ZSBjb25mbGljdGluZyBydWxlcyBiL3cgRE9UUyBj bGllbnRzIChlLmcuIG9uZSBjbGllbnQgaW5zdGFsbGluZyBibGFjay1saXN0IEFDTCBmb3IgYW4g SVAgYWRkcmVzcyBidXQgdGhlIG90aGVyIGNsaWVudCBpbnN0YWxscyB3aGl0ZS1saXN0IEFDTCBm b3IgdGhlIHNhbWUgSVAgYWRkcmVzcywgc2FtZSBhbGlhcy1uYW1lcyBmb3IgZGlmZmVyZW50IG1p dGlnYXRpb24gc2NvcGVzKS4gSSBkb27igJl0IHNlZSB0aGUgbmVlZCBmb3IgYSBjbGllbnQtc2lk ZSBET1RTIGdhdGV3YXkgdG8gY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhl IHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBvciBET1RTIHNlcnZlci4NCg0KLVRpcnUNCg0KRnJv bTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KU2VudDog U2F0dXJkYXksIE9jdG9iZXIgNywgMjAxNyAyOjA3IFBNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dh ciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb207IGRvdHNAaWV0Zi5vcmc7IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmlu c0BhcmJvci5uZXQ+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdl cw0KDQpIaSBUaXJ1LA0KDQpUaGlzIGRpc2N1c3Npb24gZ29lcyBiZXlvbmQganVzdCB0aGUgbWl0 aWdhdGlvbiByZXF1ZXN0LiAgV2UgbmVlZCB0byBjb25zaWRlciB3aGF0IGhhcHBlbnMgd2l0aCBi b3RoIGFsaWFzLW5hbWUgYW5kIGFjbC1uYW1lIChkYXRhIGNoYW5uZWwpDQoNClRoZSBzaW1wbGUg Y2FzZSBvZiBhIG1pdGlnYXRpb24gcmVxdWVzdCB3aXRoIG5vIGFsaWFzLW5hbWUgZG9lcyBub3Qg cmVxdWlyZSBhbnkga25vd2xlZGdlIG9mIHRoZSBvcmlnaW5hbCBjbGllbnQuDQoNCkhvd2V2ZXIs IGlmIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgdXNlcyBhbGlhcy1uYW1lLCB0aGVuIHRoZXJlIGFy ZSAzIHdheXMgb2YgaGFuZGxpbmcgdGhpcw0KDQphKSAgICAgICBUaGUgRE9UUyBHVyByZXBsYWNl cyB0aGUgYWxpYXMtbmFtZSB3aXRoIGl0cyBhY3R1YWwgZGVmaW5pdGlvbiAodGFyZ2V0LWlwcyBl dGMuIG1lcmdlZCBhcyBhcHByb3ByaWF0ZSksIHNvIGFsaWFzLW5hbWUgaXMgbm90IGZvcndhcmRl ZCBvbiB0byBTZXJ2ZXIg4oCTIGp1c3QgdGhlIGV4cGFuZGVkIG1pdGlnYXRpb24gcmVxdWVzdCBp cyBmb3J3YXJkZWQNCg0KYikgICAgICBUaGUgRE9UUyBHVyB1cGRhdGVzIHRoZSBhbGlhcy1uYW1l IHdpdGggYSB1bmlxdWUgYWxpYXMtbmFtZSB0aGF0IGlzIGZvcndhcmRlZCAoYW5kIGhhcyB0byBk byB0aGUgc2FtZSB0aGluZyB3aGVuIHRoZSBhbGlhcy1uYW1lIGlzIGNvbmZpZ3VyZWQgb24gdGhl IGRhdGEgY2hhbm5lbCkg4oCTIHRvIGhhbmRsZSAyIG9yIG1vcmUgY2xpZW50cyBkZWZpbmluZyB0 aGUgc2FtZSBhbGlhcy1uYW1lIHdoaWNoIGhhdmUgZGlmZmVyZW50IGNoYXJhY3RlcmlzdGljcw0K DQpjKSAgICAgICBUaGUgRE9UUyBHVyByZWNvZ25pc2VzIHRoYXQgYWxpYXMtbmFtZSBpcyBub3Qg dW5pcXVlIGFuZCBhZGRzIGluIOKAnWFkZGl0aW9uYWwtY2xpZW50LWluZm/igJ0gKEkgdGhpbmsg SSBwcmVmZXIgdGhpcyDigJwtaW5mb+KAnSBuYW1lIHRvIGNsaWVudC1pZCBvciBvcmlnaW5hbC1j bGllbnQtaWQgYXMg4oCcLWlk4oCdIGlzIHRvbyBjbG9zZWx5ICBhc3NvY2lhdGVkIHdpdGggQ2xp ZW50IElkZW50aXR5IGRlcml2ZWQgZnJvbSB0aGUgRE9UUyBHVyBDbGllbnQgY2VydGlmaWNhdGUp DQpXZSBoYXZlIGFncmVlZCB0aGF0IHdoZW4gYSBjbGllbnQgcmVxdWVzdHMgbWl0aWdhdGlvbiBz dGF0dXMsIHRoZSDigJxhbGlhcy1uYW1l4oCdIHNob3VsZCBiZSByZXR1cm5lZCBhcyDigJxhbGlh cy1uYW1l4oCdIGFuZCBub3QgdGhlIHN1YnN0aXR1dGVkIGFsaWFzLW5hbWUgY29uZmlndXJhdGlv biAodGhpcyBkb2VzIG5lZWQgdG8gYmUgc3RhdGVkIGluIHRoZSBzcGVjIGZvciBjbGFyaXR5KS4g IFRoaXMgbWFrZXMgKGEpIGRpZmZpY3VsdCB0byBiZSBoYW5kbGVkIGJ5IERPVFMgR1cgd2hpY2gg dGhlbiByYWlzZXMgdGhlIHF1ZXN0aW9uIOKAkyBkbyB3ZSByZWFsbHkgbmVlZCBhbGlhcy1uYW1l Pw0KDQpUaGUgZGVmaW5pdGlvbiBhbmQgYXNzb2NpYXRpb24gb2YgQUNMcy9GaWx0ZXJzIG9mIHRo ZSBkYXRhIGNoYW5uZWwgaXMgbW9yZSBkaWZmaWN1bHQg4oCTIHRoZSBTZXJ2ZXIgbXVzdCBpbnN0 YWxsIC8gYXBwbHkgdGhlIGFwcHJvcHJpYXRlIEFDTHMgb24gYSBwZXIgKE9yaWdpbmFsKSBDbGll bnQgYmFzaXMgd2hlbiBtaXRpZ2F0aW9uIGlzIGludm9rZWQuDQpDbGllbnQgMeKAmXMgY29uY2Vw dCBvZiBhIFdoaXRlbGlzdCBJUCBjb3VsZCBiZSBDbGllbnQgMuKAmXMgY29uY2VwdCBvZiBhIEJs YWNrbGlzdCBJUC4gIFRoZSBTZXJ2ZXIgbmVlZHMgdG8ga25vdyB3aGljaCBjbGllbnQgaXMgcmVx dWVzdGluZyB0aGUgbWl0aWdhdGlvbiBhbmQgaW5zdGFsbCB0aGUgY29ycmVjdCBBQ0xzIOKAkyBp ZiB0aGVyZSB3YXMgbm8g4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSwgdGhlIFNlcnZlciBv bmx5IGtub3dzIHRoYXQgaGUgaGFzIHRvIGluc3RhbGwgQUxMIG9mIHRoZSBBQ0xzIChpLmUuIGJv dGggdGhlIEJsYWNrIGFuZCBXaGl0ZSBsaXN0IG9mIHRoZSBzYW1lIElQIGFzIGRlZmluZWQgYnkg Q2xpZW50IDEgYW5kIENsaWVudCAyKSBhcyBkZWZpbmVkIGJ5IGhpcyBjbGllbnQgKERPVFMgR1cp IHdoZW4gaGlzIGNsaWVudCByZXF1ZXN0cyBhIG1pdGlnYXRpb24uICBIZXJlLCBJIHRoaW5rIHRo YXQgaWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBjbGllbnQgZm9yIHRoZSBET1RTIEdXLCDigJ1h ZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdIGlzIHJlcXVpcmVkLg0KDQpSZWdhcmRzDQoNCkpvbg0K DQpGcm9tOiBEb3RzIFttYWlsdG86IGRvdHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkN ClNlbnQ6IDA3IE9jdG9iZXIgMjAxNyAwNDoyOA0KVG86IEpvbiBTaGFsbG93OyBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsg ZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zDQpTdWJq ZWN0OiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpJbiBjYXNlIG9mIGNs aWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgd2h5IGRvZXMgdGhlIERPVFMgc2VydmVyIG5lZWQgdG8g a25vdyB3aGljaCDigJxET1RTIGNsaWVudOKAnSBoYXMgY29udmV5ZWQgdGhlIG1pdGlnYXRpb24g cmVxdWVzdCA/DQpGb3IgZXhhbXBsZSwgdGhlIERPVFMgY2xpZW50IGNvdWxkIGJlIGEgRERvUyBk ZXRlY3RvciBvciBhbiBBcHBsaWNhdGlvbiBzZXJ2ZXIsIGFuZCB0aGUgY2xpZW50LXNpZGUgZ2F0 ZXdheSB3aWxsIGhhdmUgdG8gcmVzb2x2ZSB0aGUgY29uZmxpY3RpbmcgbWl0aWdhdGlvbiByZXF1 ZXN0cyBmcm9tIHRoZSBET1RTIGNsaWVudHMsIGFnZ3JlZ2F0ZSB0aGUgbWl0aWdhdGlvbiByZXF1 ZXN0cyBmcm9tIHRoZSBET1RTIGNsaWVudCBhbmQgc2VuZCB0aGUgdXBkYXRlZCBtaXRpZ2F0aW9u IHJlcXVlc3QgdG8gdGhlIERPVFMgc2VydmVyLg0KDQotVGlydQ0KDQpGcm9tOiBKb24gU2hhbGxv dyBbbWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQpTZW50OiBGcmlkYXksIE9jdG9i ZXIgNiwgMjAxNyA3OjQyIFBNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1h bGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29u ZGFATWNBZmVlLmNvbT4+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRm Lm9yZz47IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5z QGFyYm9yLm5ldD4+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdl cw0KDQpIaSBUaXJ1LA0KDQpVbmxlc3MgSSBhbSBtaXNzaW5nIHNvbWV0aGluZywgaG93IGRvZXMg dGhlIENsaWVudCBzaWRlIG9mIERPVFMgR1cgY29udmV5IHRvIHRoZSB1cHN0cmVhbSBzZXJ2ZXIg YSB1bmlxdWUg4oCcY2xpZW50LWlk4oCdIHdoaWNoIGlzIGRpZmZlcmVudCB0byB0aGUgaW1wbGll ZCBjbGllbnQgaWQgYXMgZGVyaXZlZCBmcm9tIHRoZSBQS0kgY2VydGlmaWNhdGUgdGhhdCB0aGUg RE9UUyBHV+KAmUNsaWVudCB1c2VzL3ByZXNlbnRzIHdoZW4gY29tbXVuaWNhdGluZyB0byB0aGUg c2VydmVyPw0KVG8gbWUsIHRoZXJlIG5lZWRzIHRvIGJlIGFuIG9wdGlvbiBzdWNoIGFzIOKAnG9y aWdpbmFsLWNsaWVudC1pZOKAnSBvciDigJxjbGllbnQtaWTigJ0gKHdoaWNoIGlzIGNvbmZ1c2lu ZyB3aGVuIGFsc28gcmVmZXJyaW5nIHRvIHRoZSBjbGllbnQgaWRlbnRpdHkgYXMgZGVyaXZlZCBm cm9tIHRoZSAoRE9UUyBHVykgQ2xpZW504oCZcyBQS0kgY2VydGlmaWNhdGUpIGFzIGEgcGFydCBv ZiB0aGUgcHJvdG9jb2wuDQoNCkkgYWdyZWUgdGhhdCB0aGUgRE9UUyBHVyBjYW4gZ2VuZXJhdGUg aXRzIG93biB1bmlxdWUgY2xpZW50LWlkIHRvIHN0b3AgbXVsdGlwbGUgZW50cmllcyBiZWluZyBu ZWVkZWQuDQoNCkkgYWdyZWUgdGhhdCBpcyBub3QgYSBnb29kIHRoaW5nIHRvIOKAnGxlYWvigJ0g b3V0IGludGVybmFsIGluZm9ybWF0aW9uIHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHVywg c28gbXkgUkVRVUlSRUQgZG9lcyBub3QgbWFrZSBzZW5zZS4NCg0KUmVnYXJkcw0KDQpKb24NClBT IOKAkyBJIGFtIGhhdmluZyB0byBkZWFsIHdpdGggb3RoZXIgc3R1ZmYgYXQgcHJlc2VudCDigJMg SSB3aWxsIGdldCBiYWNrIGxhdGVyIG9uIHRoZSBvdGhlciBpc3N1ZXMgdW5kZXIgZGlzY3Vzc2lv bg0KDQpGcm9tOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IFttYWlsdG86IFRpcnVtYWxlc3dh clJlZGR5X0tvbmRhQG1jYWZlZS5jb208bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQG1j YWZlZS5jb20+XQ0KU2VudDogMDYgT2N0b2JlciAyMDE3IDE0OjU4DQpUbzogbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IEpv biBTaGFsbG93OyAnRG9iYmlucywgUm9sYW5kJzsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoN CkkgZG9u4oCZdCBzZWUgYSBuZWVkIGZvciBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgdG8gY29u dmV5IHRoZSDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIOKA nERPVFMgY2xpZW50IGlkZW50aXR54oCdIGxvb2tzIHJlcXVpcmVkIG9ubHkgZm9yIHRoZSBzZXJ2 ZXItc2lkZSBET1RTIGdhdGV3YXlzLiBJbiBjYXNlIG9mIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdh eSwgaXQgY2FuIGNvbnZleSB0aGUgY2xpZW50LWlkIGdlbmVyYXRlZCBmcm9tIHRoZSDigJxET1RT IGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIFRoZSBET1RTIGdhdGV3YXkg Y2FuIGdlbmVyYXRlIGEgdW5pcXVlIGNsaWVudC1pZCBhbmQgZG9lcyBub3QgaGF2ZSB0byBzZW5k IGFuIGFycmF5IG9mIGNsaWVudC1pZHMgdG8gdGhlIERPVFMgc2VydmVyIHRvIHJlc29sdmUgY2xh c2hlcy4NCg0KLVRpcnUNCg== --_000_DM5PR16MB178801766101A1EB1F4E4718EA740DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIg MiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs c2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1s ZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkJhbGxvb25UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWls eToiU2Vnb2UgVUkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1z dHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsc2Fucy1zZXJpZjt9DQpwLlRleHRlZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5U ZXh0ZWRlYnVsbGVzDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1z dHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyMDYyMTc4NzA7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwODkzNTQxNiAxMzQ4 MDc1NzUgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAx MzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+SGkgSm9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBh cmUgYXBwbGljYWJsZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZl eSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gQnV0IGZvciB0 aGUgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5LCBpdCBzaG91bGQNCiByZXNvbHZlIGNvbmZsaWN0 aW5nIHJ1bGVzIGIvdyBET1RTIGNsaWVudHMgKGUuZy4gb25lIGNsaWVudCBpbnN0YWxsaW5nIGJs YWNrLWxpc3QgQUNMIGZvciBhbiBJUCBhZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xpZW50IGluc3Rh bGxzIHdoaXRlLWxpc3QgQUNMIGZvciB0aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1lIGFsaWFzLW5h bWVzIGZvciBkaWZmZXJlbnQgbWl0aWdhdGlvbiBzY29wZXMpLiBJIGRvbuKAmXQgc2VlIHRoZSBu ZWVkIGZvciBhIGNsaWVudC1zaWRlDQogRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcY2xp ZW50IGlkZW50aXR54oCdIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgb3IgRE9UUyBz ZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb24gU2hh bGxvdyBbbWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gU2F0dXJkYXksIE9jdG9iZXIgNywgMjAxNyAyOjA3IFBNPGJyPg0KPGI+VG86PC9iPiBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDtUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUu Y29tJmd0OzsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgZG90c0BpZXRmLm9yZzsgUm9s YW5kIERvYmJpbnMgJmx0O3Jkb2JiaW5zQGFyYm9yLm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgZGlzY3Vzc2lvbiBnb2Vz IGJleW9uZCBqdXN0IHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QuJm5ic3A7IFdlIG5lZWQgdG8gY29u c2lkZXIgd2hhdCBoYXBwZW5zIHdpdGggYm90aCBhbGlhcy1uYW1lIGFuZCBhY2wtbmFtZSAoZGF0 YSBjaGFubmVsKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgc2ltcGxlIGNhc2Ugb2YgYSBtaXRpZ2F0aW9uIHJl cXVlc3Qgd2l0aCBubyBhbGlhcy1uYW1lIGRvZXMgbm90IHJlcXVpcmUgYW55IGtub3dsZWRnZSBv ZiB0aGUgb3JpZ2luYWwgY2xpZW50LiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIGlmIHRo ZSBtaXRpZ2F0aW9uIHJlcXVlc3QgdXNlcyBhbGlhcy1uYW1lLCB0aGVuIHRoZXJlIGFyZSAzIHdh eXMgb2YgaGFuZGxpbmcgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEpPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+VGhlIERPVFMgR1cgcmVwbGFjZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBpdHMgYWN0 dWFsIGRlZmluaXRpb24gKHRhcmdldC1pcHMgZXRjLiBtZXJnZWQgYXMgYXBwcm9wcmlhdGUpLCBz byBhbGlhcy1uYW1lDQogaXMgbm90IGZvcndhcmRlZCBvbiB0byBTZXJ2ZXIg4oCTIGp1c3QgdGhl IGV4cGFuZGVkIG1pdGlnYXRpb24gcmVxdWVzdCBpcyBmb3J3YXJkZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj5iKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RTIEdXIHVwZGF0ZXMgdGhlIGFsaWFzLW5h bWUgd2l0aCBhIHVuaXF1ZSBhbGlhcy1uYW1lIHRoYXQgaXMgZm9yd2FyZGVkIChhbmQgaGFzIHRv IGRvIHRoZSBzYW1lIHRoaW5nIHdoZW4NCiB0aGUgYWxpYXMtbmFtZSBpcyBjb25maWd1cmVkIG9u IHRoZSBkYXRhIGNoYW5uZWwpIOKAkyB0byBoYW5kbGUgMiBvciBtb3JlIGNsaWVudHMgZGVmaW5p bmcgdGhlIHNhbWUgYWxpYXMtbmFtZSB3aGljaCBoYXZlIGRpZmZlcmVudCBjaGFyYWN0ZXJpc3Rp Y3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5jKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RT IEdXIHJlY29nbmlzZXMgdGhhdCBhbGlhcy1uYW1lIGlzIG5vdCB1bmlxdWUgYW5kIGFkZHMgaW4g 4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSAoSSB0aGluayBJIHByZWZlciB0aGlzDQog4oCc LWluZm/igJ0gbmFtZSB0byBjbGllbnQtaWQgb3Igb3JpZ2luYWwtY2xpZW50LWlkIGFzIOKAnC1p ZOKAnSBpcyB0b28gY2xvc2VseSAmbmJzcDthc3NvY2lhdGVkIHdpdGggQ2xpZW50IElkZW50aXR5 IGRlcml2ZWQgZnJvbSB0aGUgRE9UUyBHVyBDbGllbnQgY2VydGlmaWNhdGUpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5XZSBoYXZlIGFncmVlZCB0aGF0IHdoZW4gYSBjbGllbnQgcmVx dWVzdHMgbWl0aWdhdGlvbiBzdGF0dXMsIHRoZSDigJxhbGlhcy1uYW1l4oCdIHNob3VsZCBiZSBy ZXR1cm5lZCBhcyDigJxhbGlhcy1uYW1l4oCdIGFuZCBub3QgdGhlIHN1YnN0aXR1dGVkIGFsaWFz LW5hbWUNCiBjb25maWd1cmF0aW9uICh0aGlzIGRvZXMgbmVlZCB0byBiZSBzdGF0ZWQgaW4gdGhl IHNwZWMgZm9yIGNsYXJpdHkpLiZuYnNwOyBUaGlzIG1ha2VzIChhKSBkaWZmaWN1bHQgdG8gYmUg aGFuZGxlZCBieSBET1RTIEdXIHdoaWNoIHRoZW4gcmFpc2VzIHRoZSBxdWVzdGlvbiDigJMgZG8g d2UgcmVhbGx5IG5lZWQgYWxpYXMtbmFtZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGRlZmluaXRpb24gYW5k IGFzc29jaWF0aW9uIG9mIEFDTHMvRmlsdGVycyBvZiB0aGUgZGF0YSBjaGFubmVsIGlzIG1vcmUg ZGlmZmljdWx0IOKAkyB0aGUgU2VydmVyIG11c3QgaW5zdGFsbCAvIGFwcGx5IHRoZSBhcHByb3By aWF0ZSBBQ0xzIG9uIGENCiBwZXIgKE9yaWdpbmFsKSBDbGllbnQgYmFzaXMgd2hlbiBtaXRpZ2F0 aW9uIGlzIGludm9rZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DbGllbnQgMeKA mXMgY29uY2VwdCBvZiBhIFdoaXRlbGlzdCBJUCBjb3VsZCBiZSBDbGllbnQgMuKAmXMgY29uY2Vw dCBvZiBhIEJsYWNrbGlzdCBJUC4mbmJzcDsgVGhlIFNlcnZlciBuZWVkcyB0byBrbm93IHdoaWNo IGNsaWVudCBpcyByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uDQogYW5kIGluc3RhbGwgdGhlIGNv cnJlY3QgQUNMcyDigJMgaWYgdGhlcmUgd2FzIG5vIOKAnWFkZGl0aW9uYWwtY2xpZW50LWluZm/i gJ0sIHRoZSBTZXJ2ZXIgb25seSBrbm93cyB0aGF0IGhlIGhhcyB0byBpbnN0YWxsIEFMTCBvZiB0 aGUgQUNMcyAoaS5lLiBib3RoIHRoZSBCbGFjayBhbmQgV2hpdGUgbGlzdCBvZiB0aGUgc2FtZSBJ UCBhcyBkZWZpbmVkIGJ5IENsaWVudCAxIGFuZCBDbGllbnQgMikgYXMgZGVmaW5lZCBieSBoaXMg Y2xpZW50IChET1RTIEdXKQ0KIHdoZW4gaGlzIGNsaWVudCByZXF1ZXN0cyBhIG1pdGlnYXRpb24u Jm5ic3A7IEhlcmUsIEkgdGhpbmsgdGhhdCBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGNsaWVu dCBmb3IgdGhlIERPVFMgR1csIOKAnWFkZGl0aW9uYWwtY2xpZW50LWluZm/igJ0gaXMgcmVxdWly ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IERvdHMgW21haWx0bzoNCjxhIGhy ZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRmLm9yZzwv YT5dIDxiPk9uIEJlaGFsZiBPZg0KPC9iPktvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk8YnI+DQo8 Yj5TZW50OjwvYj4gMDcgT2N0b2JlciAyMDE3IDA0OjI4PGJyPg0KPGI+VG86PC9iPiBKb24gU2hh bGxvdzsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5v cmciPmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmluczxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5JbiBjYXNlIG9mIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgd2h5IGRv ZXMgdGhlIERPVFMgc2VydmVyIG5lZWQgdG8ga25vdyB3aGljaCDigJxET1RTIGNsaWVudOKAnSBo YXMgY29udmV5ZWQgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCA/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgZXhhbXBsZSwgdGhl IERPVFMgY2xpZW50IGNvdWxkIGJlIGEgRERvUyBkZXRlY3RvciBvciBhbiBBcHBsaWNhdGlvbiBz ZXJ2ZXIsIGFuZCB0aGUgY2xpZW50LXNpZGUgZ2F0ZXdheSB3aWxsIGhhdmUgdG8gcmVzb2x2ZSB0 aGUgY29uZmxpY3RpbmcgbWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIHRoZQ0KIERPVFMgY2xpZW50 cywgYWdncmVnYXRlIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50 IGFuZCBzZW5kIHRoZSB1cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2 ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IEpvbiBTaGFsbG93IFs8YSBocmVmPSJtYWlsdG86c3VwanBz LWlldGZAanBzaGFsbG93LmNvbSI+bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciA2LCAyMDE3IDc6NDIgUE08YnI+ DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0OzxhIGhyZWY9Im1haWx0 bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj5UaXJ1bWFsZXN3YXJSZWRkeV9L b25kYUBNY0FmZWUuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9 Im1haWx0bzpkb3RzQGlldGYub3JnIj4NCmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmlu cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+cmRvYmJpbnNAYXJib3Iu bmV0PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlz IENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlVubGVzcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBob3cgZG9lcyB0aGUgQ2xp ZW50IHNpZGUgb2YgRE9UUyBHVyBjb252ZXkgdG8gdGhlIHVwc3RyZWFtIHNlcnZlciBhIHVuaXF1 ZSDigJxjbGllbnQtaWTigJ0gd2hpY2ggaXMgZGlmZmVyZW50IHRvIHRoZSBpbXBsaWVkDQogY2xp ZW50IGlkIGFzIGRlcml2ZWQgZnJvbSB0aGUgUEtJIGNlcnRpZmljYXRlIHRoYXQgdGhlIERPVFMg R1figJlDbGllbnQgdXNlcy9wcmVzZW50cyB3aGVuIGNvbW11bmljYXRpbmcgdG8gdGhlIHNlcnZl cj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvIG1lLCB0aGVyZSBuZWVkcyB0byBi ZSBhbiBvcHRpb24gc3VjaCBhcyDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0gb3Ig4oCcY2xpZW50 LWlk4oCdICh3aGljaCBpcyBjb25mdXNpbmcgd2hlbiBhbHNvIHJlZmVycmluZyB0byB0aGUgY2xp ZW50IGlkZW50aXR5IGFzDQogZGVyaXZlZCBmcm9tIHRoZSAoRE9UUyBHVykgQ2xpZW504oCZcyBQ S0kgY2VydGlmaWNhdGUpIGFzIGEgcGFydCBvZiB0aGUgcHJvdG9jb2wuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkg YWdyZWUgdGhhdCB0aGUgRE9UUyBHVyBjYW4gZ2VuZXJhdGUgaXRzIG93biB1bmlxdWUgY2xpZW50 LWlkIHRvIHN0b3AgbXVsdGlwbGUgZW50cmllcyBiZWluZyBuZWVkZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkg YWdyZWUgdGhhdCBpcyBub3QgYSBnb29kIHRoaW5nIHRvIOKAnGxlYWvigJ0gb3V0IGludGVybmFs IGluZm9ybWF0aW9uIHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHVywgc28gbXkgUkVRVUlS RUQgZG9lcyBub3QgbWFrZSBzZW5zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5K b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBTIOKAkyBJIGFtIGhhdmluZyB0byBk ZWFsIHdpdGggb3RoZXIgc3R1ZmYgYXQgcHJlc2VudCDigJMgSSB3aWxsIGdldCBiYWNrIGxhdGVy IG9uIHRoZSBvdGhlciBpc3N1ZXMgdW5kZXIgZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBLb25kYSwgVGlydW1hbGVzd2FyIFJl ZGR5IFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNh ZmVlLmNvbSI+VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gMDYgT2N0b2JlciAyMDE3IDE0OjU4PGJyPg0KPGI+VG86PC9iPiA8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTwvYT47IEpvbiBTaGFsbG93OyAnRG9iYmlucywgUm9sYW5kJzsNCjxhIGhyZWY9 Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JIGRvbuKAmXQgc2VlIGEgbmVlZCBmb3IgY2xpZW50LXNpZGUgRE9U UyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhl IERPVFMgc2VydmVyLiDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSBsb29rcyByZXF1aXJlZCBv bmx5IGZvciB0aGUgc2VydmVyLXNpZGUgRE9UUw0KIGdhdGV3YXlzLiBJbiBjYXNlIG9mIHNlcnZl ci1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgY2FuIGNvbnZleSB0aGUgY2xpZW50LWlkIGdlbmVyYXRl ZCBmcm9tIHRoZSDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIu IFRoZSBET1RTIGdhdGV3YXkgY2FuIGdlbmVyYXRlIGEgdW5pcXVlIGNsaWVudC1pZCBhbmQgZG9l cyBub3QgaGF2ZSB0byBzZW5kIGFuIGFycmF5IG9mIGNsaWVudC1pZHMgdG8gdGhlIERPVFMgc2Vy dmVyIHRvDQogcmVzb2x2ZSBjbGFzaGVzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LVRpcnU8c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR16MB178801766101A1EB1F4E4718EA740DM5PR16MB1788namp_-- From nobody Mon Oct 9 07:13:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC8F1342CF for ; Mon, 9 Oct 2017 07:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rHwhJ1faJhu for ; Mon, 9 Oct 2017 07:13:01 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85E5133032 for ; Mon, 9 Oct 2017 07:13:00 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 67ED412054E; Mon, 9 Oct 2017 16:12:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 438F16007A; Mon, 9 Oct 2017 16:12:59 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0361.001; Mon, 9 Oct 2017 16:12:58 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Dobbins, Roland" CC: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAAEIgJAABpKYTwAAGs+WA= Date: Mon, 9 Oct 2017 14:12:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A051394@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com>, <06EB9E68-F101-4809-8BF1-9C6FCDC6071E@arbor.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A051394OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 14:13:04 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A051394OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXhhY3RseS4NCg0KSSBndWVzcyB3ZSBuZWVkIHRvIGluY2x1ZGUgYSBjbGFyaWZpY2F0aW9uIGFi b3V0IGNsaWVudC1zaWRlIERPVFNHIHZzLiBzZXJ2ZXItc2lkZSBET1RTRyBpbiB0aGUgZHJhZnQg KG9yIHByZWZlcmFibHkgaW4gdGhlIHJlcXVpcmVtZW50cy9hcmNoaXRlY3R1cmUgSS1EcykuDQoN CkNoZWVycywNCk1lZA0KDQpEZSA6IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgW21haWx0bzpU aXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KRW52b3nDqSA6IGx1bmRpIDkgb2N0 b2JyZSAyMDE3IDE1OjI3DQrDgCA6IERvYmJpbnMsIFJvbGFuZA0KQ2MgOiBKb24gU2hhbGxvdzsg Qk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgZG90c0BpZXRmLm9yZw0KT2JqZXQgOiBSRTogW0Rv dHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpGcm9tOiBEb2JiaW5zLCBSb2xhbmQgW21h aWx0bzpyZG9iYmluc0BhcmJvci5uZXRdDQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3 IDQ6MzkgUE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRk eV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUu Y29tPj4NCkNjOiBKb24gU2hhbGxvdyA8c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTxtYWlsdG86 c3VwanBzLWlldGZAanBzaGFsbG93LmNvbT4+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWls dG86ZG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFs bGVuZ2VzDQoNCg0KDQpPbiBPY3QgNywgMjAxNywgYXQgMTA6MjgsIEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVt YWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PiB3cm90ZToNCkluIGNhc2Ugb2YgY2xpZW50 LXNpZGUgRE9UUyBnYXRld2F5LCB3aHkgZG9lcyB0aGUgRE9UUyBzZXJ2ZXIgbmVlZCB0byBrbm93 IHdoaWNoIOKAnERPVFMgY2xpZW504oCdIGhhcyBjb252ZXllZCB0aGUgbWl0aWdhdGlvbiByZXF1 ZXN0ID8NCg0KQmVjYXVzZSB0aGVyZSBtYXkgYmUgbWl0aWdhdGlvbiBzcGVjaWZpY3MsIHBvbGlj eSwgYW5kL29yIGNvbnRyYWN0dWFsIG9ibGlnYXRpb25zIHdoaWNoIGFyZSBjbGllbnQtc3BlY2lm aWMuDQoNCkFncmVlZCwgYnV0IHRoZSBhYm92ZSBzdGF0ZW1lbnQgaXMgb25seSB0cnVlIGZvciBz ZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgYnV0IG5vdCBmb3IgY2xpZW50LXNpZGUgRE9UUyBnYXRl d2F5LiBUaGUgRE9UUyBjbGllbnRzIGFuZCBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgYmVsb25n IHRvIHRoZSBzYW1lIGRvbWFpbiwgdGhlIERPVFMgY2xpZW50IHdpbGwgb25seSBiZSBhdXRob3Jp emVkIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSBidXQg bm90IHdpdGggdGhlIERPVFMgc2VydmVyLiBET1RTIGNsaWVudHMgY2Fubm90IGJ5LXBhc3MgdGhl IERPVFMgZ2F0ZXdheSBhbmQgc2lnbmFsIGNvbmZsaWN0aW5nIHJ1bGVzIHRvIHRoZSBET1RTIHNl cnZlci4NCg0KLVRpcnUNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Um9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJib3Iu bmV0Pj4NCg== --_000_787AE7BB302AE849A7480A190F8B93300A051394OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRl IGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi VGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2Vp Z2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FeGFjdGx5Lg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+SSBndWVzcyB3ZSBuZWVkIHRvIGluY2x1ZGUgYSBjbGFyaWZpY2F0aW9uIGFib3V0IGNsaWVu dC1zaWRlIERPVFNHIHZzLiBzZXJ2ZXItc2lkZSBET1RTRyBpbiB0aGUgZHJhZnQgKG9yIHByZWZl cmFibHkgaW4gdGhlIHJlcXVpcmVtZW50cy9hcmNoaXRlY3R1cmUNCiBJLURzKS4gPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgW21haWx0bzpUaXJ1 bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8 L2I+IGx1bmRpIDkgb2N0b2JyZSAyMDE3IDE1OjI3PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBEb2Ji aW5zLCBSb2xhbmQ8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IEpvbiBTaGFsbG93OyBCT1VDQURBSVIg TW9oYW1lZCBJTVQvT0xOOyBkb3RzQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBS RTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gRG9iYmlucywgUm9sYW5kIFs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNA YXJib3IubmV0Ij5tYWlsdG86cmRvYmJpbnNAYXJib3IubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3IDQ6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IEtv bmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0OzxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29t PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEpvbiBTaGFsbG93ICZsdDs8YSBocmVmPSJtYWlsdG86 c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTwvYT4m Z3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9y ZyI+DQpkb3RzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNdIERP VFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCk9u IE9jdCA3LCAyMDE3LCBhdCAxMDoyOCwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEg aHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5JbiBjYXNlIG9mIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgd2h5IGRvZXMgdGhl IERPVFMgc2VydmVyIG5lZWQgdG8ga25vdyB3aGljaCDigJxET1RTIGNsaWVudOKAnSBoYXMgY29u dmV5ZWQgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZWNhdXNlIHRoZXJlIG1heSBiZSBtaXRpZ2F0aW9uIHNw ZWNpZmljcywgcG9saWN5LCBhbmQvb3IgY29udHJhY3R1YWwgb2JsaWdhdGlvbnMgd2hpY2ggYXJl IGNsaWVudC1zcGVjaWZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BZ3JlZWQsIGJ1dCB0aGUgYWJvdmUgc3RhdGVtZW50 IGlzIG9ubHkgdHJ1ZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGJ1dCBub3QgZm9yIGNs aWVudC1zaWRlIERPVFMgZ2F0ZXdheS4gVGhlIERPVFMgY2xpZW50cyBhbmQgY2xpZW50LXNpZGUg RE9UUyBnYXRld2F5DQogYmVsb25nIHRvIHRoZSBzYW1lIGRvbWFpbiwgdGhlIERPVFMgY2xpZW50 IHdpbGwgb25seSBiZSBhdXRob3JpemVkIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIGNsaWVudC1z aWRlIERPVFMgZ2F0ZXdheSBidXQgbm90IHdpdGggdGhlIERPVFMgc2VydmVyLiBET1RTIGNsaWVu dHMgY2Fubm90IGJ5LXBhc3MgdGhlIERPVFMgZ2F0ZXdheSBhbmQgc2lnbmFsIGNvbmZsaWN0aW5n IHJ1bGVzIHRvIHRoZSBET1RTIHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tVGlydTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Um9sYW5kIERvYmJpbnMgJmx0OzxhIGhy ZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiPnJkb2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93300A051394OPEXCLILMA3corp_-- From nobody Mon Oct 9 07:39:35 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4622F133187 for ; Mon, 9 Oct 2017 07:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXjgPNOq6vU5 for ; Mon, 9 Oct 2017 07:39:31 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 245A5133055 for ; Mon, 9 Oct 2017 07:39:31 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e1ZDM-0002Ps-0L; Mon, 09 Oct 2017 15:39:28 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , , "Roland Dobbins" References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> In-Reply-To: Date: Mon, 9 Oct 2017 15:39:29 +0100 Message-ID: <0be801d3410c$69ca1260$3d5e3720$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BE9_01D34114.CB909D40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIAJQ6kjUASRe9X8Bri7ZGgMYlBpaopSX3bA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 14:39:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0BE9_01D34114.CB909D40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 I think part of the challenge here in our thinking is that a mitigation = request does not (cannot) ask for a specific ACL/Filter (or set of ACLS) = to be installed =E2=80=93 in a similar vein to the mitigation request = being able to call up a specific alias-name to be used. [You refer to =E2=80=9Cbut the other client installs white-list ACL for = the same IP address, same alias-names for different mitigation = scopes)=E2=80=9D below =E2=80=93 however alias-names do not currently = dictate which ACL to use as per module: = ietf-dots-data-channel-identifier.] =20 The current design appears to me is that the ACL/filter list is defined = on the DOTS Server (by a DOTS client or directly on the DOTS Server) and = you then get all the defined ACLs instantiated by DOTS Mitigator = =E2=80=93 for a single mitigation request. Even if the Filters are held = on a per client basis, there no way to upload a set of different filters = in peace time ready for selection as to which is be used in case of DDoS = Attack. White/Black lists are probably fairly static, it is the = customizable filters that are the issue currently for me.=20 =20 If there was an additional parameter in the mitigation request =E2=80=93 = e.g. =E2=80=9Cfilter-name: []=E2=80=9D to define which ACLs are to be = used, this would simplify a lot of things and give a greater degree of = flexibility should it be needed. =20 Once =E2=80=9Cfilter-name: []=E2=80=9D is in place, then conflicting = requests are much easier to resolve =E2=80=93 especially if the 2 = clients defining the filter have different client identifiers [I am = making a naive assumption that Client-1 and Client 2 are responsible for = a different set of IP addresses that the DOTS Server or GW client facing = side know about =E2=80=93 so white list filter for these set of IP and = black-list filter for those set of IPs]. If the 2 clients have the same =E2=80=9Cclient identifier=E2=80=9D, both = request mitigation with the same filter name, then a conflict needs to = be resolved. However, the last client to define/update the filter will = win I guess. =20 If the GW Server facing side passes on =E2=80=9Cfilter-name=E2=80=9D and = something like =E2=80=9Cextra-info: {string}=E2=80=9D (related to = Client-1 and Client-2), then the upstream DOTS server with the GW as its = client will also be able to simply sort out what to do. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 09 October 2017 14:35 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi Jon, =20 I agree the below problems are applicable for server-side DOTS gateway, = it must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. = But for the client-side DOTS gateway, it should resolve conflicting = rules b/w DOTS clients (e.g. one client installing black-list ACL for an = IP address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:07 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds = in =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru ------=_NextPart_000_0BE9_01D34114.CB909D40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I think part of the challenge here in our thinking is that a = mitigation request does not (cannot) ask for a specific ACL/Filter (or = set of ACLS) to be installed =E2=80=93 in a similar vein to the = mitigation request being able to call up a specific alias-name to be = used.

[You refer to =E2=80=9Cbut the = other client installs white-list ACL for the same IP address, same = alias-names for different mitigation scopes)=E2=80=9D below =E2=80=93 = however alias-names do not currently dictate which ACL to use as per = module: ietf-dots-data-channel-identifier.]

 

The current design appears to me is that the ACL/filter list is = defined on the DOTS Server (by a DOTS client or directly on the DOTS = Server) and you then get all the defined ACLs instantiated by DOTS = Mitigator =E2=80=93 for a single mitigation request.=C2=A0 Even if the = Filters are held on a per client basis, there no way to upload a set of = different filters in peace time ready for selection as to which is be = used in case of DDoS Attack.=C2=A0 White/Black lists are probably fairly = static, it is the customizable filters that are the issue currently for = me.

 

If there was an additional parameter in the mitigation request = =E2=80=93 e.g. =E2=80=9Cfilter-name: []=E2=80=9D to define which ACLs = are to be used, this would simplify a lot of things and give a greater = degree of flexibility should it be needed.

 

Once =C2=A0=E2=80=9Cfilter-name: []=E2=80=9D is in place, then = conflicting requests are much easier to resolve =E2=80=93 especially if = the 2 clients defining the filter have different client identifiers [I = am making a naive assumption that Client-1 and Client 2 are responsible = for a different set of IP addresses that the DOTS Server or GW client = facing side know about =E2=80=93 so white list filter for these set of = IP and black-list filter for those set of IPs].

If the 2 clients have the same =E2=80=9Cclient identifier=E2=80=9D, = both request mitigation with the same filter name, then a conflict needs = to be resolved.=C2=A0 However, the last client to define/update the = filter will win I guess.

 

If the GW Server facing side passes on =E2=80=9Cfilter-name=E2=80=9D = and something like =E2=80=9Cextra-info: {string}=E2=80=9D (related to = Client-1 and Client-2), then the upstream DOTS server with the GW as its = client will also be able to simply sort out what to = do.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 09 October 2017 14:35
To: Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi = Jon,

 =

I agree = the below problems are applicable for server-side DOTS gateway, it must = convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. But for = the client-side DOTS gateway, it should resolve conflicting rules b/w = DOTS clients (e.g. one client installing black-list ACL for an IP = address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server.

 =

-Tiru<= /o:p>

 =

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, October 7, 2017 2:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client.  =

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)     &nb= sp; The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)      = The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)     &nb= sp; The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely  associated with Client = Identity derived from the DOTS GW Client = certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).  This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.  The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.  Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:28
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 =

-Tiru<= /o:p>

 =

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, October 6, 2017 7:42 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= Konda, = Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 06 October 2017 14:58
To: = mohamed.boucadair@orange.com= ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: = [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 =

-Tiru

------=_NextPart_000_0BE9_01D34114.CB909D40-- From nobody Mon Oct 9 08:26:24 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E4B134621 for ; Mon, 9 Oct 2017 08:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 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_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 lOfSrmhYMqyu for ; Mon, 9 Oct 2017 08:26:19 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 781F513208E for ; Mon, 9 Oct 2017 08:19:19 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507562359; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=x vtkgAKhdKxcma2ZJsYMxtlk0khhad8QOoZ/xZsUEZ I=; b=PsD4dKqZVWGr+e9svaMkCsNqwWcWlq6bcr1BsmNF0i8S qZZeIlJLALT9QunyB+9+2F7T0yLFFs3qt5wRKpA8BO98J0i1Hf qgFo9yBFwvWfyen6cZLcVUcl/BSOsUxpkcz2b0ItJqTn9YfBM4 ifq1vBY/Fku09ry/YC7elR788Ag= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 4a48_33c0_b8c90575_82b2_4c0f_8809_ea879ff0a923; Mon, 09 Oct 2017 10:19:18 -0500 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 11:19:12 -0400 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 11:19:11 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Oct 2017 11:19:11 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 11:19:09 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 9 Oct 2017 15:19:09 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.019; Mon, 9 Oct 2017 15:19:09 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAACzkMAABuu0fgAAKB5IAAAO2RkA== Date: Mon, 9 Oct 2017 15:19:09 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <0be801d3410c$69ca1260$3d5e3720$@jpshallow.com> In-Reply-To: <0be801d3410c$69ca1260$3d5e3720$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.90.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:fABCa4/dQ4aA8/3Q7ztr/S0W7UqSyWUwJrxUhSeB8hnuyUEp6xsP87Wpp1rFstN0YcyJ6UOp5V9tnXqXDwmCRjthGRePORgEM5FOxwCABfKiykgXcOJdjJcqxVyewbiwX2DWlG1VhaenqFg5xxZ+5DliQDLFdlc795bwjX9uQwdGrRcNgbiyEqsTpUmTSE0ZGiDrHFxaqjrm4Hjgg+SiC0nyBt4P1eXKR4t7+RmuxKFoG6gzafM0WtGXMZHX99mBZ6IJABGa4hk9kylwkJn7q593sxtEHeZse/uLykBpDG24iKWhsq1TeZcHLi5FxVxTZD0VuHtbE9ds89o6uRLeog==; 5:IvmMYQIKz044AYJwH6mrVEszgwuxqnH5ug7H/wUCGxAGVYFbqVWPVxROLkfjTgdbmOriRoW9rDaCSfobHhVLeGAkCyciX6k0KlfwoOQSSsUAr2bBFt0d1fYx8UdHrHpJfxR3LpaFbyeXfa33mUazAUIh5Zct4DcLtxcm+bcSNR8=; 24:+rKYcxvf96S6sKL7YP/Kaz5Rkx43tHV8uo8EkXE9APsxwv2CSkzxmf16oCpjA7/yY9QdAuCgottm7nwj5/VHE8Ofemhb0dLq1AB+rwz/hgw=; 7:mRoMlmegTy5AlcjHp3idi20c7BY1aO/A2hNWCzG5Pd+Je83xTWBlODrqJqiFZpw6e4bDJGfHPL+5XD7Yeq1m51ugpKaQUoHEAKXAqLw2lBKOTQAhkyA1aeqCvSS1Zs+4OJrhO4+yktHER1OYklNR1HWLhNpDKPTqoEVFiN49ewnasGD/RQcoSHgC6FeO4aLzhT1vSnOmCHFwa4iubqzBnRtwIJBWrKInITZzHelN3Mg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bf26928b-85f9-4363-2f2b-08d50f2916b0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(199003)(377454003)(189002)(51444003)(32952001)(25786009)(68736007)(189998001)(77096006)(3660700001)(55016002)(2900100001)(76176999)(54356999)(101416001)(236005)(86362001)(2201001)(5660300001)(9326002)(6506006)(9686003)(33656002)(14454004)(229853002)(3280700002)(50986999)(2501003)(110136005)(53936002)(478600001)(790700001)(7696004)(316002)(74316002)(6306002)(54896002)(72206003)(7736002)(99286003)(2906002)(6116002)(3846002)(102836003)(80792005)(105586002)(2950100002)(53546010)(81156014)(81166006)(106356001)(6246003)(93886005)(8676002)(97736004)(19609705001)(66066001)(6436002)(8936002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178894FA808E65A98444BCA4EA740DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2017 15:19:09.0889 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6132> : inlines <6115> : streams <1766519> : uri <2513786> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 15:26:22 -0000 --_000_DM5PR16MB178894FA808E65A98444BCA4EA740DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uLA0KDQpQbGVhc2Ugc2VlIGlubGluZQ0KDQpGcm9tOiBKb24gU2hhbGxvdyBbbWFpbHRv OnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQpTZW50OiBNb25kYXksIE9jdG9iZXIgOSwgMjAx NyA4OjA5IFBNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IGRvdHNA aWV0Zi5vcmc7IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ+DQpTdWJqZWN0OiBS RTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSBUaXJ1LA0KDQpJIHRoaW5r IHBhcnQgb2YgdGhlIGNoYWxsZW5nZSBoZXJlIGluIG91ciB0aGlua2luZyBpcyB0aGF0IGEgbWl0 aWdhdGlvbiByZXF1ZXN0IGRvZXMgbm90IChjYW5ub3QpIGFzayBmb3IgYSBzcGVjaWZpYyBBQ0wv RmlsdGVyIChvciBzZXQgb2YgQUNMUykgdG8gYmUgaW5zdGFsbGVkIOKAkyBpbiBhIHNpbWlsYXIg dmVpbiB0byB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0IGJlaW5nIGFibGUgdG8gY2FsbCB1cCBhIHNw ZWNpZmljIGFsaWFzLW5hbWUgdG8gYmUgdXNlZC4NCltZb3UgcmVmZXIgdG8g4oCcYnV0IHRoZSBv dGhlciBjbGllbnQgaW5zdGFsbHMgd2hpdGUtbGlzdCBBQ0wgZm9yIHRoZSBzYW1lIElQIGFkZHJl c3MsIHNhbWUgYWxpYXMtbmFtZXMgZm9yIGRpZmZlcmVudCBtaXRpZ2F0aW9uIHNjb3BlcynigJ0g YmVsb3cg4oCTIGhvd2V2ZXIgYWxpYXMtbmFtZXMgZG8gbm90IGN1cnJlbnRseSBkaWN0YXRlIHdo aWNoIEFDTCB0byB1c2UgYXMgcGVyIG1vZHVsZTogaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC1pZGVu dGlmaWVyLl0NCg0KVGhlIGN1cnJlbnQgZGVzaWduIGFwcGVhcnMgdG8gbWUgaXMgdGhhdCB0aGUg QUNML2ZpbHRlciBsaXN0IGlzIGRlZmluZWQgb24gdGhlIERPVFMgU2VydmVyIChieSBhIERPVFMg Y2xpZW50IG9yIGRpcmVjdGx5IG9uIHRoZSBET1RTIFNlcnZlcikgYW5kIHlvdSB0aGVuIGdldCBh bGwgdGhlIGRlZmluZWQgQUNMcyBpbnN0YW50aWF0ZWQgYnkgRE9UUyBNaXRpZ2F0b3Ig4oCTIGZv ciBhIHNpbmdsZSBtaXRpZ2F0aW9uIHJlcXVlc3QuDQoNCltUUl0gTm8sIGJsYWNrLWxpc3QgYW5k IHdoaXRlLWxpc3QgcnVsZXMgY3JlYXRlZCB1c2luZyB0aGUgRE9UUyBkYXRhIGNoYW5uZWwgaGF2 ZSBubyBkZXBlbmRlbmN5IG9uIGNvbnZleWluZyB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0IGluIHRo ZSBET1RTIHNpZ25hbCBjaGFubmVsIChZb3UgbWF5IHdhbnQgdG8gbG9vayBpbnRvIHRoZSBET1RT IHJlcXVpcmVtZW50cyBhbmQgYXJjaGl0ZWN0dXJlIGRyYWZ0cykuDQoNCkV2ZW4gaWYgdGhlIEZp bHRlcnMgYXJlIGhlbGQgb24gYSBwZXIgY2xpZW50IGJhc2lzLCB0aGVyZSBubyB3YXkgdG8gdXBs b2FkIGEgc2V0IG9mIGRpZmZlcmVudCBmaWx0ZXJzIGluIHBlYWNlIHRpbWUgcmVhZHkgZm9yIHNl bGVjdGlvbiBhcyB0byB3aGljaCBpcyBiZSB1c2VkIGluIGNhc2Ugb2YgRERvUyBBdHRhY2suICBX aGl0ZS9CbGFjayBsaXN0cyBhcmUgcHJvYmFibHkgZmFpcmx5IHN0YXRpYywgaXQgaXMgdGhlIGN1 c3RvbWl6YWJsZSBmaWx0ZXJzIHRoYXQgYXJlIHRoZSBpc3N1ZSBjdXJyZW50bHkgZm9yIG1lLg0K DQpbVFJdIFRoaXMgaXMgYSBuZXcgcmVxdWlyZW1lbnQgYW5kIG5lZWRzIHRvIGJlIGRpc2N1c3Nl ZC4NCg0KLVRpcnUNCg0KSWYgdGhlcmUgd2FzIGFuIGFkZGl0aW9uYWwgcGFyYW1ldGVyIGluIHRo ZSBtaXRpZ2F0aW9uIHJlcXVlc3Qg4oCTIGUuZy4g4oCcZmlsdGVyLW5hbWU6IFtd4oCdIHRvIGRl ZmluZSB3aGljaCBBQ0xzIGFyZSB0byBiZSB1c2VkLCB0aGlzIHdvdWxkIHNpbXBsaWZ5IGEgbG90 IG9mIHRoaW5ncyBhbmQgZ2l2ZSBhIGdyZWF0ZXIgZGVncmVlIG9mIGZsZXhpYmlsaXR5IHNob3Vs ZCBpdCBiZSBuZWVkZWQuDQoNCk9uY2UgIOKAnGZpbHRlci1uYW1lOiBbXeKAnSBpcyBpbiBwbGFj ZSwgdGhlbiBjb25mbGljdGluZyByZXF1ZXN0cyBhcmUgbXVjaCBlYXNpZXIgdG8gcmVzb2x2ZSDi gJMgZXNwZWNpYWxseSBpZiB0aGUgMiBjbGllbnRzIGRlZmluaW5nIHRoZSBmaWx0ZXIgaGF2ZSBk aWZmZXJlbnQgY2xpZW50IGlkZW50aWZpZXJzIFtJIGFtIG1ha2luZyBhIG5haXZlIGFzc3VtcHRp b24gdGhhdCBDbGllbnQtMSBhbmQgQ2xpZW50IDIgYXJlIHJlc3BvbnNpYmxlIGZvciBhIGRpZmZl cmVudCBzZXQgb2YgSVAgYWRkcmVzc2VzIHRoYXQgdGhlIERPVFMgU2VydmVyIG9yIEdXIGNsaWVu dCBmYWNpbmcgc2lkZSBrbm93IGFib3V0IOKAkyBzbyB3aGl0ZSBsaXN0IGZpbHRlciBmb3IgdGhl c2Ugc2V0IG9mIElQIGFuZCBibGFjay1saXN0IGZpbHRlciBmb3IgdGhvc2Ugc2V0IG9mIElQc10u DQpJZiB0aGUgMiBjbGllbnRzIGhhdmUgdGhlIHNhbWUg4oCcY2xpZW50IGlkZW50aWZpZXLigJ0s IGJvdGggcmVxdWVzdCBtaXRpZ2F0aW9uIHdpdGggdGhlIHNhbWUgZmlsdGVyIG5hbWUsIHRoZW4g YSBjb25mbGljdCBuZWVkcyB0byBiZSByZXNvbHZlZC4gIEhvd2V2ZXIsIHRoZSBsYXN0IGNsaWVu dCB0byBkZWZpbmUvdXBkYXRlIHRoZSBmaWx0ZXIgd2lsbCB3aW4gSSBndWVzcy4NCg0KSWYgdGhl IEdXIFNlcnZlciBmYWNpbmcgc2lkZSBwYXNzZXMgb24g4oCcZmlsdGVyLW5hbWXigJ0gYW5kIHNv bWV0aGluZyBsaWtlIOKAnGV4dHJhLWluZm86IHtzdHJpbmd94oCdIChyZWxhdGVkIHRvIENsaWVu dC0xIGFuZCBDbGllbnQtMiksIHRoZW4gdGhlIHVwc3RyZWFtIERPVFMgc2VydmVyIHdpdGggdGhl IEdXIGFzIGl0cyBjbGllbnQgd2lsbCBhbHNvIGJlIGFibGUgdG8gc2ltcGx5IHNvcnQgb3V0IHdo YXQgdG8gZG8uDQoNClJlZ2FyZHMNCg0KSm9uDQoNCkZyb206IERvdHMgW21haWx0bzogZG90cy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg T2YgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KU2VudDogMDkgT2N0b2JlciAyMDE3IDE0OjM1 DQpUbzogSm9uIFNoYWxsb3c7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGll dGYub3JnPjsgUm9sYW5kIERvYmJpbnMNClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBHYXRld2F5 cyBDaGFsbGVuZ2VzDQoNCkhpIEpvbiwNCg0KSSBhZ3JlZSB0aGUgYmVsb3cgcHJvYmxlbXMgYXJl IGFwcGxpY2FibGUgZm9yIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgbXVzdCBjb252ZXkg dGhlIOKAnGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIEJ1dCBmb3IgdGhl IGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgc2hvdWxkIHJlc29sdmUgY29uZmxpY3Rpbmcg cnVsZXMgYi93IERPVFMgY2xpZW50cyAoZS5nLiBvbmUgY2xpZW50IGluc3RhbGxpbmcgYmxhY2st bGlzdCBBQ0wgZm9yIGFuIElQIGFkZHJlc3MgYnV0IHRoZSBvdGhlciBjbGllbnQgaW5zdGFsbHMg d2hpdGUtbGlzdCBBQ0wgZm9yIHRoZSBzYW1lIElQIGFkZHJlc3MsIHNhbWUgYWxpYXMtbmFtZXMg Zm9yIGRpZmZlcmVudCBtaXRpZ2F0aW9uIHNjb3BlcykuIEkgZG9u4oCZdCBzZWUgdGhlIG5lZWQg Zm9yIGEgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcY2xpZW50IGlk ZW50aXR54oCdIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgb3IgRE9UUyBzZXJ2ZXIu DQoNCi1UaXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFs bG93LmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDcsIDIwMTcgMjowNyBQTQ0KVG86IEtv bmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5j b208bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PjsgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47 IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucyA8cmRv YmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0KU3ViamVjdDogUkU6 IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KVGhpcyBkaXNj dXNzaW9uIGdvZXMgYmV5b25kIGp1c3QgdGhlIG1pdGlnYXRpb24gcmVxdWVzdC4gIFdlIG5lZWQg dG8gY29uc2lkZXIgd2hhdCBoYXBwZW5zIHdpdGggYm90aCBhbGlhcy1uYW1lIGFuZCBhY2wtbmFt ZSAoZGF0YSBjaGFubmVsKQ0KDQpUaGUgc2ltcGxlIGNhc2Ugb2YgYSBtaXRpZ2F0aW9uIHJlcXVl c3Qgd2l0aCBubyBhbGlhcy1uYW1lIGRvZXMgbm90IHJlcXVpcmUgYW55IGtub3dsZWRnZSBvZiB0 aGUgb3JpZ2luYWwgY2xpZW50Lg0KDQpIb3dldmVyLCBpZiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0 IHVzZXMgYWxpYXMtbmFtZSwgdGhlbiB0aGVyZSBhcmUgMyB3YXlzIG9mIGhhbmRsaW5nIHRoaXMN Cg0KYSkgICAgICAgVGhlIERPVFMgR1cgcmVwbGFjZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBpdHMg YWN0dWFsIGRlZmluaXRpb24gKHRhcmdldC1pcHMgZXRjLiBtZXJnZWQgYXMgYXBwcm9wcmlhdGUp LCBzbyBhbGlhcy1uYW1lIGlzIG5vdCBmb3J3YXJkZWQgb24gdG8gU2VydmVyIOKAkyBqdXN0IHRo ZSBleHBhbmRlZCBtaXRpZ2F0aW9uIHJlcXVlc3QgaXMgZm9yd2FyZGVkDQoNCmIpICAgICAgVGhl IERPVFMgR1cgdXBkYXRlcyB0aGUgYWxpYXMtbmFtZSB3aXRoIGEgdW5pcXVlIGFsaWFzLW5hbWUg dGhhdCBpcyBmb3J3YXJkZWQgKGFuZCBoYXMgdG8gZG8gdGhlIHNhbWUgdGhpbmcgd2hlbiB0aGUg YWxpYXMtbmFtZSBpcyBjb25maWd1cmVkIG9uIHRoZSBkYXRhIGNoYW5uZWwpIOKAkyB0byBoYW5k bGUgMiBvciBtb3JlIGNsaWVudHMgZGVmaW5pbmcgdGhlIHNhbWUgYWxpYXMtbmFtZSB3aGljaCBo YXZlIGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3MNCg0KYykgICAgICAgVGhlIERPVFMgR1cgcmVj b2duaXNlcyB0aGF0IGFsaWFzLW5hbWUgaXMgbm90IHVuaXF1ZSBhbmQgYWRkcyBpbiDigJ1hZGRp dGlvbmFsLWNsaWVudC1pbmZv4oCdIChJIHRoaW5rIEkgcHJlZmVyIHRoaXMg4oCcLWluZm/igJ0g bmFtZSB0byBjbGllbnQtaWQgb3Igb3JpZ2luYWwtY2xpZW50LWlkIGFzIOKAnC1pZOKAnSBpcyB0 b28gY2xvc2VseSAgYXNzb2NpYXRlZCB3aXRoIENsaWVudCBJZGVudGl0eSBkZXJpdmVkIGZyb20g dGhlIERPVFMgR1cgQ2xpZW50IGNlcnRpZmljYXRlKQ0KV2UgaGF2ZSBhZ3JlZWQgdGhhdCB3aGVu IGEgY2xpZW50IHJlcXVlc3RzIG1pdGlnYXRpb24gc3RhdHVzLCB0aGUg4oCcYWxpYXMtbmFtZeKA nSBzaG91bGQgYmUgcmV0dXJuZWQgYXMg4oCcYWxpYXMtbmFtZeKAnSBhbmQgbm90IHRoZSBzdWJz dGl0dXRlZCBhbGlhcy1uYW1lIGNvbmZpZ3VyYXRpb24gKHRoaXMgZG9lcyBuZWVkIHRvIGJlIHN0 YXRlZCBpbiB0aGUgc3BlYyBmb3IgY2xhcml0eSkuICBUaGlzIG1ha2VzIChhKSBkaWZmaWN1bHQg dG8gYmUgaGFuZGxlZCBieSBET1RTIEdXIHdoaWNoIHRoZW4gcmFpc2VzIHRoZSBxdWVzdGlvbiDi gJMgZG8gd2UgcmVhbGx5IG5lZWQgYWxpYXMtbmFtZT8NCg0KVGhlIGRlZmluaXRpb24gYW5kIGFz c29jaWF0aW9uIG9mIEFDTHMvRmlsdGVycyBvZiB0aGUgZGF0YSBjaGFubmVsIGlzIG1vcmUgZGlm ZmljdWx0IOKAkyB0aGUgU2VydmVyIG11c3QgaW5zdGFsbCAvIGFwcGx5IHRoZSBhcHByb3ByaWF0 ZSBBQ0xzIG9uIGEgcGVyIChPcmlnaW5hbCkgQ2xpZW50IGJhc2lzIHdoZW4gbWl0aWdhdGlvbiBp cyBpbnZva2VkLg0KQ2xpZW50IDHigJlzIGNvbmNlcHQgb2YgYSBXaGl0ZWxpc3QgSVAgY291bGQg YmUgQ2xpZW50IDLigJlzIGNvbmNlcHQgb2YgYSBCbGFja2xpc3QgSVAuICBUaGUgU2VydmVyIG5l ZWRzIHRvIGtub3cgd2hpY2ggY2xpZW50IGlzIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24gYW5k IGluc3RhbGwgdGhlIGNvcnJlY3QgQUNMcyDigJMgaWYgdGhlcmUgd2FzIG5vIOKAnWFkZGl0aW9u YWwtY2xpZW50LWluZm/igJ0sIHRoZSBTZXJ2ZXIgb25seSBrbm93cyB0aGF0IGhlIGhhcyB0byBp bnN0YWxsIEFMTCBvZiB0aGUgQUNMcyAoaS5lLiBib3RoIHRoZSBCbGFjayBhbmQgV2hpdGUgbGlz dCBvZiB0aGUgc2FtZSBJUCBhcyBkZWZpbmVkIGJ5IENsaWVudCAxIGFuZCBDbGllbnQgMikgYXMg ZGVmaW5lZCBieSBoaXMgY2xpZW50IChET1RTIEdXKSB3aGVuIGhpcyBjbGllbnQgcmVxdWVzdHMg YSBtaXRpZ2F0aW9uLiAgSGVyZSwgSSB0aGluayB0aGF0IGlmIHRoZXJlIGlzIG1vcmUgdGhhbiBv bmUgY2xpZW50IGZvciB0aGUgRE9UUyBHVywg4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSBp cyByZXF1aXJlZC4NCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFpbHRvOiBkb3Rz LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAwNyBPY3RvYmVyIDIwMTcgMDQ6 MjgNClRvOiBKb24gU2hhbGxvdzsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNA aWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucw0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTIEdhdGV3 YXlzIENoYWxsZW5nZXMNCg0KSW4gY2FzZSBvZiBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksIHdo eSBkb2VzIHRoZSBET1RTIHNlcnZlciBuZWVkIHRvIGtub3cgd2hpY2gg4oCcRE9UUyBjbGllbnTi gJ0gaGFzIGNvbnZleWVkIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgPw0KRm9yIGV4YW1wbGUsIHRo ZSBET1RTIGNsaWVudCBjb3VsZCBiZSBhIEREb1MgZGV0ZWN0b3Igb3IgYW4gQXBwbGljYXRpb24g c2VydmVyLCBhbmQgdGhlIGNsaWVudC1zaWRlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHJlc29sdmUg dGhlIGNvbmZsaWN0aW5nIG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBjbGllbnRz LCBhZ2dyZWdhdGUgdGhlIG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBjbGllbnQg YW5kIHNlbmQgdGhlIHVwZGF0ZWQgbWl0aWdhdGlvbiByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZl ci4NCg0KLVRpcnUNCg0KRnJvbTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNo YWxsb3cuY29tXQ0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDYsIDIwMTcgNzo0MiBQTQ0KVG86IEtv bmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5j b208bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PjsgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47 IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucyA8cmRv YmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0KU3ViamVjdDogUkU6 IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KVW5sZXNzIEkg YW0gbWlzc2luZyBzb21ldGhpbmcsIGhvdyBkb2VzIHRoZSBDbGllbnQgc2lkZSBvZiBET1RTIEdX IGNvbnZleSB0byB0aGUgdXBzdHJlYW0gc2VydmVyIGEgdW5pcXVlIOKAnGNsaWVudC1pZOKAnSB3 aGljaCBpcyBkaWZmZXJlbnQgdG8gdGhlIGltcGxpZWQgY2xpZW50IGlkIGFzIGRlcml2ZWQgZnJv bSB0aGUgUEtJIGNlcnRpZmljYXRlIHRoYXQgdGhlIERPVFMgR1figJlDbGllbnQgdXNlcy9wcmVz ZW50cyB3aGVuIGNvbW11bmljYXRpbmcgdG8gdGhlIHNlcnZlcj8NClRvIG1lLCB0aGVyZSBuZWVk cyB0byBiZSBhbiBvcHRpb24gc3VjaCBhcyDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0gb3Ig4oCc Y2xpZW50LWlk4oCdICh3aGljaCBpcyBjb25mdXNpbmcgd2hlbiBhbHNvIHJlZmVycmluZyB0byB0 aGUgY2xpZW50IGlkZW50aXR5IGFzIGRlcml2ZWQgZnJvbSB0aGUgKERPVFMgR1cpIENsaWVudOKA mXMgUEtJIGNlcnRpZmljYXRlKSBhcyBhIHBhcnQgb2YgdGhlIHByb3RvY29sLg0KDQpJIGFncmVl IHRoYXQgdGhlIERPVFMgR1cgY2FuIGdlbmVyYXRlIGl0cyBvd24gdW5pcXVlIGNsaWVudC1pZCB0 byBzdG9wIG11bHRpcGxlIGVudHJpZXMgYmVpbmcgbmVlZGVkLg0KDQpJIGFncmVlIHRoYXQgaXMg bm90IGEgZ29vZCB0aGluZyB0byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1hdGlvbiB3 aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR1csIHNvIG15IFJFUVVJUkVEIGRvZXMgbm90IG1h a2Ugc2Vuc2UuDQoNClJlZ2FyZHMNCg0KSm9uDQpQUyDigJMgSSBhbSBoYXZpbmcgdG8gZGVhbCB3 aXRoIG90aGVyIHN0dWZmIGF0IHByZXNlbnQg4oCTIEkgd2lsbCBnZXQgYmFjayBsYXRlciBvbiB0 aGUgb3RoZXIgaXNzdWVzIHVuZGVyIGRpc2N1c3Npb24NCg0KRnJvbTogS29uZGEsIFRpcnVtYWxl c3dhciBSZWRkeSBbbWFpbHRvOiBUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPG1h aWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPl0NClNlbnQ6IDA2IE9jdG9i ZXIgMjAxNyAxNDo1OA0KVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBKb24gU2hhbGxvdzsgJ0RvYmJpbnMsIFJvbGFu ZCc7IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0Rv dHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpJIGRvbuKAmXQgc2VlIGEgbmVlZCBmb3Ig Y2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcRE9UUyBjbGllbnQgaWRl bnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSBs b29rcyByZXF1aXJlZCBvbmx5IGZvciB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5cy4gSW4g Y2FzZSBvZiBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IGNhbiBjb252ZXkgdGhlIGNsaWVu dC1pZCBnZW5lcmF0ZWQgZnJvbSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhl IERPVFMgc2VydmVyLiBUaGUgRE9UUyBnYXRld2F5IGNhbiBnZW5lcmF0ZSBhIHVuaXF1ZSBjbGll bnQtaWQgYW5kIGRvZXMgbm90IGhhdmUgdG8gc2VuZCBhbiBhcnJheSBvZiBjbGllbnQtaWRzIHRv IHRoZSBET1RTIHNlcnZlciB0byByZXNvbHZlIGNsYXNoZXMuDQoNCi1UaXJ1DQo= --_000_DM5PR16MB178894FA808E65A98444BCA4EA740DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIg MiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs c2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1s ZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkJhbGxvb25UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWls eToiU2Vnb2UgVUkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1z dHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsc2Fucy1zZXJpZjt9DQpwLlRleHRlZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5U ZXh0ZWRlYnVsbGVzDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1z dHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBKb24sPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPlBsZWFzZSBzZWUgaW5saW5lDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEpvbiBTaGFsbG93 IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIE9jdG9iZXIgOSwgMjAxNyA4OjA5IFBNPGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGly dW1hbGVzd2FyIFJlZGR5ICZsdDtUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tJmd0 OzsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgZG90c0BpZXRmLm9yZzsgUm9sYW5kIERv YmJpbnMgJmx0O3Jkb2JiaW5zQGFyYm9yLm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkhpIFRpcnUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgcGFydCBvZiB0aGUgY2hhbGxl bmdlIGhlcmUgaW4gb3VyIHRoaW5raW5nIGlzIHRoYXQgYSBtaXRpZ2F0aW9uIHJlcXVlc3QgZG9l cyBub3QgKGNhbm5vdCkgYXNrIGZvciBhIHNwZWNpZmljIEFDTC9GaWx0ZXIgKG9yIHNldCBvZiBB Q0xTKQ0KIHRvIGJlIGluc3RhbGxlZCDigJMgaW4gYSBzaW1pbGFyIHZlaW4gdG8gdGhlIG1pdGln YXRpb24gcmVxdWVzdCBiZWluZyBhYmxlIHRvIGNhbGwgdXAgYSBzcGVjaWZpYyBhbGlhcy1uYW1l IHRvIGJlIHVzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bWW91IHJlZmVyIHRv IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmJ1dCB0aGUgb3RoZXIgY2xpZW50IGluc3RhbGxz IHdoaXRlLWxpc3QgQUNMIGZvciB0aGUgc2FtZSBJUA0KIGFkZHJlc3MsIHNhbWUgYWxpYXMtbmFt ZXMgZm9yIGRpZmZlcmVudCBtaXRpZ2F0aW9uIHNjb3BlcynigJ0gYmVsb3cg4oCTIGhvd2V2ZXIg YWxpYXMtbmFtZXMgZG8gbm90IGN1cnJlbnRseSBkaWN0YXRlIHdoaWNoIEFDTCB0byB1c2UgYXMg cGVyIG1vZHVsZTogaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC1pZGVudGlmaWVyLl08L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhl IGN1cnJlbnQgZGVzaWduIGFwcGVhcnMgdG8gbWUgaXMgdGhhdCB0aGUgQUNML2ZpbHRlciBsaXN0 IGlzIGRlZmluZWQgb24gdGhlIERPVFMgU2VydmVyIChieSBhIERPVFMgY2xpZW50IG9yIGRpcmVj dGx5IG9uIHRoZSBET1RTIFNlcnZlcikgYW5kDQogeW91IHRoZW4gZ2V0IGFsbCB0aGUgZGVmaW5l ZCBBQ0xzIGluc3RhbnRpYXRlZCBieSBET1RTIE1pdGlnYXRvciDigJMgZm9yIGEgc2luZ2xlIG1p dGlnYXRpb24gcmVxdWVzdC4mbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bVFJdIE5vLCBi bGFjay1saXN0IGFuZCB3aGl0ZS1saXN0IHJ1bGVzIGNyZWF0ZWQgdXNpbmcgdGhlIERPVFMgZGF0 YSBjaGFubmVsIGhhdmUgbm8gZGVwZW5kZW5jeSBvbiBjb252ZXlpbmcgdGhlIG1pdGlnYXRpb24g cmVxdWVzdCBpbiB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbA0KIChZb3UgbWF5IHdhbnQgdG8gbG9v ayBpbnRvIHRoZSBET1RTIHJlcXVpcmVtZW50cyBhbmQgYXJjaGl0ZWN0dXJlIGRyYWZ0cykuICZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+RXZlbiBpZiB0aGUgRmlsdGVycyBhcmUgaGVsZCBvbiBhIHBlciBjbGllbnQgYmFzaXMsIHRo ZXJlIG5vIHdheSB0byB1cGxvYWQgYSBzZXQgb2YgZGlmZmVyZW50IGZpbHRlcnMgaW4gcGVhY2Ug dGltZSByZWFkeSBmb3Igc2VsZWN0aW9uIGFzIHRvIHdoaWNoDQogaXMgYmUgdXNlZCBpbiBjYXNl IG9mIEREb1MgQXR0YWNrLiZuYnNwOyBXaGl0ZS9CbGFjayBsaXN0cyBhcmUgcHJvYmFibHkgZmFp cmx5IHN0YXRpYywgaXQgaXMgdGhlIGN1c3RvbWl6YWJsZSBmaWx0ZXJzIHRoYXQgYXJlIHRoZSBp c3N1ZSBjdXJyZW50bHkgZm9yIG1lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+W1RSXSBUaGlzIGlzIGEgbmV3IHJlcXVpcmVtZW50IGFuZCBuZWVkcyB0byBiZSBk aXNjdXNzZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tVGly dTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5JZiB0aGVyZSB3YXMgYW4gYWRkaXRpb25hbCBwYXJhbWV0ZXIgaW4gdGhl IG1pdGlnYXRpb24gcmVxdWVzdCDigJMgZS5nLiDigJxmaWx0ZXItbmFtZTogW13igJ0gdG8gZGVm aW5lIHdoaWNoIEFDTHMgYXJlIHRvIGJlIHVzZWQsIHRoaXMgd291bGQgc2ltcGxpZnkNCiBhIGxv dCBvZiB0aGluZ3MgYW5kIGdpdmUgYSBncmVhdGVyIGRlZ3JlZSBvZiBmbGV4aWJpbGl0eSBzaG91 bGQgaXQgYmUgbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbmNlICZuYnNwO+KAnGZpbHRlci1uYW1lOiBb XeKAnSBpcyBpbiBwbGFjZSwgdGhlbiBjb25mbGljdGluZyByZXF1ZXN0cyBhcmUgbXVjaCBlYXNp ZXIgdG8gcmVzb2x2ZSDigJMgZXNwZWNpYWxseSBpZiB0aGUgMiBjbGllbnRzIGRlZmluaW5nIHRo ZSBmaWx0ZXIgaGF2ZQ0KIGRpZmZlcmVudCBjbGllbnQgaWRlbnRpZmllcnMgW0kgYW0gbWFraW5n IGEgbmFpdmUgYXNzdW1wdGlvbiB0aGF0IENsaWVudC0xIGFuZCBDbGllbnQgMiBhcmUgcmVzcG9u c2libGUgZm9yIGEgZGlmZmVyZW50IHNldCBvZiBJUCBhZGRyZXNzZXMgdGhhdCB0aGUgRE9UUyBT ZXJ2ZXIgb3IgR1cgY2xpZW50IGZhY2luZyBzaWRlIGtub3cgYWJvdXQg4oCTIHNvIHdoaXRlIGxp c3QgZmlsdGVyIGZvciB0aGVzZSBzZXQgb2YgSVAgYW5kIGJsYWNrLWxpc3QgZmlsdGVyDQogZm9y IHRob3NlIHNldCBvZiBJUHNdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgdGhl IDIgY2xpZW50cyBoYXZlIHRoZSBzYW1lIOKAnGNsaWVudCBpZGVudGlmaWVy4oCdLCBib3RoIHJl cXVlc3QgbWl0aWdhdGlvbiB3aXRoIHRoZSBzYW1lIGZpbHRlciBuYW1lLCB0aGVuIGEgY29uZmxp Y3QgbmVlZHMgdG8gYmUgcmVzb2x2ZWQuJm5ic3A7IEhvd2V2ZXIsDQogdGhlIGxhc3QgY2xpZW50 IHRvIGRlZmluZS91cGRhdGUgdGhlIGZpbHRlciB3aWxsIHdpbiBJIGd1ZXNzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JZiB0aGUgR1cgU2VydmVyIGZhY2luZyBzaWRlIHBhc3NlcyBvbiDigJxmaWx0ZXItbmFtZeKA nSBhbmQgc29tZXRoaW5nIGxpa2Ug4oCcZXh0cmEtaW5mbzoge3N0cmluZ33igJ0gKHJlbGF0ZWQg dG8gQ2xpZW50LTEgYW5kIENsaWVudC0yKSwgdGhlbiB0aGUgdXBzdHJlYW0NCiBET1RTIHNlcnZl ciB3aXRoIHRoZSBHVyBhcyBpdHMgY2xpZW50IHdpbGwgYWxzbyBiZSBhYmxlIHRvIHNpbXBseSBz b3J0IG91dCB3aGF0IHRvIGRvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBEb3Rz IFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5kb3RzLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Lb25kYSwgVGlydW1hbGVz d2FyIFJlZGR5PGJyPg0KPGI+U2VudDo8L2I+IDA5IE9jdG9iZXIgMjAxNyAxNDozNTxicj4NCjxi PlRvOjwvYj4gSm9uIFNoYWxsb3c7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsNCjxhIGhyZWY9Im1h aWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnM8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgSm9uLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGFn cmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJsZSBmb3Igc2VydmVyLXNpZGUgRE9U UyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRo ZSBET1RTIHNlcnZlci4gQnV0IGZvciB0aGUgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5LCBpdCBz aG91bGQNCiByZXNvbHZlIGNvbmZsaWN0aW5nIHJ1bGVzIGIvdyBET1RTIGNsaWVudHMgKGUuZy4g b25lIGNsaWVudCBpbnN0YWxsaW5nIGJsYWNrLWxpc3QgQUNMIGZvciBhbiBJUCBhZGRyZXNzIGJ1 dCB0aGUgb3RoZXIgY2xpZW50IGluc3RhbGxzIHdoaXRlLWxpc3QgQUNMIGZvciB0aGUgc2FtZSBJ UCBhZGRyZXNzLCBzYW1lIGFsaWFzLW5hbWVzIGZvciBkaWZmZXJlbnQgbWl0aWdhdGlvbiBzY29w ZXMpLiBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkIGZvciBhIGNsaWVudC1zaWRlDQogRE9UUyBnYXRl d2F5IHRvIGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBzZXJ2ZXItc2lk ZSBET1RTIGdhdGV3YXkgb3IgRE9UUyBzZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi1UaXJ1PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEpvbiBTaGFs bG93IFs8YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+bWFpbHRvOnN1 cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5 LCBPY3RvYmVyIDcsIDIwMTcgMjowNyBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxl c3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1j QWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+Jmd0OzsNCjxh IGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPg0KZG90 c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJp bnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SGkgVGlydSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBkaXNjdXNzaW9uIGdv ZXMgYmV5b25kIGp1c3QgdGhlIG1pdGlnYXRpb24gcmVxdWVzdC4mbmJzcDsgV2UgbmVlZCB0byBj b25zaWRlciB3aGF0IGhhcHBlbnMgd2l0aCBib3RoIGFsaWFzLW5hbWUgYW5kIGFjbC1uYW1lIChk YXRhIGNoYW5uZWwpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBzaW1wbGUgY2FzZSBvZiBhIG1pdGlnYXRpb24g cmVxdWVzdCB3aXRoIG5vIGFsaWFzLW5hbWUgZG9lcyBub3QgcmVxdWlyZSBhbnkga25vd2xlZGdl IG9mIHRoZSBvcmlnaW5hbCBjbGllbnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgaWYg dGhlIG1pdGlnYXRpb24gcmVxdWVzdCB1c2VzIGFsaWFzLW5hbWUsIHRoZW4gdGhlcmUgYXJlIDMg d2F5cyBvZiBoYW5kbGluZyB0aGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGUgRE9UUyBHVyByZXBsYWNlcyB0aGUgYWxpYXMtbmFtZSB3aXRoIGl0 cyBhY3R1YWwgZGVmaW5pdGlvbiAodGFyZ2V0LWlwcyBldGMuIG1lcmdlZCBhcyBhcHByb3ByaWF0 ZSksIHNvIGFsaWFzLW5hbWUgaXMgbm90IGZvcndhcmRlZCBvbiB0byBTZXJ2ZXIg4oCTIGp1c3Qg dGhlDQogZXhwYW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGZvcndhcmRlZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmIp PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIERPVFMgR1cgdXBkYXRlcyB0aGUg YWxpYXMtbmFtZSB3aXRoIGEgdW5pcXVlIGFsaWFzLW5hbWUgdGhhdCBpcyBmb3J3YXJkZWQgKGFu ZCBoYXMgdG8gZG8gdGhlIHNhbWUgdGhpbmcgd2hlbiB0aGUgYWxpYXMtbmFtZSBpcyBjb25maWd1 cmVkIG9uIHRoZSBkYXRhIGNoYW5uZWwpDQog4oCTIHRvIGhhbmRsZSAyIG9yIG1vcmUgY2xpZW50 cyBkZWZpbmluZyB0aGUgc2FtZSBhbGlhcy1uYW1lIHdoaWNoIGhhdmUgZGlmZmVyZW50IGNoYXJh Y3RlcmlzdGljczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPmMpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGhlIERPVFMgR1cgcmVjb2duaXNlcyB0aGF0IGFsaWFzLW5hbWUgaXMgbm90IHVuaXF1ZSBh bmQgYWRkcyBpbiDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdIChJIHRoaW5rIEkgcHJlZmVy IHRoaXMg4oCcLWluZm/igJ0gbmFtZSB0byBjbGllbnQtaWQgb3Igb3JpZ2luYWwtY2xpZW50LWlk DQogYXMg4oCcLWlk4oCdIGlzIHRvbyBjbG9zZWx5ICZuYnNwO2Fzc29jaWF0ZWQgd2l0aCBDbGll bnQgSWRlbnRpdHkgZGVyaXZlZCBmcm9tIHRoZSBET1RTIEdXIENsaWVudCBjZXJ0aWZpY2F0ZSk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIGhhdmUgYWdyZWVkIHRoYXQgd2hlbiBh IGNsaWVudCByZXF1ZXN0cyBtaXRpZ2F0aW9uIHN0YXR1cywgdGhlIOKAnGFsaWFzLW5hbWXigJ0g c2hvdWxkIGJlIHJldHVybmVkIGFzIOKAnGFsaWFzLW5hbWXigJ0gYW5kIG5vdCB0aGUgc3Vic3Rp dHV0ZWQgYWxpYXMtbmFtZQ0KIGNvbmZpZ3VyYXRpb24gKHRoaXMgZG9lcyBuZWVkIHRvIGJlIHN0 YXRlZCBpbiB0aGUgc3BlYyBmb3IgY2xhcml0eSkuJm5ic3A7IFRoaXMgbWFrZXMgKGEpIGRpZmZp Y3VsdCB0byBiZSBoYW5kbGVkIGJ5IERPVFMgR1cgd2hpY2ggdGhlbiByYWlzZXMgdGhlIHF1ZXN0 aW9uIOKAkyBkbyB3ZSByZWFsbHkgbmVlZCBhbGlhcy1uYW1lPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZGVm aW5pdGlvbiBhbmQgYXNzb2NpYXRpb24gb2YgQUNMcy9GaWx0ZXJzIG9mIHRoZSBkYXRhIGNoYW5u ZWwgaXMgbW9yZSBkaWZmaWN1bHQg4oCTIHRoZSBTZXJ2ZXIgbXVzdCBpbnN0YWxsIC8gYXBwbHkg dGhlIGFwcHJvcHJpYXRlIEFDTHMgb24gYQ0KIHBlciAoT3JpZ2luYWwpIENsaWVudCBiYXNpcyB3 aGVuIG1pdGlnYXRpb24gaXMgaW52b2tlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkNsaWVudCAx4oCZcyBjb25jZXB0IG9mIGEgV2hpdGVsaXN0IElQIGNvdWxkIGJlIENsaWVudCAy 4oCZcyBjb25jZXB0IG9mIGEgQmxhY2tsaXN0IElQLiZuYnNwOyBUaGUgU2VydmVyIG5lZWRzIHRv IGtub3cgd2hpY2ggY2xpZW50IGlzIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24NCiBhbmQgaW5z dGFsbCB0aGUgY29ycmVjdCBBQ0xzIOKAkyBpZiB0aGVyZSB3YXMgbm8g4oCdYWRkaXRpb25hbC1j bGllbnQtaW5mb+KAnSwgdGhlIFNlcnZlciBvbmx5IGtub3dzIHRoYXQgaGUgaGFzIHRvIGluc3Rh bGwgQUxMIG9mIHRoZSBBQ0xzIChpLmUuIGJvdGggdGhlIEJsYWNrIGFuZCBXaGl0ZSBsaXN0IG9m IHRoZSBzYW1lIElQIGFzIGRlZmluZWQgYnkgQ2xpZW50IDEgYW5kIENsaWVudCAyKSBhcyBkZWZp bmVkIGJ5IGhpcyBjbGllbnQgKERPVFMgR1cpDQogd2hlbiBoaXMgY2xpZW50IHJlcXVlc3RzIGEg bWl0aWdhdGlvbi4mbmJzcDsgSGVyZSwgSSB0aGluayB0aGF0IGlmIHRoZXJlIGlzIG1vcmUgdGhh biBvbmUgY2xpZW50IGZvciB0aGUgRE9UUyBHVywg4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KA nSBpcyByZXF1aXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Kb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gRG90cyBbbWFp bHRvOg0KPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+ZG90cy1ib3VuY2Vz QGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mDQo8L2I+S29uZGEsIFRpcnVtYWxlc3dhciBS ZWRkeTxicj4NCjxiPlNlbnQ6PC9iPiAwNyBPY3RvYmVyIDIwMTcgMDQ6Mjg8YnI+DQo8Yj5Ubzo8 L2I+IEpvbiBTaGFsbG93OyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86 ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkluIGNhc2Ugb2YgY2xpZW50LXNpZGUgRE9UUyBnYXRl d2F5LCB3aHkgZG9lcyB0aGUgRE9UUyBzZXJ2ZXIgbmVlZCB0byBrbm93IHdoaWNoIOKAnERPVFMg Y2xpZW504oCdIGhhcyBjb252ZXllZCB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0ID88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZvciBl eGFtcGxlLCB0aGUgRE9UUyBjbGllbnQgY291bGQgYmUgYSBERG9TIGRldGVjdG9yIG9yIGFuIEFw cGxpY2F0aW9uIHNlcnZlciwgYW5kIHRoZSBjbGllbnQtc2lkZSBnYXRld2F5IHdpbGwgaGF2ZSB0 byByZXNvbHZlIHRoZSBjb25mbGljdGluZyBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlDQog RE9UUyBjbGllbnRzLCBhZ2dyZWdhdGUgdGhlIG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUg RE9UUyBjbGllbnQgYW5kIHNlbmQgdGhlIHVwZGF0ZWQgbWl0aWdhdGlvbiByZXF1ZXN0IHRvIHRo ZSBET1RTIHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSm9uIFNoYWxsb3cgWzxhIGhyZWY9Im1h aWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tIj5tYWlsdG86c3VwanBzLWlldGZAanBzaGFs bG93LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDYsIDIwMTcg Nzo0MiBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEg aHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9h PjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPg0KZG90c0BpZXRmLm9yZzwvYT47IFJv bGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9i Ymluc0BhcmJvci5uZXQ8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERP VFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SGkgVGlydSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VW5sZXNzIEkgYW0gbWlzc2luZyBzb21ldGhpbmcsIGhvdyBk b2VzIHRoZSBDbGllbnQgc2lkZSBvZiBET1RTIEdXIGNvbnZleSB0byB0aGUgdXBzdHJlYW0gc2Vy dmVyIGEgdW5pcXVlIOKAnGNsaWVudC1pZOKAnSB3aGljaCBpcyBkaWZmZXJlbnQgdG8gdGhlIGlt cGxpZWQNCiBjbGllbnQgaWQgYXMgZGVyaXZlZCBmcm9tIHRoZSBQS0kgY2VydGlmaWNhdGUgdGhh dCB0aGUgRE9UUyBHV+KAmUNsaWVudCB1c2VzL3ByZXNlbnRzIHdoZW4gY29tbXVuaWNhdGluZyB0 byB0aGUgc2VydmVyPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG8gbWUsIHRoZXJl IG5lZWRzIHRvIGJlIGFuIG9wdGlvbiBzdWNoIGFzIOKAnG9yaWdpbmFsLWNsaWVudC1pZOKAnSBv ciDigJxjbGllbnQtaWTigJ0gKHdoaWNoIGlzIGNvbmZ1c2luZyB3aGVuIGFsc28gcmVmZXJyaW5n IHRvIHRoZSBjbGllbnQgaWRlbnRpdHkgYXMNCiBkZXJpdmVkIGZyb20gdGhlIChET1RTIEdXKSBD bGllbnTigJlzIFBLSSBjZXJ0aWZpY2F0ZSkgYXMgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IHRoZSBET1RTIEdXIGNhbiBnZW5lcmF0ZSBpdHMgb3duIHVu aXF1ZSBjbGllbnQtaWQgdG8gc3RvcCBtdWx0aXBsZSBlbnRyaWVzIGJlaW5nIG5lZWRlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBv dXQgaW50ZXJuYWwgaW5mb3JtYXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLCBz byBteSBSRVFVSVJFRCBkb2VzIG5vdCBtYWtlIHNlbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UFMg4oCTIEkgYW0g aGF2aW5nIHRvIGRlYWwgd2l0aCBvdGhlciBzdHVmZiBhdCBwcmVzZW50IOKAkyBJIHdpbGwgZ2V0 IGJhY2sgbGF0ZXIgb24gdGhlIG90aGVyIGlzc3VlcyB1bmRlciBkaXNjdXNzaW9uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IEtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkgW21haWx0bzoNCjxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRk eV9Lb25kYUBtY2FmZWUuY29tIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwNiBPY3RvYmVyIDIwMTcgMTQ6NTg8YnI+DQo8Yj5Ubzo8 L2I+IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgSm9uIFNoYWxsb3c7ICdEb2JiaW5zLCBSb2xhbmQn Ow0KPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBzZWUgYSBuZWVkIGZvciBjbGll bnQtc2lkZSBET1RTIGdhdGV3YXkgdG8gY29udmV5IHRoZSDigJxET1RTIGNsaWVudCBpZGVudGl0 eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIGxvb2tz IHJlcXVpcmVkIG9ubHkgZm9yIHRoZSBzZXJ2ZXItc2lkZSBET1RTDQogZ2F0ZXdheXMuIEluIGNh c2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5IHRoZSBjbGllbnQt aWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBE T1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1bmlxdWUgY2xpZW50 LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4gYXJyYXkgb2YgY2xpZW50LWlkcyB0byB0 aGUgRE9UUyBzZXJ2ZXIgdG8NCiByZXNvbHZlIGNsYXNoZXMuIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tVGly dTxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB178894FA808E65A98444BCA4EA740DM5PR16MB1788namp_-- From nobody Mon Oct 9 08:42:31 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F6A13456F for ; Mon, 9 Oct 2017 08:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGdF3ssZgwyu for ; Mon, 9 Oct 2017 08:42:26 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C621345CE for ; Mon, 9 Oct 2017 08:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48785; q=dns/txt; s=iport; t=1507563745; x=1508773345; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=mZf9YK31S+coLqk4Pffjo9X9rcV8t46lTsFRAKNjxpA=; b=defdrYfhD6Pq1brshutJmPsNgFCL680yKW5hqUtxaURVirByfplhtXiU jq1IshR5zgJ8XD8ymao0cO7u7i6XquWzPkr2m5gdYuSaOViM7Qg7UuNiI dTV3EYfggm9pfDvT3iRCa1gjl3eIs0tcj+59SvvROSk+LFefFUcKDhjH3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AABwmNtZ/40NJK1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvQS1kbieOGY9ygUsJIpYvDoIBAwoYAQyFFgKENz8YAQIBAQE?= =?us-ascii?q?BAQEBayiFGAEBAQEBAQEBASUGOwYQCwsRAQMBAQEgAQYHJx8DBggGAQwGAgEBi?= =?us-ascii?q?h8FCBCpaDoninkBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgykEggKBUYFqKwuCc4R?= =?us-ascii?q?MIAI3FRGFLQWKCoEHiBiODIdejQmCb4huhy6VWoE5HzhPP1MlFUmFFwMcggMkN?= =?us-ascii?q?gEBiWgBAQE?= X-IronPort-AV: E=Sophos; i="5.42,500,1500940800"; d="scan'208,217"; a="14051963" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2017 15:42:07 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v99Fg6I5006239; Mon, 9 Oct 2017 15:42:07 GMT To: "Konda, Tirumaleswar Reddy" , Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> From: Flemming Andreasen Message-ID: Date: Mon, 9 Oct 2017 11:42:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------45533051AF35AD44289C230F" Content-Language: en-US Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 15:42:30 -0000 This is a multi-part message in MIME format. --------------45533051AF35AD44289C230F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: > > http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by > https://tools.ietf.org/html/rfc7925 has tested NAT behavior with > various routers and lists the timeout results. The majority of the > devices (62%) have a timeout between 2 and 2.5 minutes and the minimum > timeout value observed when packets are exchanged b/w peers in both > directions is 54 seconds. > I'm getting different data-points for at least the minimum value. There still seems to be a lot of NATs out there with a timeout value of ~30 seconds for UDP traffic (and in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what you would want. Google did a lot of testing around this and decided they were happy with the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds). Thanks -- Flemming > Responses to the questions below > > 1) The max-retransmit parameter is negotiable and configurable, DOTS > agents can pick suitable values for max-retransmit parameter based on > the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the > MAX_TRANSMIT_WAIT to 45 seconds). > > 2) No, if the DOTS agent wants to change the default heartbeat > interval then the other message transmission parameters will also have > to be modified. > > 3) The client will have to assume the session is disconnected (see the > discussion in > https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) > and initiate (D)TLS session resumption > > 4) If heartbeat expires then the DOTS server will close the (D)TLS > session, the client will have to initiate (D)TLS session resumption. > The heartbeat expires only after 273 seconds (3 CoAP ping > confirmable messages, each > CoAP ping re-transmitted 4 times). > > Med In the below text, recommended value should be 93 seconds > instead of 90 seconds (see > https://tools.ietf.org/html/rfc7252#section-4.8.2). > > -Tiru > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Jon Shallow > *Sent:* Wednesday, October 4, 2017 5:36 PM > *To:* mohamed.boucadair@orange.com; dots@ietf.org > *Subject:* Re: [Dots] Minimum heartbeat-interval > > Hi Mohamed, > > In principal I agree with your suggested updates the minimum of 10s > was an off the cuff response, to handle the broken NAT timing > implementations out there. > > The Heartbeat mechanism does raise a few questions in my mind which do > need to be thought through. On a DOTS server, using a heartbeat > interval of 15 secs, with the client going away circa 10:54:30, I get > > Oct 04 10:53:51 DEBG sending CoAP ping: > > Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29548 added to retransmit queue (2281ms) > > Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: received 41 bytes > > Oct 04 10:53:51 ALRT got RST for message 29548 > > Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29548: removed > > Oct 04 10:54:07 DEBG sending CoAP ping: > > Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29549 added to retransmit queue (2938ms) > > Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: received 41 bytes > > Oct 04 10:54:07 ALRT got RST for message 29549 > > Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29549: removed > > Oct 04 10:54:23 DEBG sending CoAP ping: > > Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29550 added to retransmit queue (2156ms) > > Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: received 41 bytes > > Oct 04 10:54:23 ALRT got RST for message 29550 > > Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29550: removed > > Oct 04 10:54:39 DEBG sending CoAP ping: > > Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551 added to retransmit queue (2813ms) > > Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551: retransmission #1 > > Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551: retransmission #2 > > Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551: retransmission #3 > > Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551: retransmission #4 > > Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551: give up after 4 attempts > > Here we see the 91 seconds (dependant on the max-retransmit value > being 4) 10:56:09 10:54:39. There is 46 seconds after transmission > #4 before the confirmable ping request times out (12 seconds for > transmission #3 before retry transmission #4). > > Question 1 > > ========== > > Should the max-retransmit actually be 3, not 4 for CON requests so > that we do not get this 46 second gap? > > - CON is only used for signal configuration (infrequent, likely only > to be in peace time) and heartbeats, not mitigation requests > > Question 2 > > ========= > > If the heartbeat interval is less than 91 seconds say 60 seconds and > the first heartbeat ping is still active, should a second heartbeat be > fired off? > > - I think not, but the text then needs to get updated to state the > interval is used whenever there is not a pending heartbeat response > outstanding. > > Question 3 > > ========= > > Heartbeat checks are being initiated by the client. The client gets a > heartbeat timeout on the session. The client subsequently needs to > send a PUT mitigate request. > > Does the client set up a new session? > > - Difficult as we are unlikely to be in peace time > > - PKI exchanges are likely to fail > > - the client just needs to send a non-confirmable PUT. > > Question 4 > > ========= > > Scenario as Q3 > > Does the client re-use the old session that the heartbeats are failing on? > > - The server may have sent a session close, but it never got through > > Question 4 > > ========== > > When the heartbeats are initiated by the server, and the heartbeat > times out, the session is bad, but the current mitigation request > continues until it expires. > > The client may have kicked off his heartbeats at a different time, and > there likely will be a sending frequency drift over time, so the > client may think the session is still active, the server not, and the > client decides it is time to send a non-confirmable PUT to refresh the > mitigation as it is about to expire or possibly another PUT for a > different IP that has just started to get hammered hence heartbeat > failures. > > Alternatively the client decides that the reason for bad session > (from the clients perspective) is an attack stopping traffic getting > through and needs to do a PUT on the existing session. > > So server receives a PUT (refresh or for a new IP) on a session that > has heartbeat expired. The session contained all the negotiated PKI > session keys etc. What should happen here? > > - as the heartbeats are failing, it is safe to assume we are not in > peace time. > > - I believe the session on the server needs to be kept hanging around > for some time post heartbeat time-out. For how long? > > - the server may be seeing the client heartbeat messages [this may > answer how to keep bad session hanging around] > > ========== > > Regards > > Jon > > *From:*Dots [mailto:ietf-supjps-dots-bounces@ietf.org] *On Behalf Of > *ietf-supjps-mohamed.boucadair@orange.com > > *Sent:* 04 October 2017 09:35 > *To:* dots@ietf.org ; Jon Shallow > (supjps-ietf@jpshallow.com ) > *Subject:* [Dots] Minimum heartbeat-interval > > Dear all, > > Jon made the following comment during the interim meeting: A: (Jon > Shallow): The minimum for the heartbeat should be 10s > > Actually, the use of 10s is not aligned with RFC8085 which says the > following: > > An application that needs to employ keep-alive messages to deliver > useful service over UDP in the presence of middleboxes SHOULD NOT > ^^^^^^^^^^^^^^^^^^^^^^ > transmit them more frequently than once every 15 seconds and SHOULD > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > use longer intervals when possible. > > I suggest to add this NEW text to the signal-channel draft to clarify > the rationale for the recommended values: > > NEW: > > Note: heartbeat-interval should be tweaked to also assist DOTS > > messages for NAT traversal (SIG-010 of > > [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive > > messages must not be sent more frequently than once every 15 > > seconds and should use longer intervals when possible. > > Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 > > minutes or longer. From that standpoint, this specification > > recommends a minimum heartbeat-interval of 15 seconds and a > > maximum heartbeat-interval of 240 seconds. The recommended value > > of 90 seconds is selected to anticipate the expiry of NAT states, > > while avoiding overloading the network with frequent keepalives > > for NAT state maintenance purposes. Note that this recommended > > value is close to the one recommended for MAX_TRANSMIT_WAIT, whose > > value is derived from transmission parameters (Section 4.8.2 of > > [RFC7252]). > > Thoughts? > > Cheers, > > Med > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------45533051AF35AD44289C230F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote:

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds.

I'm getting different data-points for at least the minimum value. There still seems to be a lot of NATs out there with a timeout value of ~30 seconds for UDP traffic (and in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what you would want. Google did a lot of testing around this and decided they were happy with the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds).

Thanks

-- Flemming


Responses to the questions below

1) The max-retransmit parameter is negotiable and configurable, DOTS agents can pick suitable values for max-retransmit parameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).

2) No, if the DOTS agent wants to change the default heartbeat interval then the other message transmission parameters will also have to be modified.

3) The client will have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS session, the client will have to initiate (D)TLS session resumption. The heartbeat expires only after 273 seconds (3 CoAP ping confirmable messages, each
CoAP ping re-transmitted 4 times).

Med In the below text, recommended value should be 93 seconds instead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2).

-Tiru

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

Hi Mohamed,

In principal I agree with your suggested updates the minimum of 10s was an off the cuff response, to handle the broken NAT timing implementations out there.

The Heartbeat mechanism does raise a few questions in my mind which do need to be thought through. On a DOTS server, using a heartbeat interval of 15 secs, with the client going away circa 10:54:30, I get

Oct 04 10:53:51 DEBG sending CoAP ping:

Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548 added to retransmit queue (2281ms)

Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message 29548

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548: removed

Oct 04 10:54:07 DEBG sending CoAP ping:

Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549 added to retransmit queue (2938ms)

Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message 29549

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549: removed

Oct 04 10:54:23 DEBG sending CoAP ping:

Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550 added to retransmit queue (2156ms)

Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message 29550

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550: removed

Oct 04 10:54:39 DEBG sending CoAP ping:

Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551 added to retransmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #1

Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #2

Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #3

Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #4

Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: give up after 4 attempts

Here we see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:09 10:54:39. There is 46 seconds after transmission #4 before the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

Question 1

==========

Should the max-retransmit actually be 3, not 4 for CON requests so that we do not get this 46 second gap?

- CON is only used for signal configuration (infrequent, likely only to be in peace time) and heartbeats, not mitigation requests

Question 2

=========

If the heartbeat interval is less than 91 seconds say 60 seconds and the first heartbeat ping is still active, should a second heartbeat be fired off?

- I think not, but the text then needs to get updated to state the interval is used whenever there is not a pending heartbeat response outstanding.

Question 3

=========

Heartbeat checks are being initiated by the client. The client gets a heartbeat timeout on the session. The client subsequently needs to send a PUT mitigate request.

Does the client set up a new session?

- Difficult as we are unlikely to be in peace time

- PKI exchanges are likely to fail

- the client just needs to send a non-confirmable PUT.

Question 4

=========

Scenario as Q3

Does the client re-use the old session that the heartbeats are failing on?

- The server may have sent a session close, but it never got through

Question 4

==========

When the heartbeats are initiated by the server, and the heartbeat times out, the session is bad, but the current mitigation request continues until it expires.

The client may have kicked off his heartbeats at a different time, and there likely will be a sending frequency drift over time, so the client may think the session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh the mitigation as it is about to expire or possibly another PUT for a different IP that has just started to get hammered hence heartbeat failures.

Alternatively the client decides that the reason for bad session (from the clients perspective) is an attack stopping traffic getting through and needs to do a PUT on the existing session.

So server receives a PUT (refresh or for a new IP) on a session that has heartbeat expired. The session contained all the negotiated PKI session keys etc. What should happen here?

- as the heartbeats are failing, it is safe to assume we are not in peace time.

- I believe the session on the server needs to be kept hanging around for some time post heartbeat time-out. For how long?

- the server may be seeing the client heartbeat messages [this may answer how to keep bad session hanging around]

==========

Regards

Jon

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com)
Subject: [Dots] Minimum heartbeat-interval

Dear all,

Jon made the following comment during the interim meeting: A: (Jon Shallow): The minimum for the heartbeat should be 10s

Actually, the use of 10s is not aligned with RFC8085 which says the following: 

 An application that needs to employ keep-alive messages to deliver
 useful service over UDP in the presence of middleboxes SHOULD NOT
 ^^^^^^^^^^^^^^^^^^^^^^
 transmit them more frequently than once every 15 seconds and SHOULD
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 use longer intervals when possible.

I suggest to add this NEW text to the signal-channel draft to clarify the rationale for the recommended values:

NEW:

Note: heartbeat-interval should be tweaked to also assist DOTS

messages for NAT traversal (SIG-010 of

[I-D.ietf-dots-requirements]). According to [RFC8085], keepalive

messages must not be sent more frequently than once every 15

seconds and should use longer intervals when possible.

Furthermore, [RFC4787] recommends NATs to use a state timeout of 2

minutes or longer. From that standpoint, this specification

recommends a minimum heartbeat-interval of 15 seconds and a

maximum heartbeat-interval of 240 seconds. The recommended value

of 90 seconds is selected to anticipate the expiry of NAT states,

while avoiding overloading the network with frequent keepalives

for NAT state maintenance purposes. Note that this recommended

value is close to the one recommended for MAX_TRANSMIT_WAIT, whose

value is derived from transmission parameters (Section 4.8.2 of

[RFC7252]).

Thoughts?

Cheers,

Med



_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--------------45533051AF35AD44289C230F-- From nobody Mon Oct 9 08:48:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736C2134E5E for ; Mon, 9 Oct 2017 08:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gufjLAtgcvAH for ; Mon, 9 Oct 2017 08:48:43 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E25134606 for ; Mon, 9 Oct 2017 08:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=101260; q=dns/txt; s=iport; t=1507564102; x=1508773702; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=kSZ0cktEUlJDMT1h6dmkPDbQ+u4FSq+QiQmgTvs9P9Y=; b=WaFB3pQdj4JR0bMwrAzncFbzzKp24zU+ToJFuLMjRb1QODdq9LZraOiY hKsPTkWcz+d0AFtwl6bgzL8+EsONS7HtrRbk5WBDoaZMQNu1p/OXFmW/b kNsh6gYMivDklt4KxAzF8yF9YiKIyLNI+9UA6Z/ZqRP1PdWQ/NYxrgP26 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAADzmNtZ/4MNJK1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvQS1kbieOGY9ygUsrli8OggEDChgBDIUWAoQ3PxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUYAQEBAQEBAQEBGAEMBjsGEAsLDgMBAwEBASABBgcnHwMGCAYBDAYCA?= =?us-ascii?q?QGKHwUIEKlrOieKegEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DKQSBJ1uBUYFqK4J?= =?us-ascii?q?+hEwHGQEBNxURhS0FigoBgQaIGIUviF2HXo0JghRbhRSDWoculVqBOR84gQ5TJ?= =?us-ascii?q?RVJhRcDHIIDJDYBAYcmgkIBAQE?= X-IronPort-AV: E=Sophos;i="5.42,500,1500940800"; d="scan'208,217";a="305522428" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2017 15:48:19 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v99FmI8W025714; Mon, 9 Oct 2017 15:48:18 GMT To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , dots@ietf.org, mohamed.boucadair@orange.com References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A050387@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0506A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <098901d33ee2$5c3478b0$149d6a10$@jpshallow.com> <0a0801d33f4f$8e9df840$abd9e8c0$@jpshallow.com> From: Flemming Andreasen Message-ID: <77ab7a0d-78fa-600a-4c06-8cb74171f719@cisco.com> Date: Mon, 9 Oct 2017 11:48:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0a0801d33f4f$8e9df840$abd9e8c0$@jpshallow.com> Content-Type: multipart/alternative; boundary="------------3646E25223217C794379EE3A" Content-Language: en-US Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 15:48:48 -0000 This is a multi-part message in MIME format. --------------3646E25223217C794379EE3A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 10/7/17 5:35 AM, Jon Shallow wrote: > > Hi Tiru, > > I confess to being troubled when considering tuning the various > max-retransmit, ack-timeout and ack-random-factor values to get > heartbeats behaving as required, as this will also affect anything > else using CON for the requests. > > With ack-timeout = 2, ack-random-factor = 1.5 and max-retransmit = 4 > (the defaults) and loss of response > > Heartbeat Ping > > 3 seconds > > Ping retry #1 > > 6 seconds > > Ping retry #2 > > 12 seconds > > Ping retry #3 > > 24 seconds > > Ping retry #4 > > 48 seconds > > Heartbeat Ping Timeout (after 93 seconds) reported to upper layers > > In terms of NAT (or even firewall session with no NAT) keep-alive, we > are doing this with a value of 3 seconds up to 48 seconds. > > I am making the assumption that the next Heartbeat Ping request (under > response loss conditions) almost immediately follows the Heartbeat > Ping Timeout, the cycles of which give up after missing-hb-allowed is > exceeded and the session is declared as dead. > > When there is no loss of response > > Heartbeat Ping > > Small number of milli seconds > > Ping Response (RST) > > MAX_TRANSMIT_WAIT (93 seconds) > > Heartbeat Ping > > Small number of milli seconds > > Ping Response (RST) > > > > I propose that instead of MAX_TRANSMIT_WAIT (93 seconds), we should > use the derived 48 second gap (between Ping Retry #4 and Heartbeat > Ping Timeout) when there is no loss of response for repeating Ping. > Thoughts? > > The reason for this is that you state below the minimum timeout value > observed when packets are exchanged b/w peers in both directions is 54 > seconds. > > A potential workaround to this discussion is that the spec states To > make sure that Heartbeats work correctly, any firewall rule (whether > NATd or not) on a firewall sitting between the DOTS client and DOTS > Server that enables the DOTS signal channel to traverse the device > MUST have an idle session timeout value greater than the derived > MAX_TRANSMIT_WAIT > The problem with this approach is that you typically do not control all the FWs and NATs en route to your destination, let alone even know about them, so imposing requirements on them is unlikely to be helpful. Instead, you need to find a way of actually working through them. Thanks -- Flemming > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org] *On Behalf Of *Konda, > Tirumaleswar Reddy > *Sent:* 07 October 2017 04:11 > *To:* Jon Shallow; dots@ietf.org; mohamed.boucadair@orange.com > *Subject:* Re: [Dots] Minimum heartbeat-interval > > Hi Jon, > > I meant heartbeat-interval will be defined as equivalent to > MAX_TRANSMIT_WAIT but not negotiated as heartbeat-interval is derived > from the message transmission parameters. > > -Tiru > > *From:*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Sent:* Saturday, October 7, 2017 2:03 AM > *To:* Konda, Tirumaleswar Reddy >; dots@ietf.org > ; mohamed.boucadair@orange.com > > *Subject:* RE: [Dots] Minimum heartbeat-interval > > Hi Guys, > > > Thanks Med, agreed on (2) (no need to negotiate and configure > heartbeat-interval). > > If heartbeat-interval is not defined / negotiated what happens in > peace time? What rate should the heartbeats be sent at? > > If COAP Pings are timing out yes, the length of time before the > timeout is reported to the upper layers is dependent on > max-retransmit, ack-timeout and ack-random-factor at which point a > COAP ping could get re-transmitted. But does the peace time COAP > Ping transmission rate have to be greater or equal to the COAP layer > reporting the Ping CON has failed? > > In war time, the next COAP Ping should be delayed until after the > current COAP Ping has expired. > > Regards > > Jon > > *From:*Dots [mailto:ietf-supjps-dots-bounces@ietf.org] *On Behalf Of > *Konda, Tirumaleswar Reddy > *Sent:* 06 October 2017 15:00 > *To:* mohamed.boucadair@orange.com > ; Jon Shallow; dots@ietf.org > > *Subject:* Re: [Dots] Minimum heartbeat-interval > > Thanks Med, agreed on (2) (no need to negotiate and configure > heartbeat-interval). > > -Tiru > > *From:*mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > *Sent:* Friday, October 6, 2017 7:12 PM > *To:* Konda, Tirumaleswar Reddy >; Jon Shallow > >; > dots@ietf.org > *Subject:* RE: [Dots] Minimum heartbeat-interval > > Tiru, > > We are on the same page for (1). I hope we will hear more voices on > this before we add some text to the draft to clarify missing points. > > Please see inline for (2). > > Cheers, > > Med > > *De:*Dots [mailto:dots-bounces@ietf.org] *De la part de* Konda, > Tirumaleswar Reddy > *Envoy:* vendredi 6 octobre 2017 15:08 > *:* BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org > > *Objet:* Re: [Dots] Minimum heartbeat-interval > > Hi Med, > > Please see inline [TR] > > *From:*mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > *Sent:* Friday, October 6, 2017 12:40 PM > *To:* Konda, Tirumaleswar Reddy >; Jon Shallow > >; > dots@ietf.org > *Subject:* RE: [Dots] Minimum heartbeat-interval > > Hi Tiru, all, > > Please see inline. > > Cheers, > > Med > > *De:*Konda, Tirumaleswar Reddy > [mailto:TirumaleswarReddy_Konda@McAfee.com] > *Envoy:* jeudi 5 octobre 2017 12:54 > *:* Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > > *Objet:* RE: [Dots] Minimum heartbeat-interval > > http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by > https://tools.ietf.org/html/rfc7925 has tested NAT behavior with > various routers and lists the timeout results. The majority of the > devices (62%) have a timeout between 2 and 2.5 minutes and the minimum > timeout value observed when packets are exchanged b/w peers in both > directions is 54 seconds. > > Responses to the questions below > > 1) The max-retransmit parameter is negotiable and configurable, DOTS > agents can pick suitable values for max-retransmit parameter based on > the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the > MAX_TRANSMIT_WAIT to 45 seconds). > > [Med] You are right about the configurable aspect, but the question > from Jon is a good one. I interpret it in another way: > > -Should we rely solely on the missing-hb-allowed to detect a session > problem? > > [TR] If the DOTS agent does not receive a response to CoAP ping but > receives other type of messages from the peer DOTS agent then a > counter incremented each time there is no response to a CoAP ping > till the counter value hits missing-hb-allowed to determine the > session is defunct can be reset to zero. > > -Should we get rid of missing-hb-allowed, but rely on the > retransmission to declare failure or not? > > [TR] If DOTS agents only rely on the retransmission mechanism then a > CoAP ping message will only be retransmitted 4 times before > concluding the session is disconnected in an interval of 93 seconds. > The network under DDoS attack is likely to be congested (high packet > loss and latency), hence missing-hb-allowed is used to send the CoAP > ping more number of times (3 (ping) + 3*4 (re-transmissions) = 15 > times) with sufficient time interval (93*3 = 279 seconds) to determine > the session is defunct. > > -What is the advantage of cumulating both missing-hb-allowed and the > retransmission procedure to declare a channel out? > > [TR] Please see above. > > 2) No, > > [Med] I agree that a heartbeat does not need to be fired when the > first ping is still alive. We can clarify this in the draft. > > [TR] Thanks. > > if the DOTS agent wants to change the default heartbeat interval then > the other message transmission parameters will also have to be modified. > > [Med] I disagree here that the other parameters need to be changed. I > dont see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even > if I agree that we need to tweak heartbeat-interval as a function of > MAX_TRANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from > other parameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * > ACK_RANDOM_FACTOR)). This is why it does not make sense to provide a > configuration for MAX_TRANSMIT_WAIT if the other parameters are provided. > > [TR] I did not get the above, the draft is not providing any new > configuration for MAX_TRANSMIT_WAIT > > [Med] I was talking about heartbeat-interval. > > . If lets say the DOTS agents decide to change the heartbeat interval > to 45 seconds then the max-retransmit has to be changed to 3 to arrive > at 45 second MAX_TRANSMIT_WAIT value (or other message transmission > parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be changed to > arrive at the new heartbeat interval). > > [Med] My comment is that if heartbeat-interval was dependent on > transmission parameters, then we do not need to configure it > explicitly IN ADDITION to the other transmission parameter. > > How can the heartbeat interval change without changing the message > transmission parameters ? > > [Med] I do see these two as separate parameters. The > heartbeat-interval determines the frequency of sending keeplaive > messages. This is an additional transmission parameter specific to > heartbeat if you will. > > -Tiru > > 3) The client will have to assume the session is disconnected (see the > discussion in > https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) > and initiate (D)TLS session resumption > > 4) If heartbeat expires then the DOTS server will close the (D)TLS > session, the client will have to initiate (D)TLS session resumption. > The heartbeat expires only after 273 seconds (3 CoAP ping > confirmable messages, each > CoAP ping re-transmitted 4 times). > > Med In the below text, recommended value should be 93 seconds > instead of 90 seconds (see > https://tools.ietf.org/html/rfc7252#section-4.8.2). > > -Tiru > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Jon Shallow > *Sent:* Wednesday, October 4, 2017 5:36 PM > *To:* mohamed.boucadair@orange.com > ; dots@ietf.org > > *Subject:* Re: [Dots] Minimum heartbeat-interval > > Hi Mohamed, > > In principal I agree with your suggested updates the minimum of 10s > was an off the cuff response, to handle the broken NAT timing > implementations out there. > > The Heartbeat mechanism does raise a few questions in my mind which do > need to be thought through. On a DOTS server, using a heartbeat > interval of 15 secs, with the client going away circa 10:54:30, I get > > Oct 04 10:53:51 DEBG sending CoAP ping: > > Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29548 added to retransmit queue (2281ms) > > Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: received 41 bytes > > Oct 04 10:53:51 ALRT got RST for message 29548 > > Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29548: removed > > Oct 04 10:54:07 DEBG sending CoAP ping: > > Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29549 added to retransmit queue (2938ms) > > Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: received 41 bytes > > Oct 04 10:54:07 ALRT got RST for message 29549 > > Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29549: removed > > Oct 04 10:54:23 DEBG sending CoAP ping: > > Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29550 added to retransmit queue (2156ms) > > Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: received 41 bytes > > Oct 04 10:54:23 ALRT got RST for message 29550 > > Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29550: removed > > Oct 04 10:54:39 DEBG sending CoAP ping: > > Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551 added to retransmit queue (2813ms) > > Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551: retransmission #1 > > Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551: retransmission #2 > > Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551: retransmission #3 > > Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551: retransmission #4 > > Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS: sent 41 bytes > > Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) > DTLS tid=29551: give up after 4 attempts > > Here we see the 91 seconds (dependant on the max-retransmit value > being 4) 10:56:09 10:54:39. There is 46 seconds after transmission > #4 before the confirmable ping request times out (12 seconds for > transmission #3 before retry transmission #4). > > Question 1 > > ========== > > Should the max-retransmit actually be 3, not 4 for CON requests so > that we do not get this 46 second gap? > > - CON is only used for signal configuration (infrequent, likely only > to be in peace time) and heartbeats, not mitigation requests > > Question 2 > > ========= > > If the heartbeat interval is less than 91 seconds say 60 seconds and > the first heartbeat ping is still active, should a second heartbeat be > fired off? > > - I think not, but the text then needs to get updated to state the > interval is used whenever there is not a pending heartbeat response > outstanding. > > Question 3 > > ========= > > Heartbeat checks are being initiated by the client. The client gets a > heartbeat timeout on the session. The client subsequently needs to > send a PUT mitigate request. > > Does the client set up a new session? > > - Difficult as we are unlikely to be in peace time > > - PKI exchanges are likely to fail > > - the client just needs to send a non-confirmable PUT. > > Question 4 > > ========= > > Scenario as Q3 > > Does the client re-use the old session that the heartbeats are failing on? > > - The server may have sent a session close, but it never got through > > Question 4 > > ========== > > When the heartbeats are initiated by the server, and the heartbeat > times out, the session is bad, but the current mitigation request > continues until it expires. > > The client may have kicked off his heartbeats at a different time, and > there likely will be a sending frequency drift over time, so the > client may think the session is still active, the server not, and the > client decides it is time to send a non-confirmable PUT to refresh the > mitigation as it is about to expire or possibly another PUT for a > different IP that has just started to get hammered hence heartbeat > failures. > > Alternatively the client decides that the reason for bad session > (from the clients perspective) is an attack stopping traffic getting > through and needs to do a PUT on the existing session. > > So server receives a PUT (refresh or for a new IP) on a session that > has heartbeat expired. The session contained all the negotiated PKI > session keys etc. What should happen here? > > - as the heartbeats are failing, it is safe to assume we are not in > peace time. > > - I believe the session on the server needs to be kept hanging around > for some time post heartbeat time-out. For how long? > > - the server may be seeing the client heartbeat messages [this may > answer how to keep bad session hanging around] > > ========== > > Regards > > Jon > > *From:*Dots [mailto:ietf-supjps-dots-bounces@ietf.org] *On Behalf Of > *ietf-supjps-mohamed.boucadair@orange.com > > *Sent:* 04 October 2017 09:35 > *To:* dots@ietf.org ; Jon Shallow > (supjps-ietf@jpshallow.com ) > *Subject:* [Dots] Minimum heartbeat-interval > > Dear all, > > Jon made the following comment during the interim meeting: A: (Jon > Shallow): The minimum for the heartbeat should be 10s > > Actually, the use of 10s is not aligned with RFC8085 which says the > following: > > An application that needs to employ keep-alive messages to deliver > useful service over UDP in the presence of middleboxes SHOULD NOT > ^^^^^^^^^^^^^^^^^^^^^^ > transmit them more frequently than once every 15 seconds and SHOULD > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > use longer intervals when possible. > > I suggest to add this NEW text to the signal-channel draft to clarify > the rationale for the recommended values: > > NEW: > > Note: heartbeat-interval should be tweaked to also assist DOTS > > messages for NAT traversal (SIG-010 of > > [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive > > messages must not be sent more frequently than once every 15 > > seconds and should use longer intervals when possible. > > Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 > > minutes or longer. From that standpoint, this specification > > recommends a minimum heartbeat-interval of 15 seconds and a > > maximum heartbeat-interval of 240 seconds. The recommended value > > of 90 seconds is selected to anticipate the expiry of NAT states, > > while avoiding overloading the network with frequent keepalives > > for NAT state maintenance purposes. Note that this recommended > > value is close to the one recommended for MAX_TRANSMIT_WAIT, whose > > value is derived from transmission parameters (Section 4.8.2 of > > [RFC7252]). > > Thoughts? > > Cheers, > > Med > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------3646E25223217C794379EE3A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 10/7/17 5:35 AM, Jon Shallow wrote:

Hi Tiru,

I confess to being troubled when considering tuning the various max-retransmit, ack-timeout and ack-random-factor values to get heartbeats behaving as required, as this will also affect anything else using CON for the requests.

With ack-timeout = 2, ack-random-factor = 1.5 and max-retransmit = 4 (the defaults) and loss of response

Heartbeat Ping

3 seconds

Ping retry #1

6 seconds

Ping retry #2

12 seconds

Ping retry #3

24 seconds

Ping retry #4

48 seconds

Heartbeat Ping Timeout (after 93 seconds) reported to upper layers

In terms of NAT (or even firewall session with no NAT) keep-alive, we are doing this with a value of 3 seconds up to 48 seconds.

I am making the assumption that the next Heartbeat Ping request (under response loss conditions) almost immediately follows the Heartbeat Ping Timeout, the cycles of which give up after missing-hb-allowed is exceeded and the session is declared as dead.

When there is no loss of response

Heartbeat Ping

Small number of milli seconds

Ping Response (RST)

MAX_TRANSMIT_WAIT (93 seconds)

Heartbeat Ping

Small number of milli seconds

Ping Response (RST)

I propose that instead of MAX_TRANSMIT_WAIT (93 seconds), we should use the derived 48 second gap (between Ping Retry #4 and Heartbeat Ping Timeout) when there is no loss of response for repeating Ping. Thoughts?

The reason for this is that you state below the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds.

A potential workaround to this discussion is that the spec states To make sure that Heartbeats work correctly, any firewall rule (whether NATd or not) on a firewall sitting between the DOTS client and DOTS Server that enables the DOTS signal channel to traverse the device MUST have an idle session timeout value greater than the derived MAX_TRANSMIT_WAIT


The problem with this approach is that you typically do not control all the FWs and NATs en route to your destination, let alone even know about them, so imposing requirements on them is unlikely to be helpful. Instead, you need to find a way of actually working through them.

Thanks

-- Flemming



Regards

Jon

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 04:11
To: Jon Shallow; dots@ietf.org; mohamed.boucadair@orange.com
Subject: Re: [Dots] Minimum heartbeat-interval

Hi Jon,

I meant heartbeat-interval will be defined as equivalent to MAX_TRANSMIT_WAIT but not negotiated as heartbeat-interval is derived from the message transmission parameters.

-Tiru

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Saturday, October 7, 2017 2:03 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org; mohamed.boucadair@orange.com
Subject: RE: [Dots] Minimum heartbeat-interval

Hi Guys,

> Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-interval).

If heartbeat-interval is not defined / negotiated what happens in peace time? What rate should the heartbeats be sent at?

If COAP Pings are timing out yes, the length of time before the timeout is reported to the upper layers is dependent on max-retransmit, ack-timeout and ack-random-factor at which point a COAP ping could get re-transmitted. But does the peace time COAP Ping transmission rate have to be greater or equal to the COAP layer reporting the Ping CON has failed?

In war time, the next COAP Ping should be delayed until after the current COAP Ping has expired.

Regards

Jon

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 October 2017 15:00
To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

Thanks Med, agreed on (2) (no need to negotiate and configure heartbeat-interval).

-Tiru

From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, October 6, 2017 7:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] Minimum heartbeat-interval

Tiru,

We are on the same page for (1). I hope we will hear more voices on this before we add some text to the draft to clarify missing points.

Please see inline for (2).

Cheers,

Med

De: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy: vendredi 6 octobre 2017 15:08
: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet: Re: [Dots] Minimum heartbeat-interval

Hi Med,

Please see inline [TR]

From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, October 6, 2017 12:40 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] Minimum heartbeat-interval

Hi Tiru, all,

Please see inline.

Cheers,

Med

De: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoy: jeudi 5 octobre 2017 12:54
: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet: RE: [Dots] Minimum heartbeat-interval

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds.

Responses to the questions below

1) The max-retransmit parameter is negotiable and configurable, DOTS agents can pick suitable values for max-retransmit parameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).

[Med] You are right about the configurable aspect, but the question from Jon is a good one. I interpret it in another way:

- Should we rely solely on the missing-hb-allowed to detect a session problem?

[TR] If the DOTS agent does not receive a response to CoAP ping but receives other type of messages from the peer DOTS agent then a counter incremented each time there is no response to a CoAP ping till the counter value hits missing-hb-allowed to determine the session is defunct can be reset to zero.

- Should we get rid of missing-hb-allowed, but rely on the retransmission to declare failure or not?

[TR] If DOTS agents only rely on the retransmission mechanism then a CoAP ping message will only be retransmitted 4 times before concluding the session is disconnected in an interval of 93 seconds. The network under DDoS attack is likely to be congested (high packet loss and latency), hence missing-hb-allowed is used to send the CoAP ping more number of times (3 (ping) + 3*4 (re-transmissions) = 15 times) with sufficient time interval (93*3 = 279 seconds) to determine the session is defunct.

- What is the advantage of cumulating both missing-hb-allowed and the retransmission procedure to declare a channel out?

[TR] Please see above.

2) No,

[Med] I agree that a heartbeat does not need to be fired when the first ping is still alive. We can clarify this in the draft.

[TR] Thanks.

if the DOTS agent wants to change the default heartbeat interval then the other message transmission parameters will also have to be modified.

[Med] I disagree here that the other parameters need to be changed. I dont see heartbeat-interval as equivalent to MAX_TRANSMIT_WAIT (even if I agree that we need to tweak heartbeat-interval as a function of MAX_TRANSMIT_WAIT). As you know, MAX_TRANSMIT_WAIT can be derived from other parameters (ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR)). This is why it does not make sense to provide a configuration for MAX_TRANSMIT_WAIT if the other parameters are provided.

[TR] I did not get the above, the draft is not providing any new configuration for MAX_TRANSMIT_WAIT

[Med] I was talking about heartbeat-interval.

. If lets say the DOTS agents decide to change the heartbeat interval to 45 seconds then the max-retransmit has to be changed to 3 to arrive at 45 second MAX_TRANSMIT_WAIT value (or other message transmission parameters ACK_TIMEOUT or ACK_RANDOM_FACTOR have to be changed to arrive at the new heartbeat interval).

[Med] My comment is that if heartbeat-interval was dependent on transmission parameters, then we do not need to configure it explicitly IN ADDITION to the other transmission parameter.

How can the heartbeat interval change without changing the message transmission parameters ?

[Med] I do see these two as separate parameters. The heartbeat-interval determines the frequency of sending keeplaive messages. This is an additional transmission parameter specific to heartbeat if you will.

-Tiru

3) The client will have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS session, the client will have to initiate (D)TLS session resumption. The heartbeat expires only after 273 seconds (3 CoAP ping confirmable messages, each
CoAP ping re-transmitted 4 times).

Med In the below text, recommended value should be 93 seconds instead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2).

-Tiru

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

Hi Mohamed,

In principal I agree with your suggested updates the minimum of 10s was an off the cuff response, to handle the broken NAT timing implementations out there.

The Heartbeat mechanism does raise a few questions in my mind which do need to be thought through. On a DOTS server, using a heartbeat interval of 15 secs, with the client going away circa 10:54:30, I get

Oct 04 10:53:51 DEBG sending CoAP ping:

Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548 added to retransmit queue (2281ms)

Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message 29548

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548: removed

Oct 04 10:54:07 DEBG sending CoAP ping:

Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549 added to retransmit queue (2938ms)

Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message 29549

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549: removed

Oct 04 10:54:23 DEBG sending CoAP ping:

Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550 added to retransmit queue (2156ms)

Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message 29550

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550: removed

Oct 04 10:54:39 DEBG sending CoAP ping:

Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551 added to retransmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #1

Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #2

Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #3

Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #4

Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: give up after 4 attempts

Here we see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:09 10:54:39. There is 46 seconds after transmission #4 before the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

Question 1

==========

Should the max-retransmit actually be 3, not 4 for CON requests so that we do not get this 46 second gap?

- CON is only used for signal configuration (infrequent, likely only to be in peace time) and heartbeats, not mitigation requests

Question 2

=========

If the heartbeat interval is less than 91 seconds say 60 seconds and the first heartbeat ping is still active, should a second heartbeat be fired off?

- I think not, but the text then needs to get updated to state the interval is used whenever there is not a pending heartbeat response outstanding.

Question 3

=========

Heartbeat checks are being initiated by the client. The client gets a heartbeat timeout on the session. The client subsequently needs to send a PUT mitigate request.

Does the client set up a new session?

- Difficult as we are unlikely to be in peace time

- PKI exchanges are likely to fail

- the client just needs to send a non-confirmable PUT.

Question 4

=========

Scenario as Q3

Does the client re-use the old session that the heartbeats are failing on?

- The server may have sent a session close, but it never got through

Question 4

==========

When the heartbeats are initiated by the server, and the heartbeat times out, the session is bad, but the current mitigation request continues until it expires.

The client may have kicked off his heartbeats at a different time, and there likely will be a sending frequency drift over time, so the client may think the session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh the mitigation as it is about to expire or possibly another PUT for a different IP that has just started to get hammered hence heartbeat failures.

Alternatively the client decides that the reason for bad session (from the clients perspective) is an attack stopping traffic getting through and needs to do a PUT on the existing session.

So server receives a PUT (refresh or for a new IP) on a session that has heartbeat expired. The session contained all the negotiated PKI session keys etc. What should happen here?

- as the heartbeats are failing, it is safe to assume we are not in peace time.

- I believe the session on the server needs to be kept hanging around for some time post heartbeat time-out. For how long?

- the server may be seeing the client heartbeat messages [this may answer how to keep bad session hanging around]

==========

Regards

Jon

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com)
Subject: [Dots] Minimum heartbeat-interval

Dear all,

Jon made the following comment during the interim meeting: A: (Jon Shallow): The minimum for the heartbeat should be 10s

Actually, the use of 10s is not aligned with RFC8085 which says the following: 

 An application that needs to employ keep-alive messages to deliver
 useful service over UDP in the presence of middleboxes SHOULD NOT
 ^^^^^^^^^^^^^^^^^^^^^^
 transmit them more frequently than once every 15 seconds and SHOULD
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 use longer intervals when possible.

I suggest to add this NEW text to the signal-channel draft to clarify the rationale for the recommended values:

NEW:

Note: heartbeat-interval should be tweaked to also assist DOTS

messages for NAT traversal (SIG-010 of

[I-D.ietf-dots-requirements]). According to [RFC8085], keepalive

messages must not be sent more frequently than once every 15

seconds and should use longer intervals when possible.

Furthermore, [RFC4787] recommends NATs to use a state timeout of 2

minutes or longer. From that standpoint, this specification

recommends a minimum heartbeat-interval of 15 seconds and a

maximum heartbeat-interval of 240 seconds. The recommended value

of 90 seconds is selected to anticipate the expiry of NAT states,

while avoiding overloading the network with frequent keepalives

for NAT state maintenance purposes. Note that this recommended

value is close to the one recommended for MAX_TRANSMIT_WAIT, whose

value is derived from transmission parameters (Section 4.8.2 of

[RFC7252]).

Thoughts?

Cheers,

Med



_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--------------3646E25223217C794379EE3A-- From nobody Mon Oct 9 08:57:57 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10440134F82 for ; Mon, 9 Oct 2017 08:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 ttC-ZOd71JpZ for ; Mon, 9 Oct 2017 08:57:35 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 90B7F1348F3 for ; Mon, 9 Oct 2017 08:55:52 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507564531; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=4 KbX8RHldSuCHAUi7RTIk0qQ42Z+1/oB6gIjtIbU11 M=; b=LY5Jt0YwgwdhLUYVKhEXbOjjoEM4yWtDwv9mnfTQHtTK nyr/I49K+93vLyvq+c7Vc/QDjsINVqIwh63fh4V1xuS2ZCmM2x sB84ma+GZu1VeIDRwwJcUIBcO3ctj8gWI1JKt7n772aoylmWLo nQKD1kH/KgqGDMoTjTuhb5Tk8wY= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 6a11_0e41_03986f20_d795_4ce3_a1e2_40d4de65abf6; Mon, 09 Oct 2017 10:55:30 -0500 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 09:55:05 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Oct 2017 09:55:05 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 09:55:04 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 9 Oct 2017 15:55:03 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.019; Mon, 9 Oct 2017 15:55:03 +0000 From: "Konda, Tirumaleswar Reddy" To: Flemming Andreasen , Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AdM866F1exiXOD0RS+2TvvngfvHPNAAHYE+AAC3w14AA1RHAgAAAO8mw Date: Mon, 9 Oct 2017 15:55:03 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.171.90.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:0g1mEtpSen0MnnsStBvbe1Npa/OcdpkqBm2xm64AL/8xkJlgiuxTkjPBEO3XwetSnrhMPpowMfzuA0eMf7Dndri2j/QsFvvIsTgnboWMzkjQ23J1uq44N/lgdn7cAQtUdQjVszVeh+Gpx+0qjOxbr+t/XB3fWHtI1MyUJEksuEetKq9U5IQALsPXi9mw/tXiOLBntuaKgqinm8YpLA5vHdhIKdpqlPHT0HzgagtEq8WZ0yBvhXREeX98QgYglsHTH75YiQY6AJMM6Uak4tqk6mERuUoiVcokep6PTE803Tp/waEmvd14FEWhJlZz3SC3uDeLVRUOELiN+1i+0P7fVQ==; 5:FfAc9rdn1+YT6Rf7AW8JJGwwosyuN/TDBPEi3kORtD8s+3GR7n7Qk15toOpTl2qJj9NB5CJK4p/41LcwHekwYgRcN0o3wPjZmvZs5cig950wJNyujv2o3zhpgsbxAMm+IEIEg+/WJ4rlY8qKVB0Jrg==; 24:0Lww79OOqcRkngBjN7LjNVFDxpbV0/dLnk4HL5BnbbNedPitOE4YCnHf419WCNZl6GMR80zwtQRrFgi9nicBY8AwPm2j3XtncM7BRA9URgE=; 7:XwbLtmGThmKf6Lqn6ZP12KgC5N1EysFYBIdXokmzlw9rwdQr9/i42IOqGcBeDWjJouU9oWqMxvZHRGqKed8YDZi5z+flFuph86asglFGcdlSBofqU/OdZCup25Mood1l7njDdFNYdle2I/iQywBog/Xcn+RTiog4tHaI8B9PTJqjRrYEEl40G30EM3p12Eqc9bvNUGi8nzaAJZUDKZhqNOH1Pz/xkocEAmHxVkOx0VY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 54766346-3e5e-49b7-dd0a-08d50f2e1abf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(377454003)(199003)(32952001)(24454002)(189002)(9686003)(229853002)(6246003)(77096006)(106356001)(76176999)(606006)(54356999)(93886005)(33656002)(110136005)(25786009)(14454004)(53546010)(7696004)(2950100002)(6436002)(6506006)(105586002)(66066001)(101416001)(3280700002)(3660700001)(50986999)(53936002)(2906002)(966005)(189998001)(86362001)(68736007)(5660300001)(2900100001)(2501003)(53946003)(99286003)(6116002)(72206003)(74316002)(8676002)(80792005)(102836003)(790700001)(2201001)(236005)(97736004)(478600001)(81156014)(55016002)(7736002)(54896002)(81166006)(8936002)(3846002)(6306002)(316002)(85282002)(562404015); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178860AAE05A18999C277484EA740DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2017 15:55:03.3393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6132> : inlines <6115> : streams <1766522> : uri <2513803> Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 15:57:55 -0000 --_000_DM5PR16MB178860AAE05A18999C277484EA740DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen Sent: Monday, October 9, 2017 9:12 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; mohamed.boucadair@orange.com; dots@ietf.o= rg Subject: Re: [Dots] Minimum heartbeat-interval On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. I'm getting different data-points for at least the minimum value. There sti= ll seems to be a lot of NATs out there with a timeout value of ~30 seconds = for UDP traffic (and in rare cases even lower), which suggests that a timeo= ut value slightly lower than 30 seconds is what you would want. Google did = a lot of testing around this and decided they were happy with the values in= https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds). Consent freshness has nothing to do with NAT/FW timeouts. -Tiru Thanks -- Flemming Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). 2) No, if the DOTS agent wants to change the default heartbeat interval the= n the other message transmission parameters will also have to be modified. 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_DM5PR16MB178860AAE05A18999C277484EA740DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@oran= ge.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

 

On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote:=

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html= /rfc7925 has tested NAT behavior with various routers and lists the tim= eout results. The majority of the devices (62%) have a timeout between 2 an= d 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is = 54 seconds.

 

I'm getting different= data-points for at least the minimum value. There still seems to be a lot = of NATs out there with a timeout value of ~30 seconds for UDP traffic (and in rare cases even lower), which suggests tha= t a timeout value slightly lower than 30 seconds is what you would want. Go= ogle did a lot of testing around this and decided they were happy with the = values in https://tools.ietf.org/html= /rfc7675 (i.e. 30 seconds).

 

Consent freshness has nothing to do with NAT/FW timeouts.

 

-Tiru



Thanks

-- Flemming



Responses to the questions below

 

1) The max-retransmit parameter is negotiable and configurable,&nbs= p; DOTS agents can pick suitable values for max-retransmit parameter based = on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds). <= /o:p>

2) No, if the DOTS agent wants to change the default heartbeat inte= rval then the other message transmission parameters will also have to be mo= dified.

3) The client will have to assume the session is disconnected (see = the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The he= artbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 

Med – In the below text, recommended value should be 93 secon= ds instead of 90 seconds (see https://tools= .ietf.org/html/rfc7252#section-4.8.2).

 

-Tiru

 

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

 <= /span>

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

 <= /span>

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

 <= /span>

Oct 04 10:53:51 DEBG se= nding CoAP ping:

Oct 04 10:53:51 DEBG *&= nbsp; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 by= tes

Oct 04 10:53:51 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 adde= d to retransmit queue (2281ms)

Oct 04 10:53:51 DEBG *&= nbsp; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 4= 1 bytes

Oct 04 10:53:51 ALRT go= t RST for message 29548

Oct 04 10:53:51 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: rem= oved

Oct 04 10:54:07 DEBG se= nding CoAP ping:

Oct 04 10:54:07 DEBG *&= nbsp; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 by= tes

Oct 04 10:54:07 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 adde= d to retransmit queue (2938ms)

Oct 04 10:54:07 DEBG *&= nbsp; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 4= 1 bytes

Oct 04 10:54:07 ALRT go= t RST for message 29549

Oct 04 10:54:07 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: rem= oved

Oct 04 10:54:23 DEBG se= nding CoAP ping:

Oct 04 10:54:23 DEBG *&= nbsp; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 by= tes

Oct 04 10:54:23 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 adde= d to retransmit queue (2156ms)

Oct 04 10:54:23 DEBG *&= nbsp; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 4= 1 bytes

Oct 04 10:54:23 ALRT go= t RST for message 29550

Oct 04 10:54:23 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: rem= oved

Oct 04 10:54:39 DEBG se= nding CoAP ping:

Oct 04 10:54:39 DEBG *&= nbsp; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 by= tes

Oct 04 10:54:39 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 adde= d to retransmit queue (2813ms)

Oct 04 10:54:42 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: ret= ransmission #1

Oct 04 10:54:42 DEBG *&= nbsp; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 by= tes

Oct 04 10:54:48 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: ret= ransmission #2

Oct 04 10:54:48 DEBG *&= nbsp; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 by= tes

Oct 04 10:55:00 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: ret= ransmission #3

Oct 04 10:55:00 DEBG *&= nbsp; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 by= tes

Oct 04 10:55:23 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: ret= ransmission #4

Oct 04 10:55:23 DEBG *&= nbsp; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 by= tes

Oct 04 10:56:09 DEBG **= 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: giv= e up after 4 attempts

 <= /span>

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

 <= /span>

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

 <= /span>

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

 <= /span>

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

 <= /span>

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Scenari= o as Q3

 <= /span>

Does th= e client re-use the old session that the heartbeats are failing on?<= o:p>

- The s= erver may have sent a session close, but it never got through

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

 <= /span>

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

 <= /span>

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

Regards=

 <= /span>

Jon

 <= /span>

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow = (supjps-ietf@jpshallow.com= )
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during the interim me= eting: “A: (Jon Shallow): The= minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with RFC8085= which says the following:

 

   An application that needs to employ keep-alive messages t=
o deliver
   useful service over UDP in the presence of middleboxes SH=
OULD NOT
           &nbs=
p;            &=
nbsp;           &nbs=
p;         ^^^^^^^^^^^^^^^^^^^^^^
   transmit them more frequently than once every 15 seconds =
and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^
   use longer intervals when possible.  

 


I suggest to add this NEW text to the signal-channel=
 draft to clarify the rationale for the recommended values:



 


NEW:


   &=
nbsp;  Note: heartbeat-interval should be tweaked to also assist DOTS<=
/span>


   &=
nbsp;  messages for NAT traversal (SIG-010 of


   &=
nbsp;  [I-D.ietf-dots-requirements]).  According to [RFC8085], ke=
epalive


   &=
nbsp;  messages must not be sent more frequently than once every 15


   &=
nbsp;  seconds and should use longer intervals when possible.


   &=
nbsp;  Furthermore, [RFC4787] recommends NATs to use a state timeout o=
f 2


   &=
nbsp;  minutes or longer.  From that standpoint, this specificati=
on


   &=
nbsp;  recommends a minimum heartbeat-interval of 15 seconds and a


   &=
nbsp;  maximum heartbeat-interval of 240 seconds.  The recommende=
d value


   &=
nbsp;  of 90 seconds is selected to anticipate the expiry of NAT state=
s,


   &=
nbsp;  while avoiding overloading the network with frequent keepalives=



   &=
nbsp;  for NAT state maintenance purposes.  Note that this recomm=
ended


   &=
nbsp;  value is close to the one recommended for MAX_TRANSMIT_WAIT, wh=
ose


   &=
nbsp;  value is derived from transmission parameters (Section 4.8.2 of=



     
[RFC7252]).


 


Thoughts?



 


Cheers,


Med






_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.iet=
f.org/mailman/listinfo/dots

 

--_000_DM5PR16MB178860AAE05A18999C277484EA740DM5PR16MB1788namp_-- From nobody Mon Oct 9 09:35:49 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EDD133321 for ; Mon, 9 Oct 2017 09:35:47 -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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 pOxvgC7rCYWg for ; Mon, 9 Oct 2017 09:35:44 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3128134552 for ; Mon, 9 Oct 2017 09:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56065; q=dns/txt; s=iport; t=1507566943; x=1508776543; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=F9Y9LFcjYGQavp6ZyNoK31aNPjtGEiFGjSSMnzV0+/U=; b=lYbohE1Y37Ui1UkDBPmR532oroi+vwaS1BykR/wsjjrIbxcMvVBtHYMf wfd7Azr6+n6JRpi3cf04lHwlEsbd8Y1sPX8c1OS+rQ+4+wP4M5zeUz5uG vCbQlRtKfux6NfQDGzvFSSyYCt4tDFd3n9YyvkF8PVFA0Vu5jOebkkHbZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAADxpNtZ/4oNJK1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvQS1kbieOGY9ygXaWLw6CAQMKGAEMhRYChDk/GAECAQEBAQE?= =?us-ascii?q?BAWsohRgBAQEBAQIBARgNBjsGGwsRAQMBAQEgAQYHJx8DBggGAQwGAgEBih8NE?= =?us-ascii?q?KllOieKewEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DKQSCAoFRgWorgn6ETCACNxU?= =?us-ascii?q?RhS0FigqJH44Mh16NCYJviG6HLpVagTkfOE8/UyUVSYUXAxyCAyQ2AQGJaAEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos; i="5.42,500,1500940800"; d="scan'208,217"; a="14075100" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2017 16:35:42 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v99GZfMT020754; Mon, 9 Oct 2017 16:35:41 GMT To: "Konda, Tirumaleswar Reddy" , Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> From: Flemming Andreasen Message-ID: <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com> Date: Mon, 9 Oct 2017 12:35:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0FDF4960E2205F278CA19F2B" Content-Language: en-US Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 16:35:48 -0000 This is a multi-part message in MIME format. --------------0FDF4960E2205F278CA19F2B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote: > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Flemming > Andreasen > *Sent:* Monday, October 9, 2017 9:12 PM > *To:* Konda, Tirumaleswar Reddy ; > Jon Shallow ; mohamed.boucadair@orange.com; > dots@ietf.org > *Subject:* Re: [Dots] Minimum heartbeat-interval > > On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: > > http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced > by https://tools.ietf.org/html/rfc7925 has tested NAT behavior > with various routers and lists the timeout results. The majority > of the devices (62%) have a timeout between 2 and 2.5 minutes and > the minimum timeout value observed when packets are exchanged b/w > peers in both directions is 54 seconds. > > I'm getting different data-points for at least the minimum value. > There still seems to be a lot of NATs out there with a timeout value > of ~30 seconds for UDP traffic (and in rare cases even lower), which > suggests that a timeout value slightly lower than 30 seconds is what > you would want. Google did a lot of testing around this and decided > they were happy with the values in https://tools.ietf.org/html/rfc7675 > (i.e. 30 seconds). > > Consent freshness has nothing to do with NAT/FW timeouts. > You are missing the point Tiru - testing has been done (in the past and more recently) and a value of ~30 seconds seems to be what works for the majority of devices. I'll trust Google on this one. -- Flemming > -Tiru > > > > Thanks > > -- Flemming > > > > Responses to the questions below > > 1) The max-retransmit parameter is negotiable and configurable, > DOTS agents can pick suitable values for max-retransmit parameter > based on the heartbeat-interval (e.g. use 3 instead of default 4 > to reduce the MAX_TRANSMIT_WAIT to 45 seconds). > > 2) No, if the DOTS agent wants to change the default heartbeat > interval then the other message transmission parameters will also > have to be modified. > > 3) The client will have to assume the session is disconnected (see > the discussion in > https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) > and initiate (D)TLS session resumption > > 4) If heartbeat expires then the DOTS server will close the (D)TLS > session, the client will have to initiate (D)TLS session > resumption. The heartbeat expires only after 273 seconds (3 CoAP > ping confirmable messages, each > CoAP ping re-transmitted 4 times). > > Med In the below text, recommended value should be 93 seconds > instead of 90 seconds (see > https://tools.ietf.org/html/rfc7252#section-4.8.2). > > -Tiru > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Jon Shallow > *Sent:* Wednesday, October 4, 2017 5:36 PM > *To:* mohamed.boucadair@orange.com > ; dots@ietf.org > > *Subject:* Re: [Dots] Minimum heartbeat-interval > > Hi Mohamed, > > In principal I agree with your suggested updates the minimum of > 10s was an off the cuff response, to handle the broken NAT > timing implementations out there. > > The Heartbeat mechanism does raise a few questions in my mind > which do need to be thought through. On a DOTS server, using a > heartbeat interval of 15 secs, with the client going away circa > 10:54:30, I get > > Oct 04 10:53:51 DEBG sending CoAP ping: > > Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS: sent 41 bytes > > Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29548 added to retransmit queue (2281ms) > > Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS: received 41 bytes > > Oct 04 10:53:51 ALRT got RST for message 29548 > > Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29548: removed > > Oct 04 10:54:07 DEBG sending CoAP ping: > > Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS: sent 41 bytes > > Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29549 added to retransmit queue (2938ms) > > Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS: received 41 bytes > > Oct 04 10:54:07 ALRT got RST for message 29549 > > Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29549: removed > > Oct 04 10:54:23 DEBG sending CoAP ping: > > Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS: sent 41 bytes > > Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29550 added to retransmit queue (2156ms) > > Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS: received 41 bytes > > Oct 04 10:54:23 ALRT got RST for message 29550 > > Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29550: removed > > Oct 04 10:54:39 DEBG sending CoAP ping: > > Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS: sent 41 bytes > > Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29551 added to retransmit queue (2813ms) > > Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29551: retransmission #1 > > Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS: sent 41 bytes > > Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29551: retransmission #2 > > Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS: sent 41 bytes > > Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29551: retransmission #3 > > Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS: sent 41 bytes > > Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29551: retransmission #4 > > Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS: sent 41 bytes > > Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 > (if1) DTLS tid=29551: give up after 4 attempts > > Here we see the 91 seconds (dependant on the max-retransmit value > being 4) 10:56:09 10:54:39. There is 46 seconds after > transmission #4 before the confirmable ping request times out (12 > seconds for transmission #3 before retry transmission #4). > > Question 1 > > ========== > > Should the max-retransmit actually be 3, not 4 for CON requests so > that we do not get this 46 second gap? > > - CON is only used for signal configuration (infrequent, likely > only to be in peace time) and heartbeats, not mitigation requests > > Question 2 > > ========= > > If the heartbeat interval is less than 91 seconds say 60 seconds > and the first heartbeat ping is still active, should a second > heartbeat be fired off? > > - I think not, but the text then needs to get updated to state the > interval is used whenever there is not a pending heartbeat > response outstanding. > > Question 3 > > ========= > > Heartbeat checks are being initiated by the client. The client > gets a heartbeat timeout on the session. The client subsequently > needs to send a PUT mitigate request. > > Does the client set up a new session? > > - Difficult as we are unlikely to be in peace time > > - PKI exchanges are likely to fail > > - the client just needs to send a non-confirmable PUT. > > Question 4 > > ========= > > Scenario as Q3 > > Does the client re-use the old session that the heartbeats are > failing on? > > - The server may have sent a session close, but it never got through > > Question 4 > > ========== > > When the heartbeats are initiated by the server, and the heartbeat > times out, the session is bad, but the current mitigation > request continues until it expires. > > The client may have kicked off his heartbeats at a different time, > and there likely will be a sending frequency drift over time, so > the client may think the session is still active, the server not, > and the client decides it is time to send a non-confirmable PUT to > refresh the mitigation as it is about to expire or possibly > another PUT for a different IP that has just started to get > hammered hence heartbeat failures. > > Alternatively the client decides that the reason for bad session > (from the clients perspective) is an attack stopping traffic > getting through and needs to do a PUT on the existing session. > > So server receives a PUT (refresh or for a new IP) on a session > that has heartbeat expired. The session contained all the > negotiated PKI session keys etc. What should happen here? > > - as the heartbeats are failing, it is safe to assume we are not > in peace time. > > - I believe the session on the server needs to be kept hanging > around for some time post heartbeat time-out. For how long? > > - the server may be seeing the client heartbeat messages [this may > answer how to keep bad session hanging around] > > ========== > > Regards > > Jon > > *From:*Dots [mailto:ietf-supjps-dots-bounces@ietf.org] *On Behalf > Of *ietf-supjps-mohamed.boucadair@orange.com > > *Sent:* 04 October 2017 09:35 > *To:* dots@ietf.org ; Jon Shallow > (supjps-ietf@jpshallow.com ) > *Subject:* [Dots] Minimum heartbeat-interval > > Dear all, > > Jon made the following comment during the interim meeting: A: > (Jon Shallow): The minimum for the heartbeat should be 10s > > Actually, the use of 10s is not aligned with RFC8085 which says > the following: > > An application that needs to employ keep-alive messages to deliver > > useful service over UDP in the presence of middleboxes SHOULD NOT > > ^^^^^^^^^^^^^^^^^^^^^^ > > transmit them more frequently than once every 15 seconds and SHOULD > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > use longer intervals when possible. > > I suggest to add this NEW text to the signal-channel draft to > clarify the rationale for the recommended values: > > NEW: > > Note: heartbeat-interval should be tweaked to also assist DOTS > > messages for NAT traversal (SIG-010 of > > [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive > > messages must not be sent more frequently than once every 15 > > seconds and should use longer intervals when possible. > > Furthermore, [RFC4787] recommends NATs to use a state > timeout of 2 > > minutes or longer. From that standpoint, this specification > > recommends a minimum heartbeat-interval of 15 seconds and a > > maximum heartbeat-interval of 240 seconds. The recommended > value > > of 90 seconds is selected to anticipate the expiry of NAT > states, > > while avoiding overloading the network with frequent keepalives > > for NAT state maintenance purposes. Note that this recommended > > value is close to the one recommended for MAX_TRANSMIT_WAIT, > whose > > value is derived from transmission parameters (Section 4.8.2 of > > [RFC7252]). > > Thoughts? > > Cheers, > > Med > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > --------------0FDF4960E2205F278CA19F2B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote:

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote:

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds.

I'm getting different data-points for at least the minimum value. There still seems to be a lot of NATs out there with a timeout value of ~30 seconds for UDP traffic (and in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what you would want. Google did a lot of testing around this and decided they were happy with the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds).

Consent freshness has nothing to do with NAT/FW timeouts.

You are missing the point Tiru - testing has been done (in the past and more recently) and a value of ~30 seconds seems to be what works for the majority of devices. I'll trust Google on this one.

-- Flemming


-Tiru



Thanks

-- Flemming



Responses to the questions below

1) The max-retransmit parameter is negotiable and configurable, DOTS agents can pick suitable values for max-retransmit parameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).

2) No, if the DOTS agent wants to change the default heartbeat interval then the other message transmission parameters will also have to be modified.

3) The client will have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS session, the client will have to initiate (D)TLS session resumption. The heartbeat expires only after 273 seconds (3 CoAP ping confirmable messages, each
CoAP ping re-transmitted 4 times).

Med In the below text, recommended value should be 93 seconds instead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2).

-Tiru

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

Hi Mohamed,

In principal I agree with your suggested updates the minimum of 10s was an off the cuff response, to handle the broken NAT timing implementations out there.

The Heartbeat mechanism does raise a few questions in my mind which do need to be thought through. On a DOTS server, using a heartbeat interval of 15 secs, with the client going away circa 10:54:30, I get

Oct 04 10:53:51 DEBG sending CoAP ping:

Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548 added to retransmit queue (2281ms)

Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message 29548

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548: removed

Oct 04 10:54:07 DEBG sending CoAP ping:

Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549 added to retransmit queue (2938ms)

Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message 29549

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549: removed

Oct 04 10:54:23 DEBG sending CoAP ping:

Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550 added to retransmit queue (2156ms)

Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message 29550

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550: removed

Oct 04 10:54:39 DEBG sending CoAP ping:

Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551 added to retransmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #1

Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #2

Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #3

Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #4

Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: give up after 4 attempts

Here we see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:09 10:54:39. There is 46 seconds after transmission #4 before the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

Question 1

==========

Should the max-retransmit actually be 3, not 4 for CON requests so that we do not get this 46 second gap?

- CON is only used for signal configuration (infrequent, likely only to be in peace time) and heartbeats, not mitigation requests

Question 2

=========

If the heartbeat interval is less than 91 seconds say 60 seconds and the first heartbeat ping is still active, should a second heartbeat be fired off?

- I think not, but the text then needs to get updated to state the interval is used whenever there is not a pending heartbeat response outstanding.

Question 3

=========

Heartbeat checks are being initiated by the client. The client gets a heartbeat timeout on the session. The client subsequently needs to send a PUT mitigate request.

Does the client set up a new session?

- Difficult as we are unlikely to be in peace time

- PKI exchanges are likely to fail

- the client just needs to send a non-confirmable PUT.

Question 4

=========

Scenario as Q3

Does the client re-use the old session that the heartbeats are failing on?

- The server may have sent a session close, but it never got through

Question 4

==========

When the heartbeats are initiated by the server, and the heartbeat times out, the session is bad, but the current mitigation request continues until it expires.

The client may have kicked off his heartbeats at a different time, and there likely will be a sending frequency drift over time, so the client may think the session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh the mitigation as it is about to expire or possibly another PUT for a different IP that has just started to get hammered hence heartbeat failures.

Alternatively the client decides that the reason for bad session (from the clients perspective) is an attack stopping traffic getting through and needs to do a PUT on the existing session.

So server receives a PUT (refresh or for a new IP) on a session that has heartbeat expired. The session contained all the negotiated PKI session keys etc. What should happen here?

- as the heartbeats are failing, it is safe to assume we are not in peace time.

- I believe the session on the server needs to be kept hanging around for some time post heartbeat time-out. For how long?

- the server may be seeing the client heartbeat messages [this may answer how to keep bad session hanging around]

==========

Regards

Jon

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com)
Subject: [Dots] Minimum heartbeat-interval

Dear all,

Jon made the following comment during the interim meeting: A: (Jon Shallow): The minimum for the heartbeat should be 10s

Actually, the use of 10s is not aligned with RFC8085 which says the following: 

 An application that needs to employ keep-alive messages to deliver
 useful service over UDP in the presence of middleboxes SHOULD NOT
 ^^^^^^^^^^^^^^^^^^^^^^
 transmit them more frequently than once every 15 seconds and SHOULD
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 use longer intervals when possible.

I suggest to add this NEW text to the signal-channel draft to clarify the rationale for the recommended values:

NEW:

Note: heartbeat-interval should be tweaked to also assist DOTS

messages for NAT traversal (SIG-010 of

[I-D.ietf-dots-requirements]). According to [RFC8085], keepalive

messages must not be sent more frequently than once every 15

seconds and should use longer intervals when possible.

Furthermore, [RFC4787] recommends NATs to use a state timeout of 2

minutes or longer. From that standpoint, this specification

recommends a minimum heartbeat-interval of 15 seconds and a

maximum heartbeat-interval of 240 seconds. The recommended value

of 90 seconds is selected to anticipate the expiry of NAT states,

while avoiding overloading the network with frequent keepalives

for NAT state maintenance purposes. Note that this recommended

value is close to the one recommended for MAX_TRANSMIT_WAIT, whose

value is derived from transmission parameters (Section 4.8.2 of

[RFC7252]).

Thoughts?

Cheers,

Med




_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots


--------------0FDF4960E2205F278CA19F2B-- From nobody Mon Oct 9 20:18:29 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B2713431D for ; Mon, 9 Oct 2017 20:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NZwEbM3hZxZ for ; Mon, 9 Oct 2017 20:18:25 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 35481132F3F for ; Mon, 9 Oct 2017 20:18:25 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id DF39925F691; Tue, 10 Oct 2017 12:18:23 +0900 (JST) Received: from SR2-nishizuka.lv4.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id CD1A376351D; Tue, 10 Oct 2017 12:18:23 +0900 (JST) To: "Konda, Tirumaleswar Reddy" , Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" , Roland Dobbins References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> From: kaname nishizuka Message-ID: <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> Date: Tue, 10 Oct 2017 12:18:30 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B5BE7469A60F45064FD40413" Content-Language: en-US Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 03:18:28 -0000 This is a multi-part message in MIME format. --------------B5BE7469A60F45064FD40413 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, > I agree the below problems are applicable for server-side DOTS gateway, it must convey the “client identity” to the DOTS server. I agree with this server-side DOTS gateway case. At the same time, I agree with below: > I agree that is not a good thing to “leak” out internal information when passing through a DOTS GW, Then, should DOTS GW send “client identity” (i.e. certificates of DOTS clients) itself or hashed(“client identity”) to DOTS server? If later, how can DOTS server react to the ambiguous information of the hashed(“client identity”). regards, Kaname On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote: > > Hi Jon, > > I agree the below problems are applicable for server-side DOTS gateway, it must convey the “client identity” to the DOTS server. But for the client-side DOTS gateway, it should resolve conflicting rules b/w DOTS clients (e.g. one client installing black-list ACL for an IP address but the other client installs white-list ACL for the same IP address, same alias-names for different mitigation scopes). I don’t see the need for a client-side DOTS gateway to convey the “client identity” to the server-side DOTS gateway or DOTS server. > > -Tiru > > *From:*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Sent:* Saturday, October 7, 2017 2:07 PM > *To:* Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins > *Subject:* RE: [Dots] DOTS Gateways Challenges > > Hi Tiru, > > This discussion goes beyond just the mitigation request.  We need to consider what happens with both alias-name and acl-name (data channel) > > The simple case of a mitigation request with no alias-name does not require any knowledge of the original client. > > However, if the mitigation request uses alias-name, then there are 3 ways of handling this > > a)The DOTS GW replaces the alias-name with its actual definition (target-ips etc. merged as appropriate), so alias-name is not forwarded on to Server – just the expanded mitigation request is forwarded > > b)The DOTS GW updates the alias-name with a unique alias-name that is forwarded (and has to do the same thing when the alias-name is configured on the data channel) – to handle 2 or more clients defining the same alias-name which have different characteristics > > c)The DOTS GW recognises that alias-name is not unique and adds in ”additional-client-info” (I think I prefer this “-info” name to client-id or original-client-id as “-id” is too closely  associated with Client Identity derived from the DOTS GW Client certificate) > > We have agreed that when a client requests mitigation status, the “alias-name” should be returned as “alias-name” and not the substituted alias-name configuration (this does need to be stated in the spec for clarity).  This makes (a) difficult to be handled by DOTS GW which then raises the question – do we really need alias-name? > > The definition and association of ACLs/Filters of the data channel is more difficult – the Server must install / apply the appropriate ACLs on a per (Original) Client basis when mitigation is invoked. > > Client 1’s concept of a Whitelist IP could be Client 2’s concept of a Blacklist IP.  The Server needs to know which client is requesting the mitigation and install the correct ACLs – if there was no ”additional-client-info”, the Server only knows that he has to install ALL of the ACLs (i.e. both the Black and White list of the same IP as defined by Client 1 and Client 2) as defined by his client (DOTS GW) when his client requests a mitigation.  Here, I think that if there is more than one client for the DOTS GW, ”additional-client-info” is required. > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org ] *On Behalf Of *Konda, Tirumaleswar Reddy > *Sent:* 07 October 2017 04:28 > *To:* Jon Shallow; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > *Subject:* Re: [Dots] DOTS Gateways Challenges > > In case of client-side DOTS gateway, why does the DOTS server need to know which “DOTS client” has conveyed the mitigation request ? > > For example, the DOTS client could be a DDoS detector or an Application server, and the client-side gateway will have to resolve the conflicting mitigation requests from the DOTS clients, aggregate the mitigation requests from the DOTS client and send the updated mitigation request to the DOTS server. > > -Tiru > > *From:*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Sent:* Friday, October 6, 2017 7:42 PM > *To:* Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > > *Subject:* RE: [Dots] DOTS Gateways Challenges > > Hi Tiru, > > Unless I am missing something, how does the Client side of DOTS GW convey to the upstream server a unique “client-id” which is different to the implied client id as derived from the PKI certificate that the DOTS GW’Client uses/presents when communicating to the server? > > To me, there needs to be an option such as “original-client-id” or “client-id” (which is confusing when also referring to the client identity as derived from the (DOTS GW) Client’s PKI certificate) as a part of the protocol. > > I agree that the DOTS GW can generate its own unique client-id to stop multiple entries being needed. > > I agree that is not a good thing to “leak” out internal information when passing through a DOTS GW, so my REQUIRED does not make sense. > > Regards > > Jon > > PS – I am having to deal with other stuff at present – I will get back later on the other issues under discussion > > *From:*Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com ] > *Sent:* 06 October 2017 14:58 > *To:* mohamed.boucadair@orange.com ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org > *Subject:* RE: [Dots] DOTS Gateways Challenges > > I don’t see a need for client-side DOTS gateway to convey the “DOTS client identity” to the DOTS server. “DOTS client identity” looks required only for the server-side DOTS gateways. In case of server-side DOTS gateway, it can convey the client-id generated from the “DOTS client identity” to the DOTS server. The DOTS gateway can generate a unique client-id and does not have to send an array of client-ids to the DOTS server to resolve clashes. > > -Tiru > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------B5BE7469A60F45064FD40413 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

> I agree the below problems are applicable for server-side DOTS gateway, it must convey the “client identity” to the DOTS server.
I agree with this server-side DOTS gateway case.
At the same time, I agree with below:
> I agree that is not a good thing to “leak” out internal information when passing through a DOTS GW,

Then, should DOTS GW send “client identity” (i.e. certificates of DOTS clients) itself or hashed(“client identity”) to DOTS server?
If later, how can DOTS server react to the ambiguous information of the hashed(“client identity”).

regards,
Kaname



On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote:

Hi Jon,

 

I agree the below problems are applicable for server-side DOTS gateway, it must convey the “client identity” to the DOTS server. But for the client-side DOTS gateway, it should resolve conflicting rules b/w DOTS clients (e.g. one client installing black-list ACL for an IP address but the other client installs white-list ACL for the same IP address, same alias-names for different mitigation scopes). I don’t see the need for a client-side DOTS gateway to convey the “client identity” to the server-side DOTS gateway or DOTS server.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Saturday, October 7, 2017 2:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins <rdobbins@arbor.net>
Subject: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We need to consider what happens with both alias-name and acl-name (data channel)

 

The simple case of a mitigation request with no alias-name does not require any knowledge of the original client. 

 

However, if the mitigation request uses alias-name, then there are 3 ways of handling this

a)       The DOTS GW replaces the alias-name with its actual definition (target-ips etc. merged as appropriate), so alias-name is not forwarded on to Server – just the expanded mitigation request is forwarded

b)      The DOTS GW updates the alias-name with a unique alias-name that is forwarded (and has to do the same thing when the alias-name is configured on the data channel) – to handle 2 or more clients defining the same alias-name which have different characteristics

c)       The DOTS GW recognises that alias-name is not unique and adds in ”additional-client-info” (I think I prefer this “-info” name to client-id or original-client-id as “-id” is too closely  associated with Client Identity derived from the DOTS GW Client certificate)

We have agreed that when a client requests mitigation status, the “alias-name” should be returned as “alias-name” and not the substituted alias-name configuration (this does need to be stated in the spec for clarity).  This makes (a) difficult to be handled by DOTS GW which then raises the question – do we really need alias-name?

 

The definition and association of ACLs/Filters of the data channel is more difficult – the Server must install / apply the appropriate ACLs on a per (Original) Client basis when mitigation is invoked.

Client 1’s concept of a Whitelist IP could be Client 2’s concept of a Blacklist IP.  The Server needs to know which client is requesting the mitigation and install the correct ACLs – if there was no ”additional-client-info”, the Server only knows that he has to install ALL of the ACLs (i.e. both the Black and White list of the same IP as defined by Client 1 and Client 2) as defined by his client (DOTS GW) when his client requests a mitigation.  Here, I think that if there is more than one client for the DOTS GW, ”additional-client-info” is required.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 04:28
To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

 

In case of client-side DOTS gateway, why does the DOTS server need to know which “DOTS client” has conveyed the mitigation request ?

For example, the DOTS client could be a DDoS detector or an Application server, and the client-side gateway will have to resolve the conflicting mitigation requests from the DOTS clients, aggregate the mitigation requests from the DOTS client and send the updated mitigation request to the DOTS server.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, October 6, 2017 7:42 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins <rdobbins@arbor.net>
Subject: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW convey to the upstream server a unique “client-id” which is different to the implied client id as derived from the PKI certificate that the DOTS GW’Client uses/presents when communicating to the server?

To me, there needs to be an option such as “original-client-id” or “client-id” (which is confusing when also referring to the client identity as derived from the (DOTS GW) Client’s PKI certificate) as a part of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to stop multiple entries being needed.

 

I agree that is not a good thing to “leak” out internal information when passing through a DOTS GW, so my REQUIRED does not make sense.

 

Regards

 

Jon

PS – I am having to deal with other stuff at present – I will get back later on the other issues under discussion

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 06 October 2017 14:58
To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: [Dots] DOTS Gateways Challenges

 

I don’t see a need for client-side DOTS gateway to convey the “DOTS client identity” to the DOTS server. “DOTS client identity” looks required only for the server-side DOTS gateways. In case of server-side DOTS gateway, it can convey the client-id generated from the “DOTS client identity” to the DOTS server. The DOTS gateway can generate a unique client-id and does not have to send an array of client-ids to the DOTS server to resolve clashes.

 

-Tiru



_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--------------B5BE7469A60F45064FD40413-- From nobody Mon Oct 9 20:31:39 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BAC13431D for ; Mon, 9 Oct 2017 20:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GkA-g1-2ojx for ; Mon, 9 Oct 2017 20:31:32 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA62132F30 for ; Mon, 9 Oct 2017 20:31:31 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 7709425F68D; Tue, 10 Oct 2017 12:31:31 +0900 (JST) Received: from SR2-nishizuka.lv4.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 1A36B75900A; Tue, 10 Oct 2017 12:31:31 +0900 (JST) To: Flemming Andreasen , "Konda, Tirumaleswar Reddy" , Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com> From: kaname nishizuka Message-ID: <4406f5bc-60ea-96dc-d74b-a74430b83285@nttv6.jp> Date: Tue, 10 Oct 2017 12:31:37 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com> Content-Type: multipart/alternative; boundary="------------7C018C858806845D21AC53F4" Content-Language: en-US Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 03:31:37 -0000 This is a multi-part message in MIME format. --------------7C018C858806845D21AC53F4 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I agree with Flemming's suggestion. Practically, the timeout will be set to ~30 seconds by operators like us. regards, kaname On 2017/10/10 1:35, Flemming Andreasen wrote: > > > On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote: >> >> *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Flemming Andreasen >> *Sent:* Monday, October 9, 2017 9:12 PM >> *To:* Konda, Tirumaleswar Reddy ; Jon Shallow ; mohamed.boucadair@orange.com; dots@ietf.org >> *Subject:* Re: [Dots] Minimum heartbeat-interval >> >> On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: >> >> http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds. >> >> I'm getting different data-points for at least the minimum value. There still seems to be a lot of NATs out there with a timeout value of ~30 seconds for UDP traffic (and in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what you would want. Google did a lot of testing around this and decided they were happy with the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds). >> >> Consent freshness has nothing to do with NAT/FW timeouts. >> > You are missing the point Tiru - testing has been done (in the past and more recently) and a value of ~30 seconds seems to be what works for the majority of devices. I'll trust Google on this one. > > -- Flemming > > >> -Tiru >> >> >> >> Thanks >> >> -- Flemming >> >> >> >> Responses to the questions below >> >> 1) The max-retransmit parameter is negotiable and configurable, DOTS agents can pick suitable values for max-retransmit parameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds). >> >> 2) No, if the DOTS agent wants to change the default heartbeat interval then the other message transmission parameters will also have to be modified. >> >> 3) The client will have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption >> >> 4) If heartbeat expires then the DOTS server will close the (D)TLS session, the client will have to initiate (D)TLS session resumption. The heartbeat expires only after 273 seconds (3 CoAP ping confirmable messages, each >> CoAP ping re-transmitted 4 times). >> >> Med In the below text, recommended value should be 93 seconds instead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). >> >> -Tiru >> >> *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Jon Shallow >> *Sent:* Wednesday, October 4, 2017 5:36 PM >> *To:* mohamed.boucadair@orange.com ; dots@ietf.org >> *Subject:* Re: [Dots] Minimum heartbeat-interval >> >> Hi Mohamed, >> >> In principal I agree with your suggested updates the minimum of 10s was an off the cuff response, to handle the broken NAT timing implementations out there. >> >> The Heartbeat mechanism does raise a few questions in my mind which do need to be thought through. On a DOTS server, using a heartbeat interval of 15 secs, with the client going away circa 10:54:30, I get >> >> Oct 04 10:53:51 DEBG sending CoAP ping: >> >> Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes >> >> Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548 added to retransmit queue (2281ms) >> >> Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes >> >> Oct 04 10:53:51 ALRT got RST for message 29548 >> >> Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548: removed >> >> Oct 04 10:54:07 DEBG sending CoAP ping: >> >> Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes >> >> Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549 added to retransmit queue (2938ms) >> >> Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes >> >> Oct 04 10:54:07 ALRT got RST for message 29549 >> >> Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549: removed >> >> Oct 04 10:54:23 DEBG sending CoAP ping: >> >> Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes >> >> Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550 added to retransmit queue (2156ms) >> >> Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes >> >> Oct 04 10:54:23 ALRT got RST for message 29550 >> >> Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550: removed >> >> Oct 04 10:54:39 DEBG sending CoAP ping: >> >> Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes >> >> Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551 added to retransmit queue (2813ms) >> >> Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #1 >> >> Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes >> >> Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #2 >> >> Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes >> >> Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #3 >> >> Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes >> >> Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #4 >> >> Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes >> >> Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: give up after 4 attempts >> >> Here we see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:09 10:54:39. There is 46 seconds after transmission #4 before the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4). >> >> Question 1 >> >> ========== >> >> Should the max-retransmit actually be 3, not 4 for CON requests so that we do not get this 46 second gap? >> >> - CON is only used for signal configuration (infrequent, likely only to be in peace time) and heartbeats, not mitigation requests >> >> Question 2 >> >> ========= >> >> If the heartbeat interval is less than 91 seconds say 60 seconds and the first heartbeat ping is still active, should a second heartbeat be fired off? >> >> - I think not, but the text then needs to get updated to state the interval is used whenever there is not a pending heartbeat response outstanding. >> >> Question 3 >> >> ========= >> >> Heartbeat checks are being initiated by the client. The client gets a heartbeat timeout on the session. The client subsequently needs to send a PUT mitigate request. >> >> Does the client set up a new session? >> >> - Difficult as we are unlikely to be in peace time >> >> - PKI exchanges are likely to fail >> >> - the client just needs to send a non-confirmable PUT. >> >> Question 4 >> >> ========= >> >> Scenario as Q3 >> >> Does the client re-use the old session that the heartbeats are failing on? >> >> - The server may have sent a session close, but it never got through >> >> Question 4 >> >> ========== >> >> When the heartbeats are initiated by the server, and the heartbeat times out, the session is bad, but the current mitigation request continues until it expires. >> >> The client may have kicked off his heartbeats at a different time, and there likely will be a sending frequency drift over time, so the client may think the session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh the mitigation as it is about to expire or possibly another PUT for a different IP that has just started to get hammered hence heartbeat failures. >> >> Alternatively the client decides that the reason for bad session (from the clients perspective) is an attack stopping traffic getting through and needs to do a PUT on the existing session. >> >> So server receives a PUT (refresh or for a new IP) on a session that has heartbeat expired. The session contained all the negotiated PKI session keys etc. What should happen here? >> >> - as the heartbeats are failing, it is safe to assume we are not in peace time. >> >> - I believe the session on the server needs to be kept hanging around for some time post heartbeat time-out. For how long? >> >> - the server may be seeing the client heartbeat messages [this may answer how to keep bad session hanging around] >> >> ========== >> >> Regards >> >> Jon >> >> *From:*Dots [mailto:ietf-supjps-dots-bounces@ietf.org] *On Behalf Of *ietf-supjps-mohamed.boucadair@orange.com >> *Sent:* 04 October 2017 09:35 >> *To:* dots@ietf.org ; Jon Shallow (supjps-ietf@jpshallow.com ) >> *Subject:* [Dots] Minimum heartbeat-interval >> >> Dear all, >> >> Jon made the following comment during the interim meeting: A: (Jon Shallow): The minimum for the heartbeat should be 10s >> >> Actually, the use of 10s is not aligned with RFC8085 which says the following: >> >> An application that needs to employ keep-alive messages to deliver >> >> useful service over UDP in the presence of middleboxes SHOULD NOT >> >> ^^^^^^^^^^^^^^^^^^^^^^ >> >> transmit them more frequently than once every 15 seconds and SHOULD >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> use longer intervals when possible. >> >> I suggest to add this NEW text to the signal-channel draft to clarify the rationale for the recommended values: >> >> NEW: >> >> Note: heartbeat-interval should be tweaked to also assist DOTS >> >> messages for NAT traversal (SIG-010 of >> >> [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive >> >> messages must not be sent more frequently than once every 15 >> >> seconds and should use longer intervals when possible. >> >> Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 >> >> minutes or longer. From that standpoint, this specification >> >> recommends a minimum heartbeat-interval of 15 seconds and a >> >> maximum heartbeat-interval of 240 seconds. The recommended value >> >> of 90 seconds is selected to anticipate the expiry of NAT states, >> >> while avoiding overloading the network with frequent keepalives >> >> for NAT state maintenance purposes. Note that this recommended >> >> value is close to the one recommended for MAX_TRANSMIT_WAIT, whose >> >> value is derived from transmission parameters (Section 4.8.2 of >> >> [RFC7252]). >> >> Thoughts? >> >> Cheers, >> >> Med >> >> >> >> >> _______________________________________________ >> >> Dots mailing list >> >> Dots@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dots >> > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------7C018C858806845D21AC53F4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I agree with Flemming's suggestion.
Practically, the timeout will be set to ~30 seconds by operators like us.

regards,
kaname

On 2017/10/10 1:35, Flemming Andreasen wrote:


On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote:

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote:

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds.

I'm getting different data-points for at least the minimum value. There still seems to be a lot of NATs out there with a timeout value of ~30 seconds for UDP traffic (and in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what you would want. Google did a lot of testing around this and decided they were happy with the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds).

Consent freshness has nothing to do with NAT/FW timeouts.

You are missing the point Tiru - testing has been done (in the past and more recently) and a value of ~30 seconds seems to be what works for the majority of devices. I'll trust Google on this one.

-- Flemming


-Tiru



Thanks

-- Flemming



Responses to the questions below

1) The max-retransmit parameter is negotiable and configurable, DOTS agents can pick suitable values for max-retransmit parameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).

2) No, if the DOTS agent wants to change the default heartbeat interval then the other message transmission parameters will also have to be modified.

3) The client will have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS session, the client will have to initiate (D)TLS session resumption. The heartbeat expires only after 273 seconds (3 CoAP ping confirmable messages, each
CoAP ping re-transmitted 4 times).

Med In the below text, recommended value should be 93 seconds instead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2).

-Tiru

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

Hi Mohamed,

In principal I agree with your suggested updates the minimum of 10s was an off the cuff response, to handle the broken NAT timing implementations out there.

The Heartbeat mechanism does raise a few questions in my mind which do need to be thought through. On a DOTS server, using a heartbeat interval of 15 secs, with the client going away circa 10:54:30, I get

Oct 04 10:53:51 DEBG sending CoAP ping:

Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548 added to retransmit queue (2281ms)

Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message 29548

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548: removed

Oct 04 10:54:07 DEBG sending CoAP ping:

Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549 added to retransmit queue (2938ms)

Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message 29549

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549: removed

Oct 04 10:54:23 DEBG sending CoAP ping:

Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550 added to retransmit queue (2156ms)

Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message 29550

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550: removed

Oct 04 10:54:39 DEBG sending CoAP ping:

Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551 added to retransmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #1

Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #2

Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #3

Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #4

Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: give up after 4 attempts

Here we see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:09 10:54:39. There is 46 seconds after transmission #4 before the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

Question 1

==========

Should the max-retransmit actually be 3, not 4 for CON requests so that we do not get this 46 second gap?

- CON is only used for signal configuration (infrequent, likely only to be in peace time) and heartbeats, not mitigation requests

Question 2

=========

If the heartbeat interval is less than 91 seconds say 60 seconds and the first heartbeat ping is still active, should a second heartbeat be fired off?

- I think not, but the text then needs to get updated to state the interval is used whenever there is not a pending heartbeat response outstanding.

Question 3

=========

Heartbeat checks are being initiated by the client. The client gets a heartbeat timeout on the session. The client subsequently needs to send a PUT mitigate request.

Does the client set up a new session?

- Difficult as we are unlikely to be in peace time

- PKI exchanges are likely to fail

- the client just needs to send a non-confirmable PUT.

Question 4

=========

Scenario as Q3

Does the client re-use the old session that the heartbeats are failing on?

- The server may have sent a session close, but it never got through

Question 4

==========

When the heartbeats are initiated by the server, and the heartbeat times out, the session is bad, but the current mitigation request continues until it expires.

The client may have kicked off his heartbeats at a different time, and there likely will be a sending frequency drift over time, so the client may think the session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh the mitigation as it is about to expire or possibly another PUT for a different IP that has just started to get hammered hence heartbeat failures.

Alternatively the client decides that the reason for bad session (from the clients perspective) is an attack stopping traffic getting through and needs to do a PUT on the existing session.

So server receives a PUT (refresh or for a new IP) on a session that has heartbeat expired. The session contained all the negotiated PKI session keys etc. What should happen here?

- as the heartbeats are failing, it is safe to assume we are not in peace time.

- I believe the session on the server needs to be kept hanging around for some time post heartbeat time-out. For how long?

- the server may be seeing the client heartbeat messages [this may answer how to keep bad session hanging around]

==========

Regards

Jon

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com)
Subject: [Dots] Minimum heartbeat-interval

Dear all,

Jon made the following comment during the interim meeting: A: (Jon Shallow): The minimum for the heartbeat should be 10s

Actually, the use of 10s is not aligned with RFC8085 which says the following: 

 An application that needs to employ keep-alive messages to deliver
 useful service over UDP in the presence of middleboxes SHOULD NOT
 ^^^^^^^^^^^^^^^^^^^^^^
 transmit them more frequently than once every 15 seconds and SHOULD
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 use longer intervals when possible.

I suggest to add this NEW text to the signal-channel draft to clarify the rationale for the recommended values:

NEW:

Note: heartbeat-interval should be tweaked to also assist DOTS

messages for NAT traversal (SIG-010 of

[I-D.ietf-dots-requirements]). According to [RFC8085], keepalive

messages must not be sent more frequently than once every 15

seconds and should use longer intervals when possible.

Furthermore, [RFC4787] recommends NATs to use a state timeout of 2

minutes or longer. From that standpoint, this specification

recommends a minimum heartbeat-interval of 15 seconds and a

maximum heartbeat-interval of 240 seconds. The recommended value

of 90 seconds is selected to anticipate the expiry of NAT states,

while avoiding overloading the network with frequent keepalives

for NAT state maintenance purposes. Note that this recommended

value is close to the one recommended for MAX_TRANSMIT_WAIT, whose

value is derived from transmission parameters (Section 4.8.2 of

[RFC7252]).

Thoughts?

Cheers,

Med




_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots




_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--------------7C018C858806845D21AC53F4-- From nobody Tue Oct 10 02:05:16 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34BE134B11 for ; Tue, 10 Oct 2017 02:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=verisign.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 44R4zGxW1iDs for ; Tue, 10 Oct 2017 02:05:09 -0700 (PDT) Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE64134B0B for ; Tue, 10 Oct 2017 02:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=52080; q=dns/txt; s=VRSN; t=1507626310; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XeMty0lf0S2UYV2iZGWuZMD0tSO6VLtIeCuFRR0mahM=; b=LAaG5+CaqRvB4kOK2hDajGGIZ+d5S6uYy3ZUsksU29mO1joXWAqr5aJP 2NXNbxmzqll4j6+1SJDuicNgvUmJFARxCNkR1iZeMCOAlb7J8D6C17J/P qEB02LO2Ug7AQpy9VuI19Q/j/f7tMY2BzXlweAVyCPSoLjwsDChS4USSe Sc4pn6Ji5QfqsZvCXAlHiuyxXCrW1zKFIXZeupIVX5bpdaar+CxALE+5g eDVojnFTTVeG4tNJyvY4oR6kWH0DZ9MeyhiDw4zXPE5IDXqDTmUdsZ1j/ rJyPxR/Qvmx1QDwHsFO7W9b+lehHITZJTvGvYLGdALmDAI3LmOFhHj12B w==; X-IronPort-AV: E=Sophos;i="5.42,504,1500940800"; d="scan'208,217";a="2832917" IronPort-PHdr: =?us-ascii?q?9a23=3AM4pcWhROAD+oRQO0KoYpG2J2L9psv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa67ZRGDt8tkgFKBZ4jH8fUM07OQ6PGwHzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLdxIRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlD?= =?us-ascii?q?kIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWGhPUdtLVyFZAo2y?= =?us-ascii?q?cZYBD/YPM+hboYnypUcBohSlCAa2GO/vzyVFimPq0aA61ekqDAHI3BYnH9ILqH?= =?us-ascii?q?nYosv7O7kIXuC60anH0y3PZO5O1zf864jEfA0qrPaKXbJsb8Xe00YvFx7bgViL?= =?us-ascii?q?t4zqISmV1uUWs2ia4OpgU/ijhHIgqwF0uzWiwNonhIfOhoIQ0F/E9CN5zZ40Jd?= =?us-ascii?q?KmVE57b8SoEJxKtyGVL4d2WcIiQ250tyY9z70GvIS3fC8QyJQowRPUdv+Jc5CQ?= =?us-ascii?q?7x7+SOqdOyp0iXBrdb6lmhq/8UatxvfiWsS70FtHqDdOnMPWuXAXzRPT79CKSv?= =?us-ascii?q?56/ki8xzmCzxvT6uRYIUAskqrbNoIhzqYwlpUNtUTDGTf7l17sjK+Qa0kk/uep?= =?us-ascii?q?6+H9bbXnop+cMJJ0ih3iPqgwgMC/H/o3MhIPX2iA+OS827vj8VflT7VNi/06iq?= =?us-ascii?q?jZsJbEKsQHvqO1HhNZ3pw+5xu9ATqqyskUkHkJIV5fZh6KgIjkN0nLIP/iDPe/?= =?us-ascii?q?h1qskC1sx/DDJrDhBInNIWbZn7fuYLZy9VVRyBQtwtBF5pJUEbABIP31WkPrqN?= =?us-ascii?q?PYCRo5PxSuw+n7ENV9yp8eWWWXD6CEN6PSrUSI6/kuI+aSeI8VtizxK/8/5/7h?= =?us-ascii?q?lXU5g0MSfbG13ZsLb3C1BvFmI0KZYXX2h9cOD3oFshAlQ+ztlV2NTSRcaGuoUK?= =?us-ascii?q?I9/DE2E4WmDZ3ZSYCrj7yOwj23EYFRZmBDElqMC2vnd52YW/cQbyKfOtRhkiEc?= =?us-ascii?q?VbijU48hzgiitA7kxLp7IOrZ4S8YtYr41Nh1/eLTkRUy9Tt6DsiHz26NSGR0lH?= =?us-ascii?q?sSRzAqxKB/vVB9ylCb3KZmgvxYD8FT5/ZTXQc+K5Hc1OJ7BMroWgzdYNiGVUup?= =?us-ascii?q?Q9W+Dj80SdIxxcIBbFxmFtWnkh/MxSSqDKELmLCRGJM09afc1WDrJ8lh03bGyL?= =?us-ascii?q?Uhj14+T8tBL2KmgLNw9xLNCIHTiEWUjLqldaUH3CHR82eP13aBvEZdUARoS6XK?= =?us-ascii?q?QWgfZlfKrdT+/k7CTKWhCbI9PQtE18GPMa1KasH1jVVYRfrvItbeY3ri01u3UB?= =?us-ascii?q?WBwLqJYcLsen4d3TfAC0FMxwMa+3+DOCA4Gju//STcFGo9O0joZhamzeR3p262?= =?us-ascii?q?CgcSzgLAJxlny7e89QMYreKRUfII370C/iwmrmMnTx6Gw9vKBo/Y9EJad6JGbI?= =?us-ascii?q?Z4uQ8f2A=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2FDAQDDjNxZ//WZrQpZAxkBAQEBAQEBAQEBAQcBAQEBARQ?= =?us-ascii?q?BAQEBAQEBAQEBAQcBAQEBAYJEP4ERgRWfYSKCd5NGggEDChgBDIUWAoUFFQEBA?= =?us-ascii?q?QEBAQEBAQEBAoEQgjgkAQ1GLAEBAQEBAQEBASMBAQEBAQEjAg0xLAEBAQEBAgE?= =?us-ascii?q?BGA0GOwYLEAIBCA0EAQMBASEBBgcnCxQDBggCBA4FiUB0qXs6iyQBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdgykEg1SBaSsLgnODe1EgAh0HExURgnuCMgWKC4khjhA?= =?us-ascii?q?Ch1yPe5AflTQCBAsCGQGBOQ8mcj94FUkSAYUEAxyBZ3YBAYo+AQEB?= Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id v9A955xZ030268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Oct 2017 05:05:06 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Tue, 10 Oct 2017 05:05:05 -0400 From: "Teague, Nik" To: kaname nishizuka CC: Flemming Andreasen , "Konda, Tirumaleswar Reddy" , Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AQHTQabcPwAEEUqQsEedzoCS6HZY9Q== Date: Tue, 10 Oct 2017 09:05:04 +0000 Message-ID: <48E2524D-FEA4-4765-A3A8-0A2B01D906AE@Verisign.com> References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com>, <4406f5bc-60ea-96dc-d74b-a74430b83285@nttv6.jp> In-Reply-To: <4406f5bc-60ea-96dc-d74b-a74430b83285@nttv6.jp> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_48E2524DFEA44765A3A80A2B01D906AEVerisigncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 09:05:14 -0000 --_000_48E2524DFEA44765A3A80A2B01D906AEVerisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 for ~30s On 10 Oct 2017, at 04:31, kaname nishizuka > wrote: I agree with Flemming's suggestion. Practically, the timeout will be set to ~30 seconds by operators like us. regards, kaname On 2017/10/10 1:35, Flemming Andreasen wrote: On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote: From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen Sent: Monday, October 9, 2017 9:12 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow = ; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. I'm getting different data-points for at least the minimum value. There sti= ll seems to be a lot of NATs out there with a timeout value of ~30 seconds = for UDP traffic (and in rare cases even lower), which suggests that a timeo= ut value slightly lower than 30 seconds is what you would want. Google did = a lot of testing around this and decided they were happy with the values in= https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds). Consent freshness has nothing to do with NAT/FW timeouts. You are missing the point Tiru - testing has been done (in the past and mor= e recently) and a value of ~30 seconds seems to be what works for the major= ity of devices. I'll trust Google on this one. -- Flemming -Tiru Thanks -- Flemming Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). 2) No, if the DOTS agent wants to change the default heartbeat interval the= n the other message transmission parameters will also have to be modified. 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 =93CoAP ping=94 confirmable messages, eac= h =93CoAP ping=94 re-transmitted 4 times). Med =96 In the below text, recommended value should be 93 seconds instead o= f 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates =96 the minimum of 10s was= an off the cuff response, to handle the =93broken=94 NAT timing implementa= tions out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 =96 10:54:39. There is 46 seconds after transmission #4 before th= e confirmable ping request times out (12 seconds for transmission #3 before= retry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds =96 say 60 seconds and th= e first heartbeat ping is still active, should a second heartbeat be fired = off? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is =93bad=94, but the current mitigation request continues u= ntil it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered =96 hence heartbeat failures. Alternatively the client decides that the reason for =93bad=94 session (fro= m the client=92s perspective) is an attack stopping traffic getting through= and needs to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep =93bad=94 session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: =93A: (Jon Shall= ow): The minimum for the heartbeat should be 10s=94 Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_48E2524DFEA44765A3A80A2B01D906AEVerisigncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 for ~30s

On 10 Oct 2017, at 04:31, kaname nishizuka <kaname@nttv6.jp> wrote:


I agree with Flemming's suggestion.
Practically, the timeout will be set to ~30 seconds by operators like us.
regards,
kaname

On 2017/10/10 1:35, Flemming Andreasen wrote= :


On 10/9/17 11:55 AM, Konda, Tirumaleswar Red= dy wrote:

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

 

On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote:=

http://conferences.sigcomm.org/imc/2010/papers/p2= 60.pdf referenced by ht= tps://tools.ietf.org/html/rfc7925 has tested NAT behavior with various = routers and lists the timeout results. The majority of the devices (62%) ha= ve a timeout between 2 and 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peer= s in both directions is 54 seconds.

 

I'm getting dif= ferent data-points for at least the minimum value. There still seems to be = a lot of NATs out there with a timeout value of ~30 seconds for UDP traffic (and in rare cases even lower), which= suggests that a timeout value slightly lower than 30 seconds is what you w= ould want. Google did a lot of testing around this and decided they were ha= ppy with the values in ht= tps://tools.ietf.org/html/rfc7675 (i.e. 30 seconds).  

Consent freshness has nothing to do with NAT/FW timeouts.

You are missing the point Tiru - testing has been done (in the past and mor= e recently) and a value of ~30 seconds seems to be what works for the major= ity of devices. I'll trust Google on this one.

-- Flemming


 

-Tiru



Thanks

-- Flemming



Responses to the questions below

 

1) The max-retransmit parameter is negotiable and configurable,&nbs= p; DOTS agents can pick suitable values for max-retransmit parameter based = on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds). <= /o:p>

2) No, if the DOTS agent wants to change the default heartbeat inte= rval then the other message transmission parameters will also have to be mo= dified.

3) The client will have to assume the session is disconnected (see = the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The he= artbeat expires only after 273 seconds (3 =93CoAP ping=94 confirmable messages, each
=93CoAP ping=94 re-transmitted 4 times).

 

Med =96 In the below text, recommended value should be 93 seconds i= nstead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). <= /p>

 

-Tiru

 

From:<= /span> Dots [mailto:dots-bounces@ietf= .org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadair@orange.com; dots@ietf.org=
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

 <= /span>

In prin= cipal I agree with your suggested updates =96 the minimum of 10s was an off= the cuff response, to handle the =93broken=94 NAT timing implementations o= ut there. 

 <= /span>

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

 <= /span>

Oct 04 10:53:5= 1 DEBG sending CoAP ping:

Oct 04 10:53:5= 1 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: s= ent 41 bytes

Oct 04 10:53:5= 1 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9548 added to retransmit queue (2281ms)

Oct 04 10:53:5= 1 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: r= eceived 41 bytes

Oct 04 10:53:5= 1 ALRT got RST for message 29548

Oct 04 10:53:5= 1 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9548: removed

Oct 04 10:54:0= 7 DEBG sending CoAP ping:

Oct 04 10:54:0= 7 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: s= ent 41 bytes

Oct 04 10:54:0= 7 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9549 added to retransmit queue (2938ms)

Oct 04 10:54:0= 7 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: r= eceived 41 bytes

Oct 04 10:54:0= 7 ALRT got RST for message 29549

Oct 04 10:54:0= 7 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9549: removed

Oct 04 10:54:2= 3 DEBG sending CoAP ping:

Oct 04 10:54:2= 3 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: s= ent 41 bytes

Oct 04 10:54:2= 3 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9550 added to retransmit queue (2156ms)

Oct 04 10:54:2= 3 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: r= eceived 41 bytes

Oct 04 10:54:2= 3 ALRT got RST for message 29550

Oct 04 10:54:2= 3 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9550: removed

Oct 04 10:54:3= 9 DEBG sending CoAP ping:

Oct 04 10:54:3= 9 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: s= ent 41 bytes

Oct 04 10:54:3= 9 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9551 added to retransmit queue (2813ms)

Oct 04 10:54:4= 2 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9551: retransmission #1

Oct 04 10:54:4= 2 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: s= ent 41 bytes

Oct 04 10:54:4= 8 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9551: retransmission #2

Oct 04 10:54:4= 8 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: s= ent 41 bytes

Oct 04 10:55:0= 0 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9551: retransmission #3

Oct 04 10:55:0= 0 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: s= ent 41 bytes

Oct 04 10:55:2= 3 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9551: retransmission #4

Oct 04 10:55:2= 3 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: s= ent 41 bytes

Oct 04 10:56:0= 9 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D2= 9551: give up after 4 attempts

 <= /span>

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 =96 10:54:39.  There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

 <= /span>

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

 <= /span>

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds =96 say 60 seconds and the first= heartbeat ping is still active, should a second heartbeat be fired off?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

 <= /span>

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

 <= /span>

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Scenari= o as Q3

 <= /span>

Does th= e client re-use the old session that the heartbeats are failing on?<= o:p>

- The s= erver may have sent a session close, but it never got through

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is =93bad=94, but the current mitigation request continues until it= expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered =96 hence heartbeat failures= . 

Alterna= tively the client decides that the reason for =93bad=94 session (from the c= lient=92s perspective) is an attack stopping traffic getting through and ne= eds to do a PUT on the existing session.

 <= /span>

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep =93bad=94 session hanging around]

 <= /span>

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

Regards=

 <= /span>

Jon

 <= /span>

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org= ] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com<= br> Sent: 04 October 2017 09:35
To: dots@i= etf.org; Jon Shallow (supjps-ietf@jpshallow.com)
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during th= e interim meeting: =93A: (Jon Shall= ow): The minimum for the heartbeat should be 10s=94

 

Actually, the use of 10s is not aligned = with RFC8085 which says the following:

 

   An application that needs to employ keep-alive messages t=
o deliver
   useful service over UDP in the presence of middleboxes SH=
OULD NOT
           &nbs=
p;            &=
nbsp;           &nbs=
p;         ^^^^^^^^^^^^^^^^^^^^^^
   transmit them more frequently than once every 15 seconds =
and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^
   use longer intervals when possible.  

 


I suggest to add this NEW text to the si=
gnal-channel draft to clarify the rationale for the recommended values:



 


NEW:


      Note:=
 heartbeat-interval should be tweaked to also assist DOTS=



      messa=
ges for NAT traversal (SIG-010 of


      [I-D.=
ietf-dots-requirements]).  According to [RFC8085], keepalive


      messa=
ges must not be sent more frequently than once every 15

      secon=
ds and should use longer intervals when possible.


      Furth=
ermore, [RFC4787] recommends NATs to use a state timeout of 2


      minut=
es or longer.  From that standpoint, this specification


      recom=
mends a minimum heartbeat-interval of 15 seconds and a

      maxim=
um heartbeat-interval of 240 seconds.  The recommended value


      of 90=
 seconds is selected to anticipate the expiry of NAT states,


      while=
 avoiding overloading the network with frequent keepalives


      for N=
AT state maintenance purposes.  Note that this recommended=



      value=
 is close to the one recommended for MAX_TRANSMIT_WAIT, whose


      value=
 is derived from transmission parameters (Section 4.8.2 of


     
[RFC7252]).<=
/o:p>


 =



Thoughts?



 =



Cheers,


Med





_______________________________________________
Dots mailing list
Dots@ietf.or=
g
https://www.ietf.org/mailman/listinfo/dots

 




_______________________________________________
Dots mailing list
Dots@ie=
tf.org
https://www.ietf.org/mailman/listinfo/dots

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ie= tf.org/mailman/listinfo/dots


--_000_48E2524DFEA44765A3A80A2B01D906AEVerisigncom_-- From nobody Tue Oct 10 02:16:01 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EFA13452A for ; Tue, 10 Oct 2017 02:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwjAyaHgzzq3 for ; Tue, 10 Oct 2017 02:15:56 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 E29921342E7 for ; Tue, 10 Oct 2017 02:15:53 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e1qdh-00035L-KC; Tue, 10 Oct 2017 10:15:49 +0100 From: "Jon Shallow" To: "'kaname nishizuka'" , "Konda, Tirumaleswar Reddy" , , "'Flemming Andreasen'" , References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com> <4406f5bc-60ea-96dc-d74b-a74430b83285@nttv6.jp> In-Reply-To: <4406f5bc-60ea-96dc-d74b-a74430b83285@nttv6.jp> Date: Tue, 10 Oct 2017 10:15:51 +0100 Message-ID: <0cc001d341a8$5e8238a0$1b86a9e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CC1_01D341B0.C04911A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFSg1IOmvyw/QR4DyHE01ic1cgMDAGpyfFOAh5uDMMCbmyffAKcH5JuAib54W0ChaMRsqNySUPw Content-Language: en-gb Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 09:16:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0CC1_01D341B0.C04911A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I also agree - my experience since the 80's is a (firewall/NAT) UDP session timeout value default of 30 seconds - RFC4787 came out some 20 years later in 2007. The "heartbeat-interval" needs to be retained - with a minimum value of less than 30 seconds (perhaps 15 seconds) so that DOTS signal will work through (?broken?) firewalls/NAT devices that maintain some sort of state. Even if the heartbeat is every 30 seconds, this is a packet of less than 100 bytes every 30 seconds - this is not going to add to a DDoS situation. I think that text similar to the following also needs to be added "A heartbeat is not allowed to be transmitted while a previous heartbeat has not been responded to - which could be longer than the heartbeat interval if there is packet loss and could be up to MAX_TRANSMIT_WAIT (RFC7252) seconds. If MAX_TRANSMIT_WAIT is greater than the heartbeat interval and the previous heartbeat has had no response, then the next heartbeat should be sent as soon as possible. Otherwise heartbeats should be sent no more frequently than the heartbeat interval." Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 10 October 2017 04:32 To: Flemming Andreasen; Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval I agree with Flemming's suggestion. Practically, the timeout will be set to ~30 seconds by operators like us. regards, kaname On 2017/10/10 1:35, Flemming Andreasen wrote: On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote: From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen Sent: Monday, October 9, 2017 9:12 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds. I'm getting different data-points for at least the minimum value. There still seems to be a lot of NATs out there with a timeout value of ~30 seconds for UDP traffic (and in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what you would want. Google did a lot of testing around this and decided they were happy with the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds). Consent freshness has nothing to do with NAT/FW timeouts. You are missing the point Tiru - testing has been done (in the past and more recently) and a value of ~30 seconds seems to be what works for the majority of devices. I'll trust Google on this one. -- Flemming -Tiru Thanks -- Flemming Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agents can pick suitable values for max-retransmit parameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds). 2) No, if the DOTS agent wants to change the default heartbeat interval then the other message transmission parameters will also have to be modified. 3) The client will have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session, the client will have to initiate (D)TLS session resumption. The heartbeat expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was an off the cuff response, to handle the "broken" NAT timing implementations out there. The Heartbeat mechanism does raise a few questions in my mind which do need to be thought through. On a DOTS server, using a heartbeat interval of 15 secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4). Question 1 ========== Should the max-retransmit actually be 3, not 4 for CON requests so that we do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be in peace time) and heartbeats, not mitigation requests Question 2 ========= If the heartbeat interval is less than 91 seconds - say 60 seconds and the first heartbeat ping is still active, should a second heartbeat be fired off? - I think not, but the text then needs to get updated to state the interval is used whenever there is not a pending heartbeat response outstanding. Question 3 ========= Heartbeat checks are being initiated by the client. The client gets a heartbeat timeout on the session. The client subsequently needs to send a PUT mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 ========= Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 ========== When the heartbeats are initiated by the server, and the heartbeat times out, the session is "bad", but the current mitigation request continues until it expires. The client may have kicked off his heartbeats at a different time, and there likely will be a sending frequency drift over time, so the client may think the session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh the mitigation as it is about to expire or possibly another PUT for a different IP that has just started to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from the client's perspective) is an attack stopping traffic getting through and needs to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has heartbeat expired. The session contained all the negotiated PKI session keys etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace time. - I believe the session on the server needs to be kept hanging around for some time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer how to keep "bad" session hanging around] ========== Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the following: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the rationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots ------=_NextPart_000_0CC1_01D341B0.C04911A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also agree – my = experience since the 80’s is a (firewall/NAT) UDP session timeout = value default of 30 seconds – RFC4787 came out some 20 years later = in 2007.

 

The = “heartbeat-interval” needs to be retained – with a = minimum value of less than 30 seconds (perhaps 15 seconds) so that DOTS = signal will work through (?broken?) firewalls/NAT devices that maintain = some sort of state.  Even if the heartbeat is every 30 seconds, = this is a packet of less than 100 bytes every 30 seconds – this is = not going to add to a DDoS situation.

 

I think that text = similar to the following also needs to be added

 

“A heartbeat is = not allowed to be transmitted while a previous heartbeat has not been = responded to – which could be longer than the heartbeat interval = if there is packet loss and could be up to MAX_TRANSMIT_WAIT = (RFC7252) seconds.  If MAX_TRANSMIT_WAIT is greater than the = heartbeat interval and the previous heartbeat has had no response, then = the next heartbeat should be sent as soon as possible.  Otherwise = heartbeats should be sent no more frequently than the heartbeat = interval.”

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] = On Behalf Of kaname nishizuka
Sent: 10 October 2017 = 04:32
To: Flemming Andreasen; Konda, Tirumaleswar Reddy; Jon = Shallow; mohamed.boucadair@orange.com; dots@ietf.org
Subject: = Re: [Dots] Minimum = heartbeat-interval

 


I agree with Flemming's = suggestion.
Practically, the timeout will be set to ~30 seconds by = operators like us.

regards,
kaname

On 2017/10/10 1:35, Flemming Andreasen = wrote:

 

On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy = wrote:

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Flemming Andreasen
Sent: Monday, October = 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_= Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] Minimum heartbeat-interval

 

 

On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy = wrote:

http://c= onferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/= rfc7925 has tested NAT behavior with various routers and lists the = timeout results. The majority of the devices (62%) have a timeout = between 2 and 2.5 minutes and the minimum timeout value observed when = packets are exchanged b/w peers in both directions is 54 seconds. =

 <= /o:p>

I'm getting different data-points for at = least the minimum value. There still seems to be a lot of NATs out there = with a timeout value of ~30 seconds for UDP traffic (and in rare cases = even lower), which suggests that a timeout value slightly lower than 30 = seconds is what you would want. Google did a lot of testing around this = and decided they were happy with the values in https://tools.ietf.org/html/= rfc7675 (i.e. 30 seconds).

 <= /o:p>

Consent freshness = has nothing to do with NAT/FW timeouts. =

You are missing the point = Tiru - testing has been done (in the past and more recently) and a value = of ~30 seconds seems to be what works for the majority of devices. I'll = trust Google on this one.

-- Flemming =



 <= /o:p>

-Tiru



Thanks

-- Flemming =




Responses to the = questions below

 <= /o:p>

1) The = max-retransmit parameter is negotiable and configurable,  DOTS = agents can pick suitable values for max-retransmit parameter based on = the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the = MAX_TRANSMIT_WAIT to 45 seconds).

2) No, if the DOTS = agent wants to change the default heartbeat interval then the other = message transmission parameters will also have to be modified. =

3) The client will = have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#sec= tion-2.2.1) and initiate (D)TLS session resumption =

4) If heartbeat = expires then the DOTS server will close the (D)TLS session, the client = will have to initiate (D)TLS session resumption. The heartbeat expires = only after 273 seconds (3 “CoAP ping” confirmable messages, = each
“CoAP ping” re-transmitted 4 times). =

 <= /o:p>

Med – In the = below text, recommended value should be 93 seconds instead of 90 seconds = (see https://tools.= ietf.org/html/rfc7252#section-4.8.2).

 <= /o:p>

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Wednesday, October 4, = 2017 5:36 PM
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] Minimum heartbeat-interval

 

Hi Mohamed,

 

In principal I agree = with your suggested updates – the minimum of 10s was an off the = cuff response, to handle the “broken” NAT timing = implementations out there. 

 

The Heartbeat mechanism = does raise a few questions in my mind which do need to be thought = through.  On a DOTS server, using a heartbeat interval of 15 secs, = with the client going away circa 10:54:30, I get

 

Oct 04 10:53:51 DEBG sending CoAP = ping:

Oct 04 = 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to retransmit queue = (2281ms)

Oct 04 = 10:53:51 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message = 29548

Oct 04 = 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending CoAP = ping:

Oct 04 = 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to retransmit queue = (2938ms)

Oct 04 = 10:54:07 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message = 29549

Oct 04 = 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending CoAP = ping:

Oct 04 = 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to retransmit queue = (2156ms)

Oct 04 = 10:54:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message = 29550

Oct 04 = 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending CoAP = ping:

Oct 04 = 10:54:39 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to retransmit queue = (2813ms)

Oct 04 = 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) = DTLS tid=3D29551: retransmission #1

Oct 04 10:54:42 DEBG *  192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission = #2

Oct 04 = 10:54:48 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission = #3

Oct 04 = 10:55:00 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission = #4

Oct 04 = 10:55:23 DEBG *  192.168.0.189:5684 <-> 192.168.0.1:54477 = (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> = 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up after 4 = attempts

 

Here we see the 91 = seconds (dependant on the max-retransmit value being 4) 10:56:09 – = 10:54:39.  There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 = before retry transmission #4).

 

Question = 1

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

Should the = max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON is only used for signal configuration = (infrequent, likely only to be in peace time) and heartbeats, not = mitigation requests

 

Question = 2

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

If the heartbeat = interval is less than 91 seconds – say 60 seconds and the first = heartbeat ping is still active, should a second heartbeat be fired = off?

- I think not, but the text then needs to get = updated to state the interval is used whenever there is not a pending = heartbeat response outstanding.

 

Question = 3

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

 

Heartbeat checks are = being initiated by the client.  The client gets a heartbeat timeout = on the session.  The client subsequently needs to send a PUT = mitigate request.

 

Does the client set up a = new session?

- Difficult as we are unlikely to be in peace = time

- PKI exchanges are likely to = fail

- the client just needs to send a = non-confirmable PUT.

 

Question = 4

=3D=3D=3D=3D=3D=3D=3D=3D=3D

=

 

Scenario as = Q3

 

Does the client re-use = the old session that the heartbeats are failing = on?

- The server may have sent a session close, but = it never got through

 

Question = 4

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

When the heartbeats are = initiated by the server, and the heartbeat times out, the session is = “bad”, but the current mitigation request continues until it = expires.

The client may have kicked off his heartbeats at = a different time, and there likely will be a sending frequency drift = over time, so the client may think the session is still active, the = server not, and the client decides it is time to send a non-confirmable = PUT to refresh the mitigation as it is about to expire or possibly = another PUT for a different IP that has just started to get hammered = – hence heartbeat failures. 

Alternatively the client = decides that the reason for “bad” session (from the = client’s perspective) is an attack stopping traffic getting = through and needs to do a PUT on the existing = session.

 

So server receives a PUT = (refresh or for a new IP) on a session that has heartbeat expired.  = The session contained all the negotiated PKI session keys etc.  = What should happen here?

- as the heartbeats are failing, it is safe to = assume we are not in peace time.

- I believe the session = on the server needs to be kept hanging around for some time post = heartbeat time-out. For how long?

- the server may be = seeing the client heartbeat messages [this may answer how to keep = “bad” session hanging around]

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots= -bounces@ietf.org] On Behalf Of ietf-supjps-moha= med.boucadair@orange.com
Sent: 04 October 2017 = 09:35
To: dots@ietf.org; = Jon Shallow (supjps-ietf@jpshallow.com)<= br>Subject: [Dots] Minimum = heartbeat-interval

 

Dear all,

 

Jon = made the following comment during the interim meeting: = “A: (Jon Shallow): The = minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with = RFC8085 which says the following:

 

   An =
application that needs to employ keep-alive messages to =
deliver
   useful service over UDP in the =
presence of middleboxes SHOULD =
NOT
        =
            &=
nbsp;           &n=
bsp;           &nb=
sp; ^^^^^^^^^^^^^^^^^^^^^^
   transmit =
them more frequently than once every 15 seconds and =
SHOULD
 =
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^
   use longer intervals when =
possible. 

 

I = suggest to add this NEW text to the signal-channel draft to clarify the = rationale for the recommended values:

 

NEW:

      Note: heartbeat-interval = should be tweaked to also assist DOTS

      messages for NAT = traversal (SIG-010 of

      = [I-D.ietf-dots-requirements]).  According to [RFC8085], = keepalive

      messages must not be = sent more frequently than once every 15

      seconds and should use = longer intervals when possible.

      Furthermore, [RFC4787] = recommends NATs to use a state timeout of 2

      minutes or longer.  = >From that standpoint, this specification

      recommends a minimum = heartbeat-interval of 15 seconds and a

      maximum = heartbeat-interval of 240 seconds.  The recommended = value

      of 90 seconds is = selected to anticipate the expiry of NAT states,

      while avoiding = overloading the network with frequent keepalives

      for NAT state = maintenance purposes.  Note that this = recommended

      value is close to the = one recommended for MAX_TRANSMIT_WAIT, whose

      value is derived from = transmission parameters (Section 4.8.2 of

      [RFC7252]).

 

Thoughts?

 

Cheers,

Med





___=
____________________________________________
Dots =
mailing list
Dots@ietf.org
https://www.ietf.org/=
mailman/listinfo/dots

 





_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/=
mailman/listinfo/dots

 

------=_NextPart_000_0CC1_01D341B0.C04911A0-- From nobody Tue Oct 10 02:23:21 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D1B134B59 for ; Tue, 10 Oct 2017 02:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3lVxuYqg3Y5 for ; Tue, 10 Oct 2017 02:23:19 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 AF9E0134B51 for ; Tue, 10 Oct 2017 02:23:18 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e1qkt-00035m-Ni; Tue, 10 Oct 2017 10:23:15 +0100 From: "Jon Shallow" To: "'kaname nishizuka'" , "Konda, Tirumaleswar Reddy" , , , "Roland Dobbins" References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> In-Reply-To: <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> Date: Tue, 10 Oct 2017 10:23:17 +0100 Message-ID: <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CD7_01D341B1.CA2F9850" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIAJQ6kjUASRe9X8Bri7ZGgMYlBpaAoe6cxOigZ6XoA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 09:23:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0CD7_01D341B1.CA2F9850 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kaname, =20 I do not think that information necessarily needs to be the original = client identity. The GW Client side will have its own identity which = the DOTS Server can use to differentiate between DOTS (GW) Clients. =20 So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash collisions. Or = it could be a simple list such as C1, C2 =E2=80=A6Cn. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 10 October 2017 04:19 To: Konda, Tirumaleswar Reddy; Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi, > I agree the below problems are applicable for server-side DOTS = gateway, it must convey the =E2=80=9Cclient identity=E2=80=9D to the = DOTS server.=20 I agree with this server-side DOTS gateway case. At the same time, I agree with below: > I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW,=20 Then, should DOTS GW send =E2=80=9Cclient identity=E2=80=9D (i.e. = certificates of DOTS clients) itself or hashed(=E2=80=9Cclient = identity=E2=80=9D) to DOTS server? If later, how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient identity=E2=80=9D). regards, Kaname On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote: Hi Jon, =20 I agree the below problems are applicable for server-side DOTS gateway, = it must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. = But for the client-side DOTS gateway, it should resolve conflicting = rules b/w DOTS clients (e.g. one client installing black-list ACL for an = IP address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:07 PM To: Konda, Tirumaleswar Reddy = = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds = in =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0CD7_01D341B1.CA2F9850 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Kaname,

 

I do not think that information necessarily needs to be the original = client identity.=C2=A0 The GW Client side will have its own identity = which the DOTS Server can use to differentiate between DOTS (GW) = Clients.

 

So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash = collisions.=C2=A0 Or it could be a simple list such as C1, C2 = =E2=80=A6Cn.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname = nishizuka
Sent: 10 October 2017 04:19
To: Konda, = Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS = Gateways Challenges

 

Hi,

> I agree the below = problems are applicable for server-side DOTS gateway, it must convey the = =E2=80=9Cclient identity=E2=80=9D to the DOTS server.
I agree with = this server-side DOTS gateway case.
At the same time, I agree with = below:
> I agree that is not a good thing to = =E2=80=9Cleak=E2=80=9D out internal information when passing through a = DOTS GW,

Then, should DOTS GW send =E2=80=9Cclient = identity=E2=80=9D (i.e. certificates of DOTS clients) itself or = hashed(=E2=80=9Cclient identity=E2=80=9D) to DOTS server?
If later, = how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient = identity=E2=80=9D).

regards,
Kaname


<= div>

On 2017/10/09 22:34, Konda, Tirumaleswar Reddy = wrote:

Hi = Jon,

 

I agree = the below problems are applicable for server-side DOTS gateway, it must = convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. But for = the client-side DOTS gateway, it should resolve conflicting rules b/w = DOTS clients (e.g. one client installing black-list ACL for an IP = address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, October 7, 2017 2:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_= Konda@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
S= ubject: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client.  =

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)     &nb= sp; The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)      = The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)     &nb= sp; The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely  associated with Client = Identity derived from the DOTS GW Client = certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).  This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.  The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.  Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= = Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:28
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, October 6, 2017 7:42 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= = Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 06 October 2017 14:58
To: = mohamed.boucadair@orange.com= ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: = [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 

-Tiru




_______________________=
________________________
Dots mailing =
list
Dots@ietf.org
https://www.ietf.org/=
mailman/listinfo/dots

 

------=_NextPart_000_0CD7_01D341B1.CA2F9850-- From nobody Tue Oct 10 02:43:19 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D5D134BD9 for ; Tue, 10 Oct 2017 02:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTspbycEpDLt for ; Tue, 10 Oct 2017 02:43:15 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1095134BF0 for ; Tue, 10 Oct 2017 02:43:03 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4BC89C05D5; Tue, 10 Oct 2017 11:43:02 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 25B0860062; Tue, 10 Oct 2017 11:43:02 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0361.001; Tue, 10 Oct 2017 11:43:01 +0200 From: To: Jon Shallow , 'kaname nishizuka' , "Konda, Tirumaleswar Reddy" , 'Flemming Andreasen' , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AQHTQawpxic0CJiAHE2G7/fmYix2ZQ== Date: Tue, 10 Oct 2017 09:43:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A051A13@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com> <4406f5bc-60ea-96dc-d74b-a74430b83285@nttv6.jp> <0cc001d341a8$5e8238a0$1b86a9e0$@jpshallow.com> In-Reply-To: <0cc001d341a8$5e8238a0$1b86a9e0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A051A13OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 09:43:18 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A051A13OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Here is an updated text to echo the voices heard so far. Please double chec= k it: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 30 seconds is selected to be aligned with common practices for services suffering from similar issues (e.g., [RFc7675]). A heartbeat-interval of 30s may be seen as too chatty in some deploym= ents. For such deployments, DOTS agents may negotiate longer heartbeat-inte= rval values to avoid overloading the network with too frequent keepalives. Of course, the text proposed by Jon will also be integrated in the next ite= ration of the draft (that point was already agreed). Thank you. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 10 octobre 2017 11:16 =C0 : 'kaname nishizuka'; Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed IMT/= OLN; 'Flemming Andreasen'; dots@ietf.org Objet : RE: [Dots] Minimum heartbeat-interval I also agree - my experience since the 80's is a (firewall/NAT) UDP session= timeout value default of 30 seconds - RFC4787 came out some 20 years later= in 2007. The "heartbeat-interval" needs to be retained - with a minimum value of les= s than 30 seconds (perhaps 15 seconds) so that DOTS signal will work throug= h (?broken?) firewalls/NAT devices that maintain some sort of state. Even = if the heartbeat is every 30 seconds, this is a packet of less than 100 byt= es every 30 seconds - this is not going to add to a DDoS situation. I think that text similar to the following also needs to be added "A heartbeat is not allowed to be transmitted while a previous heartbeat ha= s not been responded to - which could be longer than the heartbeat interval= if there is packet loss and could be up to MAX_TRANSMIT_WAIT (RFC7252) sec= onds. If MAX_TRANSMIT_WAIT is greater than the heartbeat interval and the = previous heartbeat has had no response, then the next heartbeat should be s= ent as soon as possible. Otherwise heartbeats should be sent no more frequ= ently than the heartbeat interval." Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of kaname nishizuka Sent: 10 October 2017 04:32 To: Flemming Andreasen; Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.bou= cadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval I agree with Flemming's suggestion. Practically, the timeout will be set to ~30 seconds by operators like us. regards, kaname On 2017/10/10 1:35, Flemming Andreasen wrote: On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote: From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen Sent: Monday, October 9, 2017 9:12 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow = ; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. I'm getting different data-points for at least the minimum value. There sti= ll seems to be a lot of NATs out there with a timeout value of ~30 seconds = for UDP traffic (and in rare cases even lower), which suggests that a timeo= ut value slightly lower than 30 seconds is what you would want. Google did = a lot of testing around this and decided they were happy with the values in= https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds). Consent freshness has nothing to do with NAT/FW timeouts. You are missing the point Tiru - testing has been done (in the past and mor= e recently) and a value of ~30 seconds seems to be what works for the major= ity of devices. I'll trust Google on this one. -- Flemming -Tiru Thanks -- Flemming Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). 2) No, if the DOTS agent wants to change the default heartbeat interval the= n the other message transmission parameters will also have to be modified. 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_787AE7BB302AE849A7480A190F8B93300A051A13OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Here is an up= dated text to echo the voices heard so far. Please double check it:

 

NEW:

      Note: heartbeat-interval should be t= weaked to also assist DOTS

      messages for NAT traversal (SIG-010 = of

      [I-D.ietf-dots-requirements]). = According to [RFC8085], keepalive

      messages must not be sent more frequ= ently than once every 15

      seconds and should use longer interv= als when possible.

      Furthermore, [RFC4787] recommends NA= Ts to use a state timeout of 2

      minutes or longer.  From that s= tandpoint, this specification

      recommends a minimum heartbeat-inter= val of 15 seconds and a

      maximum heartbeat-interval of 240 se= conds.  The recommended value

      of 30 seconds is selected to be alig= ned with common practices for

      services suffering from similar= issues (e.g., [RFc7675]).

      A heartbeat-interval of 30s may= be seen as too chatty in some deployments.

      For such deployments, DOTS agen= ts may negotiate longer heartbeat-interval

      values to avoid overloading the= network with too frequent keepalives.

 

Of course, the text proposed by Jon will also be integrated in the = next iteration of the draft (that point was already agreed).

 

Thank you.

 

Cheers,

Med        

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 10 octobre 2017 11:16
=C0 : 'kaname nishizuka'; Konda, Tirumaleswar Reddy; BOUCADAIR = Mohamed IMT/OLN; 'Flemming Andreasen'; dots@ietf.org
Objet : RE: [Dots] Minimum heartbeat-interval=

 

I also = agree – my experience since the 80’s is a (firewall/NAT) UDP se= ssion timeout value default of 30 seconds – RFC4787 came out some 20 = years later in 2007.

&n= bsp;

The = 220;heartbeat-interval” needs to be retained – with a minimum v= alue of less than 30 seconds (perhaps 15 seconds) so that DOTS signal will = work through (?broken?) firewalls/NAT devices that maintain some sort of state.  Even if the heartbeat is every 30 seconds, this = is a packet of less than 100 bytes every 30 seconds – this is not goi= ng to add to a DDoS situation.

&n= bsp;

I think= that text similar to the following also needs to be added

&n= bsp;

“= A heartbeat is not allowed to be transmitted while a previous heartbeat has= not been responded to – which could be longer than the heartbeat int= erval if there is packet loss and could be up to MAX_TRANSMIT_WAIT (RFC7252) seconds.  If MAX_TRANSMIT_WAIT is g= reater than the heartbeat interval and the previous heartbeat has had no re= sponse, then the next heartbeat should be sent as soon as possible.  Otherwise heartbeats should be sent no mor= e frequently than the heartbeat interval.”

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.o= rg] On Behalf Of kaname nishizuka
Sent: 10 October 2017 04:32
To: Flemming Andreasen; Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com; dots@iet= f.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

=
I agree with Flemming's suggestion.
Practically, the timeout will be set to ~30 seconds by operators like us.
regards,
kaname

On 2017/10/10 1:35, Flemming An= dreasen wrote:

=  

On 10/9/17 11:55 AM, Konda, Tir= umaleswar Reddy wrote:

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

 

On 10/5/17 6:54 AM, Konda, Tiru= maleswar Reddy wrote:

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf= referenced by https://tools.ietf.org/html= /rfc7925 has tested NAT behavior with various routers and lists the tim= eout results. The majority of the devices (62%) have a timeout between 2 an= d 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is = 54 seconds.

 =

I'm = getting different data-points for at least the minimum value. There still s= eems to be a lot of NATs out there with a timeout value of ~30 seconds for = UDP traffic (and in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what= you would want. Google did a lot of testing around this and decided they w= ere happy with the values in https://tools.ietf.org/html= /rfc7675 (i.e. 30 seconds).

 =

Consent freshness has nothing to do with NAT/FW time= outs.

You are missing the point Tiru - testi= ng has been done (in the past and more recently) and a value of ~30 seconds seems to be what works for the majority of devices. I'll tr= ust Google on this one.

-- Flemming


 =

-Tiru<= /p>



Thanks

-- Flemming



Responses to the questions below

 =

1) The max-retransmit parameter is negotiable and co= nfigurable,  DOTS agents can pick suitable values for max-retransmit p= arameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).=

2) No, if the DOTS agent wants to change the default= heartbeat interval then the other message transmission parameters will als= o have to be modified.

3) The client will have to assume the session is dis= connected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will cl= ose the (D)TLS session, the client will have to initiate (D)TLS session res= umption. The heartbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 =

Med – In the below text, recommended value sho= uld be 93 seconds instead of 90 seconds (see https://tools= .ietf.org/html/rfc7252#section-4.8.2).

 =

-Tiru<= /p>

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

 <= /span>

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

 <= /span>

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

 <= /span>

Oct 04 10:53:51 DEBG sendi= ng CoAP ping:

Oct 04 10:53:51 DEBG *&nbs= p; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:53:51 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added t= o retransmit queue (2281ms)

Oct 04 10:53:51 DEBG *&nbs= p; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 b= ytes

Oct 04 10:53:51 ALRT got R= ST for message 29548

Oct 04 10:53:51 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: remove= d

Oct 04 10:54:07 DEBG sendi= ng CoAP ping:

Oct 04 10:54:07 DEBG *&nbs= p; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:07 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added t= o retransmit queue (2938ms)

Oct 04 10:54:07 DEBG *&nbs= p; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 b= ytes

Oct 04 10:54:07 ALRT got R= ST for message 29549

Oct 04 10:54:07 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: remove= d

Oct 04 10:54:23 DEBG sendi= ng CoAP ping:

Oct 04 10:54:23 DEBG *&nbs= p; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:23 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added t= o retransmit queue (2156ms)

Oct 04 10:54:23 DEBG *&nbs= p; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 b= ytes

Oct 04 10:54:23 ALRT got R= ST for message 29550

Oct 04 10:54:23 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: remove= d

Oct 04 10:54:39 DEBG sendi= ng CoAP ping:

Oct 04 10:54:39 DEBG *&nbs= p; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:39 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added t= o retransmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retran= smission #1

Oct 04 10:54:42 DEBG *&nbs= p; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:48 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retran= smission #2

Oct 04 10:54:48 DEBG *&nbs= p; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:55:00 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retran= smission #3

Oct 04 10:55:00 DEBG *&nbs= p; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:55:23 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retran= smission #4

Oct 04 10:55:23 DEBG *&nbs= p; 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:56:09 DEBG ** 19= 2.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give u= p after 4 attempts

 <= /span>

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

 <= /span>

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests=

 <= /span>

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

 <= /span>

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

 <= /span>

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.=

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Scenari= o as Q3

 <= /span>

Does th= e client re-use the old session that the heartbeats are failing on?<= span lang=3D"EN-GB">

- The s= erver may have sent a session close, but it never got through

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

 <= /span>

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

 <= /span>

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

Regards=

 <= /span>

Jon

 <= /span>

From:= Dots [mailto:ietf-sup= jps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow = (supjps-ietf@jpshallow.com= )
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the follo= wing comment during the interim meeting: “A: (Jon Shallow): The minimum for the heartbeat should be 10s”

 

Actually, the use = of 10s is not aligned with RFC8085 which says the following:

 

   An app=
lication that needs to employ keep-alive messages to deliver
   useful=
 service over UDP in the presence of middleboxes SHOULD NOT
   &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     ^^^^^^^^^^^^^^^^^^^^^^
   transm=
it them more frequently than once every 15 seconds and SHOULD
   ^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   use lo=
nger intervals when possible. 

 

I suggest to add t= his NEW text to the signal-channel draft to clarify the rationale for the r= ecommended values:

 

NEW:

      Note: heartbeat-interval shou= ld be tweaked to also assist DOTS

      messages for NAT traversal (S= IG-010 of

      [I-D.ietf-dots-requirements])= .  According to [RFC8085], keepalive<= /o:p>

      messages must not be sent mor= e frequently than once every 15

      seconds and should use longer= intervals when possible.

      Furthermore, [RFC4787] recomm= ends NATs to use a state timeout of 2

      minutes or longer.  From= that standpoint, this specification=

      recommends a minimum heartbea= t-interval of 15 seconds and a

      maximum heartbeat-interval of= 240 seconds.  The recommended value<= /o:p>

      of 90 seconds is selected to = anticipate the expiry of NAT states,=

      while avoiding overloading th= e network with frequent keepalives

      for NAT state maintenance pur= poses.  Note that this recommended

      value is close to the one rec= ommended for MAX_TRANSMIT_WAIT, whose

      value is derived from transmi= ssion parameters (Section 4.8.2 of

  &nb= sp;   [RFC7252]).

 

Thoughts?

 

Cheers,

Med




___________________=
____________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/d=
ots

&nbs= p;




___________________=
____________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/d=
ots

 

--_000_787AE7BB302AE849A7480A190F8B93300A051A13OPEXCLILMA3corp_-- From nobody Tue Oct 10 02:43:43 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A68134BE2 for ; Tue, 10 Oct 2017 02:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pgwz2eqeD9II for ; Tue, 10 Oct 2017 02:43:20 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 E55C0134BEB for ; Tue, 10 Oct 2017 02:43:05 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e1r44-00036R-8F; Tue, 10 Oct 2017 10:43:04 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , , "Roland Dobbins" References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net>, <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <0be801d3410c$69ca1260$3d5e3720$@jpshallow.com> In-Reply-To: Date: Tue, 10 Oct 2017 10:43:06 +0100 Message-ID: <0cec01d341ac$2cd05ef0$86711cd0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CED_01D341B4.8E9710E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIAJQ6kjUASRe9X8Bri7ZGgMYlBpaAoZI+RkCa4Rp2KJuUMbg Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 09:43:24 -0000 X-List-Received-Date: Tue, 10 Oct 2017 09:43:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0CED_01D341B4.8E9710E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 See inline to your 2 responses. =20 Regards Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 09 October 2017 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi Jon, =20 Please see inline=20 =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Monday, October 9, 2017 8:09 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 I think part of the challenge here in our thinking is that a mitigation = request does not (cannot) ask for a specific ACL/Filter (or set of ACLS) = to be installed =E2=80=93 in a similar vein to the mitigation request = being able to call up a specific alias-name to be used. [You refer to =E2=80=9Cbut the other client installs white-list ACL for = the same IP address, same alias-names for different mitigation = scopes)=E2=80=9D below =E2=80=93 however alias-names do not currently = dictate which ACL to use as per module: = ietf-dots-data-channel-identifier.] =20 The current design appears to me is that the ACL/filter list is defined = on the DOTS Server (by a DOTS client or directly on the DOTS Server) and = you then get all the defined ACLs instantiated by DOTS Mitigator = =E2=80=93 for a single mitigation request. =20 =20 [TR] No, black-list and white-list rules created using the DOTS data = channel have no dependency on conveying the mitigation request in the = DOTS signal channel (You may want to look into the DOTS requirements and = architecture drafts).=20 [Jon] I have re-read the requirements / architecture drafts. I agree = that currently the White/Black/Filter definitions have no dependency on = the mitigation request =E2=80=93 it is up to the DOTS server (GW or not) = as to how the White/Black/Filter definitions get passed on to DOTS = mitigator (out of spec), but the DOTS server needs to know which of the = White/Black/Filter definitions are relevant when a mitigation request = comes in. Currently, it is possible for the DOTS Server to hold = White/Black/Filter definitions on a per client identity. When the = White/Black/Filter definitions are passed from a GW Client side to a GW = server side and on to the next DOTS server, GW server side has to convey = also something about the clients on the GW client side for the DOTS = server to maintain the White/Black/Filter definitions on a per pseudo = =E2=80=9Cclient identity=E2=80=9D =E2=80=93 so when the migration = request is passed to the DOS server via a GW it knows what = White/Black/Filter definitions to apply to that mitigation request. =20 Even if the Filters are held on a per client identity basis, there no = way to upload a set of different filters in peace time ready for = selection as to which is be used in case of DDoS Attack. White/Black = lists are probably fairly static, it is the customizable filters that = are the issue currently for me.=20 =20 [TR] This is a new requirement and needs to be discussed.=20 [Jon] Agreed. We need to be able to support the flexibility of being = able to have different sets ACLs, one or more of which can be triggered = by a mitigation request. =20 -Tiru =20 If there was an additional parameter in the mitigation request =E2=80=93 = e.g. =E2=80=9Cfilter-name: []=E2=80=9D to define which ACLs are to be = used, this would simplify a lot of things and give a greater degree of = flexibility should it be needed. =20 Once =E2=80=9Cfilter-name: []=E2=80=9D is in place, then conflicting = requests are much easier to resolve =E2=80=93 especially if the 2 = clients defining the filter have different client identifiers [I am = making a naive assumption that Client-1 and Client 2 are responsible for = a different set of IP addresses that the DOTS Server or GW client facing = side know about =E2=80=93 so white list filter for these set of IP and = black-list filter for those set of IPs]. If the 2 clients have the same =E2=80=9Cclient identifier=E2=80=9D, both = request mitigation with the same filter name, then a conflict needs to = be resolved. However, the last client to define/update the filter will = win I guess. =20 If the GW Server facing side passes on =E2=80=9Cfilter-name=E2=80=9D and = something like =E2=80=9Cextra-info: {string}=E2=80=9D (related to = Client-1 and Client-2), then the upstream DOTS server with the GW as its = client will also be able to simply sort out what to do. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 09 October 2017 14:35 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi Jon, =20 I agree the below problems are applicable for server-side DOTS gateway, = it must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. = But for the client-side DOTS gateway, it should resolve conflicting = rules b/w DOTS clients (e.g. one client installing black-list ACL for an = IP address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:07 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds = in =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru ------=_NextPart_000_0CED_01D341B4.8E9710E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline to your 2 responses.

 

Regards


Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 09 October 2017 16:19
To: Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi = Jon,

 =

Please see = inline

 =

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Monday, October 9, 2017 8:09 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

I think part of the challenge here in our thinking is that a = mitigation request does not (cannot) ask for a specific ACL/Filter (or = set of ACLS) to be installed =E2=80=93 in a similar vein to the = mitigation request being able to call up a specific alias-name to be = used.

[You refer to =E2=80=9Cbut the = other client installs white-list ACL for the same IP address, same = alias-names for different mitigation scopes)=E2=80=9D below =E2=80=93 = however alias-names do not currently dictate which ACL to use as per = module: ietf-dots-data-channel-identifier.]

 

The current design appears to me is that the ACL/filter list is = defined on the DOTS Server (by a DOTS client or directly on the DOTS = Server) and you then get all the defined ACLs instantiated by DOTS = Mitigator =E2=80=93 for a single mitigation request.  =

 =

[TR] No, = black-list and white-list rules created using the DOTS data channel have = no dependency on conveying the mitigation request in the DOTS signal = channel (You may want to look into the DOTS requirements and = architecture drafts).

[Jon] I have re-read the requirements / architecture drafts.=C2=A0 I = agree that currently the White/Black/Filter definitions have no = dependency on the mitigation request =E2=80=93 it is up to the DOTS = server (GW or not) as to how the White/Black/Filter definitions get = passed on to DOTS mitigator (out of spec), but the DOTS server needs to = know which of the White/Black/Filter definitions are relevant when a = mitigation request comes in.=C2=A0 Currently, it is possible for the = DOTS Server to hold White/Black/Filter definitions on a per client = identity.=C2=A0 When the White/Black/Filter definitions are passed from = a GW Client side to a GW server side and on to the next DOTS server, GW = server side has to convey also something about the clients on the GW = client side for the DOTS server to maintain the White/Black/Filter = definitions on a per pseudo =E2=80=9Cclient identity=E2=80=9D =E2=80=93 = so when the migration request is passed to the DOS server via a GW it = knows what White/Black/Filter definitions to apply to that mitigation = request.

 =

Even if the Filters are held on a per client identity basis, there no way to upload a set of different filters in peace = time ready for selection as to which is be used in case of DDoS = Attack.  White/Black lists are probably fairly static, it is the = customizable filters that are the issue currently for me. =

 =

[TR] This = is a new requirement and needs to be discussed.

[Jon] Agreed.=C2=A0 We need to be able to support the flexibility of = being able to have different sets ACLs, one or more of which can be = triggered by a mitigation request.

 =

-Tiru<= /o:p>

 

If there was an additional parameter in the mitigation request = =E2=80=93 e.g. =E2=80=9Cfilter-name: []=E2=80=9D to define which ACLs = are to be used, this would simplify a lot of things and give a greater = degree of flexibility should it be needed.

 

Once  =E2=80=9Cfilter-name: []=E2=80=9D is in place, then = conflicting requests are much easier to resolve =E2=80=93 especially if = the 2 clients defining the filter have different client identifiers [I = am making a naive assumption that Client-1 and Client 2 are responsible = for a different set of IP addresses that the DOTS Server or GW client = facing side know about =E2=80=93 so white list filter for these set of = IP and black-list filter for those set of IPs].

If the 2 clients have the same =E2=80=9Cclient identifier=E2=80=9D, = both request mitigation with the same filter name, then a conflict needs = to be resolved.  However, the last client to define/update the = filter will win I guess.

 

If the GW Server facing side passes on =E2=80=9Cfilter-name=E2=80=9D = and something like =E2=80=9Cextra-info: {string}=E2=80=9D (related to = Client-1 and Client-2), then the upstream DOTS server with the GW as its = client will also be able to simply sort out what to = do.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 09 October 2017 = 14:35
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi = Jon,

 =

I agree = the below problems are applicable for server-side DOTS gateway, it must = convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. But for = the client-side DOTS gateway, it should resolve conflicting rules b/w = DOTS clients (e.g. one client installing black-list ACL for an IP = address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server.

 =

-Tiru<= /o:p>

 =

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, October 7, 2017 2:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client.  =

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)     &nb= sp; The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)      = The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)     &nb= sp; The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely  associated with Client = Identity derived from the DOTS GW Client = certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).  This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.  The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.  Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:28
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 =

-Tiru<= /o:p>

 =

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, October 6, 2017 7:42 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= Konda, = Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 06 October 2017 14:58
To: = mohamed.boucadair@orange.com= ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: = [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 =

-Tiru

------=_NextPart_000_0CED_01D341B4.8E9710E0-- From nobody Tue Oct 10 03:39:48 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA62134457 for ; Tue, 10 Oct 2017 03:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=verisign.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 n3aOlrauok27 for ; Tue, 10 Oct 2017 03:39:43 -0700 (PDT) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617A1134322 for ; Tue, 10 Oct 2017 03:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=49021; q=dns/txt; s=VRSN; t=1507631983; h=from:to:subject:date:message-id:mime-version; bh=MV1nJU3zyBpNhmkFdYYeEoy8ZRgYkhb4A0104p2bxIM=; b=it0TybcwfHAW1mWBXY6n1Llg3ReoET2mNU0B8ESe2aZ/4bOsOg9V7OZm P/nbxxVFXGZ1vL22vjMYpx/SX3XfM6Yu0hG2Nfd6zrM8ndrdl9UGc5SVF CJLgkNAsMe+A9sT0aMayeYaInchuzKo4SccZUsOB/3UIqd1BFwNq7h3Et Uo6FbZmzCCd2RCcqnvXGlgQYUZ3K33mTJ2rYTzck+CMWWkE4rWIU2s4Wy 8KNUUpUcNp7hCHbYQgTDVWUjzjn8GY9j/uNFAT6ewFlKoACLkojS7nSEg I0DsUnNFGInh/n97KoqEucMKfkCvksxrJyyHBPV+Yu0TRL1wScwgBFvE0 A==; X-IronPort-AV: E=Sophos;i="5.42,504,1500940800"; d="scan'208,217";a="2726048" IronPort-PHdr: =?us-ascii?q?9a23=3AoyNtPxwvCNMTWefXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?0u4WLvad9pjvdHbS+e9qxAeQG96Ku7Qc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q89pDXYAhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXWpPUNhMWSxdDI2y?= =?us-ascii?q?bIUAD+sdMulXtITyvUcCrR6kCAWwHu7iyDlFjWL2060g1OQhFBnL0AI+Ed0Qqn?= =?us-ascii?q?vUo8j1O7kKXeuo1KfIzDbDY/1L0jr67ojIbg4uruuDXbJtb8Xc0lcvGB3fjlWR?= =?us-ascii?q?sozlPjyV1uIXv2eH6OpgUPuihmg6oA9/pTivw90jiojPho8Ny1DL6zl5wIgvKd?= =?us-ascii?q?2/Uk57btipG4ZTuSGCL4Z6X98uT3t1tCs4xLAKo4O3cSgExZg92RLSZPOKf5CV?= =?us-ascii?q?7h7/TuqdPDV1iG5/dL6iiBu/8lKsxvD/W8SyzV1EtDBKksPWuXAIzxHT78+HRe?= =?us-ascii?q?Zj8Uq5wjaP0hzT6vlDIUApiarXM54hzaA0lpoUqUnMBTX2mEPrgK+SeUQk//Kn?= =?us-ascii?q?6+XjYrXhu5+cK5N4hhzkPqQwhMO/G+U4MhMPX2iU/+SwzqHs/Ur8QLlSj/02lL?= =?us-ascii?q?fWsIzCKMgGuqK1GRJZ34Qt5hqlEjur0NoVkWMZIF9Kdx+Ll43pNEvPIPD8A/e/?= =?us-ascii?q?mVOskDJzyvDAIr3uHI/CLnfekLj/Zrt99VBTyBAyzdBE5pJUBbcBLOjvVU/2sd?= =?us-ascii?q?zUFgU5PBCsw+b7FNV90ZsTWXiSDa+eK6zdql6I5uQ0I+SXfoAVoi3yK/8/5/L0?= =?us-ascii?q?i382h0Mdd7Gz3ZQLcHC4AuhmI0KBbHXxhdcBDXwKsxE/TOP0lF2CXyRfZ3GoX6?= =?us-ascii?q?Iz/js7Ep6pDZ/fRoCxh7yMxCK7HppWZm9cD1CDD2rne5+fVPcLdSKdPtVunSEe?= =?us-ascii?q?WrigUY8szhautBXgxLphIerb5DcUuo7k1Nhw/+fTjw099SRoD8SB1GGAV396nm?= =?us-ascii?q?ISRz8r2aBwu0h9xUmY0al2mfNYD8Bd6O1UXQgnNZ/T1+l0C9f0Wg3cZNiEU1Om?= =?us-ascii?q?Tcm8DjE/UN0+3cUCbFp6G9WnlhrDxTalA6cJl7yXA5w56qHc0GL3J8lnznbJyr?= =?us-ascii?q?Isj186QstTK22rh7Rz9wrLB4TRiUWWi76qdbgA3C7K7GqD1neOvFlaUA5oSqXJ?= =?us-ascii?q?RHEfaVXKrdT3/U7CTaeuCa8nMgRbzc6CLqxKa9PzgVpaQ/fjPYeWX2XkuWC2TS?= =?us-ascii?q?2Iz7eIa5WiL34AxCfFEw0Fnhwd1XSeLgg3AiOmvCTVCzk4URqlLEDl9+B7pTu9?= =?us-ascii?q?T1Q0zhOXbEQunfLh+RcTjPmRY/UPwqxa/iU5/XE8VnW62d7fT5K8phB8eaxYbM?= =?us-ascii?q?gi6U0P72/Vux03dsicLrp/g1cafh9otlnU2hl7G7Jjls4mpVsvxwN8JK/e21RE?= =?us-ascii?q?IXfQl5X3OrTSJ2W09heyYKfa01DE+NGM86EA5bIzrFCp9FWsEUor9nhrldNSzn?= =?us-ascii?q?CV6pzLFiIVS5v3XUtx/B9/8fWSKCU6+5j81HBwP++zqDCIk4YlA/c+4hetY9kZ?= =?us-ascii?q?N7mLQku6WfcdA8GoJKQGnFKjbxQfdqgG7qIzNcmnceCu0bShO/wmmj+62zdp+o?= =?us-ascii?q?d4hwiw+iNzV+OMl7AEwLvQig2bWj7zkVqJrM3tmJtFajdUFW26n3u3TLVNb7F/?= =?us-ascii?q?KN5YQVylJNe6k5An38bg?= X-IPAS-Result: =?us-ascii?q?A2EkAQAaotxZ//SZrQpSCRkBAQEBAQEBAQEBAQcBAQEBARQ?= =?us-ascii?q?BAQEBAQEBAQEBAQcBAQEBAYJEgVCBFQeDc5wJmD4DChgBCoUYAhqEchQBAQEBA?= =?us-ascii?q?QEBAQEBAQKBEII4JAENRiwBAQEBAQFPAj4sAQECAgEBASFLEA0BCA0BAwEDAQE?= =?us-ascii?q?hAQYDAgQlCxQDBgoEARKJQFwYp36CJxYRg28Bhw0BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGgWDLYEngi2CFIJJNYRaFC0fAoJbL4IyBYsShi+PewKndpU0AgQLAhkBgTk?= =?us-ascii?q?2ZEx4FUkSAYUGARyBLAE6dod9B4EsgRABAQE?= Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v9AAdeZ9007572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Oct 2017 06:39:40 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Tue, 10 Oct 2017 06:39:40 -0400 From: "Teague, Nik" To: Jon Shallow , "'kaname nishizuka'" , "Konda, Tirumaleswar Reddy" , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AQHTQbQSw8iG8Vox8UW/V2PvLWtpkQ== Date: Tue, 10 Oct 2017 10:39:39 +0000 Message-ID: <85E29EEF-7B2F-48BA-B5EC-A77F06C7C005@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-originating-ip: [10.170.148.18] Content-Type: multipart/alternative; boundary="_000_85E29EEF7B2F48BAB5ECA77F06C7C005verisigncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 10:39:47 -0000 --_000_85E29EEF7B2F48BAB5ECA77F06C7C005verisigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFuZCB0aGF0IHNvcnQgb2YgaG9sZHMgd2l0aCB0aGUgY29uY2VwdCB0aGF0IHRoZSBE T1RTIGdhdGV3YXkgaXNu4oCZdCBhIHRocnUgcGF0aCBidXQgdGhlIGxvZ2ljYWwgY29uY2F0ZW5h dGlvbiB3ZSBsYWlkIG91dCBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ04oCmDQoNClRoYW5rcywN Cg0KLU5paw0KDQpPbiAxMC8xMC8yMDE3LCAxMDoyMywgIkRvdHMgb24gYmVoYWxmIG9mIEpvbiBT aGFsbG93IiA8ZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5v cmc+IG9uIGJlaGFsZiBvZiBzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPG1haWx0bzpzdXBqcHMt aWV0ZkBqcHNoYWxsb3cuY29tPj4gd3JvdGU6DQoNCkhpIEthbmFtZSwNCg0KSSBkbyBub3QgdGhp bmsgdGhhdCBpbmZvcm1hdGlvbiBuZWNlc3NhcmlseSBuZWVkcyB0byBiZSB0aGUgb3JpZ2luYWwg Y2xpZW50IGlkZW50aXR5LiAgVGhlIEdXIENsaWVudCBzaWRlIHdpbGwgaGF2ZSBpdHMgb3duIGlk ZW50aXR5IHdoaWNoIHRoZSBET1RTIFNlcnZlciBjYW4gdXNlIHRvIGRpZmZlcmVudGlhdGUgYmV0 d2VlbiBET1RTIChHVykgQ2xpZW50cy4NCg0KU28sIHllcywgYSBoYXNoZWQgc2V0IG9mIG5hbWVz IGNhbiBiZSB1c2VkIOKAkyBpdCBpcyB1cCB0byB0aGUgRE9UUyBHVyBDbGllbnQgc2lkZSB0byBt YWtlIHN1cmUgdGhhdCB0aGVyZSBhcmUgbm8gaGFzaCBjb2xsaXNpb25zLiAgT3IgaXQgY291bGQg YmUgYSBzaW1wbGUgbGlzdCBzdWNoIGFzIEMxLCBDMiDigKZDbi4NCg0KUmVnYXJkcw0KDQpKb24N Cg0KRnJvbTogRG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBrYW5hbWUgbmlzaGl6dWthDQpTZW50OiAxMCBPY3RvYmVyIDIwMTcgMDQ6MTkNClRvOiBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5OyBKb24gU2hhbGxvdzsgbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTsgZG90c0BpZXRmLm9yZzsgUm9sYW5kIERvYmJpbnMNClN1YmplY3Q6IFJlOiBbRG90 c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpLA0KDQo+IEkgYWdyZWUgdGhlIGJlbG93 IHByb2JsZW1zIGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0 IG11c3QgY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVy Lg0KSSBhZ3JlZSB3aXRoIHRoaXMgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGNhc2UuDQpBdCB0 aGUgc2FtZSB0aW1lLCBJIGFncmVlIHdpdGggYmVsb3c6DQo+IEkgYWdyZWUgdGhhdCBpcyBub3Qg YSBnb29kIHRoaW5nIHRvIOKAnGxlYWvigJ0gb3V0IGludGVybmFsIGluZm9ybWF0aW9uIHdoZW4g cGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHVywNCg0KVGhlbiwgc2hvdWxkIERPVFMgR1cgc2VuZCDi gJxjbGllbnQgaWRlbnRpdHnigJ0gKGkuZS4gY2VydGlmaWNhdGVzIG9mIERPVFMgY2xpZW50cykg aXRzZWxmIG9yIGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHnigJ0pIHRvIERPVFMgc2VydmVyPw0K SWYgbGF0ZXIsIGhvdyBjYW4gRE9UUyBzZXJ2ZXIgcmVhY3QgdG8gdGhlIGFtYmlndW91cyBpbmZv cm1hdGlvbiBvZiB0aGUgaGFzaGVkKOKAnGNsaWVudCBpZGVudGl0eeKAnSkuDQoNCnJlZ2FyZHMs DQpLYW5hbWUNCg0KDQoNCk9uIDIwMTcvMTAvMDkgMjI6MzQsIEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkgd3JvdGU6DQpIaSBKb24sDQoNCkkgYWdyZWUgdGhlIGJlbG93IHByb2JsZW1zIGFyZSBh cHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IG11c3QgY29udmV5IHRo ZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiBCdXQgZm9yIHRoZSBj bGllbnQtc2lkZSBET1RTIGdhdGV3YXksIGl0IHNob3VsZCByZXNvbHZlIGNvbmZsaWN0aW5nIHJ1 bGVzIGIvdyBET1RTIGNsaWVudHMgKGUuZy4gb25lIGNsaWVudCBpbnN0YWxsaW5nIGJsYWNrLWxp c3QgQUNMIGZvciBhbiBJUCBhZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xpZW50IGluc3RhbGxzIHdo aXRlLWxpc3QgQUNMIGZvciB0aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1lIGFsaWFzLW5hbWVzIGZv ciBkaWZmZXJlbnQgbWl0aWdhdGlvbiBzY29wZXMpLiBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkIGZv ciBhIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKAnGNsaWVudCBpZGVu dGl0eeKAnSB0byB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IG9yIERPVFMgc2VydmVyLg0K DQotVGlydQ0KDQpGcm9tOiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxv dy5jb21dDQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3IDI6MDcgUE0NClRvOiBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29t PjxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBk b3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMgPHJkb2Ji aW5zQGFyYm9yLm5ldD48bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4NClN1YmplY3Q6IFJFOiBb RG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUsDQoNClRoaXMgZGlzY3Vz c2lvbiBnb2VzIGJleW9uZCBqdXN0IHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QuICBXZSBuZWVkIHRv IGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3aXRoIGJvdGggYWxpYXMtbmFtZSBhbmQgYWNsLW5hbWUg KGRhdGEgY2hhbm5lbCkNCg0KVGhlIHNpbXBsZSBjYXNlIG9mIGEgbWl0aWdhdGlvbiByZXF1ZXN0 IHdpdGggbm8gYWxpYXMtbmFtZSBkb2VzIG5vdCByZXF1aXJlIGFueSBrbm93bGVkZ2Ugb2YgdGhl IG9yaWdpbmFsIGNsaWVudC4NCg0KSG93ZXZlciwgaWYgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCB1 c2VzIGFsaWFzLW5hbWUsIHRoZW4gdGhlcmUgYXJlIDMgd2F5cyBvZiBoYW5kbGluZyB0aGlzDQoN CmEpICAgICAgIFRoZSBET1RTIEdXIHJlcGxhY2VzIHRoZSBhbGlhcy1uYW1lIHdpdGggaXRzIGFj dHVhbCBkZWZpbml0aW9uICh0YXJnZXQtaXBzIGV0Yy4gbWVyZ2VkIGFzIGFwcHJvcHJpYXRlKSwg c28gYWxpYXMtbmFtZSBpcyBub3QgZm9yd2FyZGVkIG9uIHRvIFNlcnZlciDigJMganVzdCB0aGUg ZXhwYW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGZvcndhcmRlZA0KDQpiKSAgICAgIFRoZSBE T1RTIEdXIHVwZGF0ZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBhIHVuaXF1ZSBhbGlhcy1uYW1lIHRo YXQgaXMgZm9yd2FyZGVkIChhbmQgaGFzIHRvIGRvIHRoZSBzYW1lIHRoaW5nIHdoZW4gdGhlIGFs aWFzLW5hbWUgaXMgY29uZmlndXJlZCBvbiB0aGUgZGF0YSBjaGFubmVsKSDigJMgdG8gaGFuZGxl IDIgb3IgbW9yZSBjbGllbnRzIGRlZmluaW5nIHRoZSBzYW1lIGFsaWFzLW5hbWUgd2hpY2ggaGF2 ZSBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNzDQoNCmMpICAgICAgIFRoZSBET1RTIEdXIHJlY29n bmlzZXMgdGhhdCBhbGlhcy1uYW1lIGlzIG5vdCB1bmlxdWUgYW5kIGFkZHMgaW4g4oCdYWRkaXRp b25hbC1jbGllbnQtaW5mb+KAnSAoSSB0aGluayBJIHByZWZlciB0aGlzIOKAnC1pbmZv4oCdIG5h bWUgdG8gY2xpZW50LWlkIG9yIG9yaWdpbmFsLWNsaWVudC1pZCBhcyDigJwtaWTigJ0gaXMgdG9v IGNsb3NlbHkgIGFzc29jaWF0ZWQgd2l0aCBDbGllbnQgSWRlbnRpdHkgZGVyaXZlZCBmcm9tIHRo ZSBET1RTIEdXIENsaWVudCBjZXJ0aWZpY2F0ZSkNCldlIGhhdmUgYWdyZWVkIHRoYXQgd2hlbiBh IGNsaWVudCByZXF1ZXN0cyBtaXRpZ2F0aW9uIHN0YXR1cywgdGhlIOKAnGFsaWFzLW5hbWXigJ0g c2hvdWxkIGJlIHJldHVybmVkIGFzIOKAnGFsaWFzLW5hbWXigJ0gYW5kIG5vdCB0aGUgc3Vic3Rp dHV0ZWQgYWxpYXMtbmFtZSBjb25maWd1cmF0aW9uICh0aGlzIGRvZXMgbmVlZCB0byBiZSBzdGF0 ZWQgaW4gdGhlIHNwZWMgZm9yIGNsYXJpdHkpLiAgVGhpcyBtYWtlcyAoYSkgZGlmZmljdWx0IHRv IGJlIGhhbmRsZWQgYnkgRE9UUyBHVyB3aGljaCB0aGVuIHJhaXNlcyB0aGUgcXVlc3Rpb24g4oCT IGRvIHdlIHJlYWxseSBuZWVkIGFsaWFzLW5hbWU/DQoNClRoZSBkZWZpbml0aW9uIGFuZCBhc3Nv Y2lhdGlvbiBvZiBBQ0xzL0ZpbHRlcnMgb2YgdGhlIGRhdGEgY2hhbm5lbCBpcyBtb3JlIGRpZmZp Y3VsdCDigJMgdGhlIFNlcnZlciBtdXN0IGluc3RhbGwgLyBhcHBseSB0aGUgYXBwcm9wcmlhdGUg QUNMcyBvbiBhIHBlciAoT3JpZ2luYWwpIENsaWVudCBiYXNpcyB3aGVuIG1pdGlnYXRpb24gaXMg aW52b2tlZC4NCkNsaWVudCAx4oCZcyBjb25jZXB0IG9mIGEgV2hpdGVsaXN0IElQIGNvdWxkIGJl IENsaWVudCAy4oCZcyBjb25jZXB0IG9mIGEgQmxhY2tsaXN0IElQLiAgVGhlIFNlcnZlciBuZWVk cyB0byBrbm93IHdoaWNoIGNsaWVudCBpcyByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uIGFuZCBp bnN0YWxsIHRoZSBjb3JyZWN0IEFDTHMg4oCTIGlmIHRoZXJlIHdhcyBubyDigJ1hZGRpdGlvbmFs LWNsaWVudC1pbmZv4oCdLCB0aGUgU2VydmVyIG9ubHkga25vd3MgdGhhdCBoZSBoYXMgdG8gaW5z dGFsbCBBTEwgb2YgdGhlIEFDTHMgKGkuZS4gYm90aCB0aGUgQmxhY2sgYW5kIFdoaXRlIGxpc3Qg b2YgdGhlIHNhbWUgSVAgYXMgZGVmaW5lZCBieSBDbGllbnQgMSBhbmQgQ2xpZW50IDIpIGFzIGRl ZmluZWQgYnkgaGlzIGNsaWVudCAoRE9UUyBHVykgd2hlbiBoaXMgY2xpZW50IHJlcXVlc3RzIGEg bWl0aWdhdGlvbi4gIEhlcmUsIEkgdGhpbmsgdGhhdCBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25l IGNsaWVudCBmb3IgdGhlIERPVFMgR1csIOKAnWFkZGl0aW9uYWwtY2xpZW50LWluZm/igJ0gaXMg cmVxdWlyZWQuDQoNClJlZ2FyZHMNCg0KSm9uDQoNCkZyb206IERvdHMgW21haWx0bzogZG90cy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg T2YgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KU2VudDogMDcgT2N0b2JlciAyMDE3IDA0OjI4 DQpUbzogSm9uIFNoYWxsb3c7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGll dGYub3JnPjsgUm9sYW5kIERvYmJpbnMNClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBHYXRld2F5 cyBDaGFsbGVuZ2VzDQoNCkluIGNhc2Ugb2YgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5LCB3aHkg ZG9lcyB0aGUgRE9UUyBzZXJ2ZXIgbmVlZCB0byBrbm93IHdoaWNoIOKAnERPVFMgY2xpZW504oCd IGhhcyBjb252ZXllZCB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0ID8NCkZvciBleGFtcGxlLCB0aGUg RE9UUyBjbGllbnQgY291bGQgYmUgYSBERG9TIGRldGVjdG9yIG9yIGFuIEFwcGxpY2F0aW9uIHNl cnZlciwgYW5kIHRoZSBjbGllbnQtc2lkZSBnYXRld2F5IHdpbGwgaGF2ZSB0byByZXNvbHZlIHRo ZSBjb25mbGljdGluZyBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50cywg YWdncmVnYXRlIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50IGFu ZCBzZW5kIHRoZSB1cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIu DQoNCi1UaXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFs bG93LmNvbV0NClNlbnQ6IEZyaWRheSwgT2N0b2JlciA2LCAyMDE3IDc6NDIgUE0NClRvOiBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29t PG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPj47IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBk b3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMgPHJkb2Ji aW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pj4NClN1YmplY3Q6IFJFOiBb RG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUsDQoNClVubGVzcyBJIGFt IG1pc3Npbmcgc29tZXRoaW5nLCBob3cgZG9lcyB0aGUgQ2xpZW50IHNpZGUgb2YgRE9UUyBHVyBj b252ZXkgdG8gdGhlIHVwc3RyZWFtIHNlcnZlciBhIHVuaXF1ZSDigJxjbGllbnQtaWTigJ0gd2hp Y2ggaXMgZGlmZmVyZW50IHRvIHRoZSBpbXBsaWVkIGNsaWVudCBpZCBhcyBkZXJpdmVkIGZyb20g dGhlIFBLSSBjZXJ0aWZpY2F0ZSB0aGF0IHRoZSBET1RTIEdX4oCZQ2xpZW50IHVzZXMvcHJlc2Vu dHMgd2hlbiBjb21tdW5pY2F0aW5nIHRvIHRoZSBzZXJ2ZXI/DQpUbyBtZSwgdGhlcmUgbmVlZHMg dG8gYmUgYW4gb3B0aW9uIHN1Y2ggYXMg4oCcb3JpZ2luYWwtY2xpZW50LWlk4oCdIG9yIOKAnGNs aWVudC1pZOKAnSAod2hpY2ggaXMgY29uZnVzaW5nIHdoZW4gYWxzbyByZWZlcnJpbmcgdG8gdGhl IGNsaWVudCBpZGVudGl0eSBhcyBkZXJpdmVkIGZyb20gdGhlIChET1RTIEdXKSBDbGllbnTigJlz IFBLSSBjZXJ0aWZpY2F0ZSkgYXMgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbC4NCg0KSSBhZ3JlZSB0 aGF0IHRoZSBET1RTIEdXIGNhbiBnZW5lcmF0ZSBpdHMgb3duIHVuaXF1ZSBjbGllbnQtaWQgdG8g c3RvcCBtdWx0aXBsZSBlbnRyaWVzIGJlaW5nIG5lZWRlZC4NCg0KSSBhZ3JlZSB0aGF0IGlzIG5v dCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5mb3JtYXRpb24gd2hl biBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLCBzbyBteSBSRVFVSVJFRCBkb2VzIG5vdCBtYWtl IHNlbnNlLg0KDQpSZWdhcmRzDQoNCkpvbg0KUFMg4oCTIEkgYW0gaGF2aW5nIHRvIGRlYWwgd2l0 aCBvdGhlciBzdHVmZiBhdCBwcmVzZW50IOKAkyBJIHdpbGwgZ2V0IGJhY2sgbGF0ZXIgb24gdGhl IG90aGVyIGlzc3VlcyB1bmRlciBkaXNjdXNzaW9uDQoNCkZyb206IEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHkgW21haWx0bzogVGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbTxtYWls dG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbT5dDQpTZW50OiAwNiBPY3RvYmVy IDIwMTcgMTQ6NTgNClRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgSm9uIFNoYWxsb3c7ICdEb2JiaW5zLCBSb2xhbmQn OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtEb3Rz XSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSSBkb27igJl0IHNlZSBhIG5lZWQgZm9yIGNs aWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKAnERPVFMgY2xpZW50IGlkZW50 aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4g4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gbG9v a3MgcmVxdWlyZWQgb25seSBmb3IgdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheXMuIEluIGNh c2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5IHRoZSBjbGllbnQt aWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBE T1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1bmlxdWUgY2xpZW50 LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4gYXJyYXkgb2YgY2xpZW50LWlkcyB0byB0 aGUgRE9UUyBzZXJ2ZXIgdG8gcmVzb2x2ZSBjbGFzaGVzLg0KDQotVGlydQ0KDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRvdHMgbWFp bGluZyBsaXN0DQoNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQoNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQo= --_000_85E29EEF7B2F48BAB5ECA77F06C7C005verisigncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4AC1CF488F166B4B8851E53DAD8B880B@verisign.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlBNaW5nTGlVOw0KCXBhbm9zZS0xOjIg MiA1IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiU2Vnb2UgVUkiO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlm Ow0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7DQoJY29sb3I6 YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDoz Ni4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzYW5zLXNlcmlmOw0KCWNvbG9y OmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9 DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxl cyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUg ZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnAuVGV4dGVk ZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxsZXMNCgl7bXNvLXN0eWxl LW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxl cyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciLHNlcmlmOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6d2luZG93dGV4dCI+QW5kIHRoYXQgc29ydCBvZiBob2xkcyB3aXRoIHRoZSBjb25jZXB0 IHRoYXQgdGhlIERPVFMgZ2F0ZXdheSBpc27igJl0IGEgdGhydSBwYXRoIGJ1dCB0aGUgbG9naWNh bCBjb25jYXRlbmF0aW9uIHdlIGxhaWQgb3V0IGluIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnTigKY8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPi1OaWs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAx MC8xMC8yMDE3LCAxMDoyMywgJnF1b3Q7RG90cyBvbiBiZWhhbGYgb2YgSm9uIFNoYWxsb3cmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNl c0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZA anBzaGFsbG93LmNvbSI+c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTwvYT4mZ3Q7IHdyb3RlOjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SGkgS2FuYW1lLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SSBkbyBub3QgdGhpbmsgdGhhdCBpbmZvcm1hdGlvbiBuZWNlc3NhcmlseSBuZWVkcyB0byBiZSB0 aGUgb3JpZ2luYWwgY2xpZW50IGlkZW50aXR5LiZuYnNwOyBUaGUgR1cgQ2xpZW50IHNpZGUgd2ls bCBoYXZlIGl0cyBvd24gaWRlbnRpdHkNCiB3aGljaCB0aGUgRE9UUyBTZXJ2ZXIgY2FuIHVzZSB0 byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gRE9UUyAoR1cpIENsaWVudHMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbywgeWVzLCBhIGhhc2hlZCBzZXQgb2YgbmFtZXMg Y2FuIGJlIHVzZWQg4oCTIGl0IGlzIHVwIHRvIHRoZSBET1RTIEdXIENsaWVudCBzaWRlIHRvIG1h a2Ugc3VyZSB0aGF0IHRoZXJlIGFyZSBubyBoYXNoIGNvbGxpc2lvbnMuJm5ic3A7IE9yDQogaXQg Y291bGQgYmUgYSBzaW1wbGUgbGlzdCBzdWNoIGFzIEMxLCBDMiDigKZDbi48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkpvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBEb3RzIFttYWlsdG86IGRvdHMt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+a2FuYW1lIG5pc2hpenVrYTxi cj4NCjxiPlNlbnQ6PC9iPiAxMCBPY3RvYmVyIDIwMTcgMDQ6MTk8YnI+DQo8Yj5Ubzo8L2I+IEtv bmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk7IEpvbiBTaGFsbG93OyBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tOyBkb3RzQGlldGYub3JnOyBSb2xhbmQgRG9iYmluczxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJv dHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCkhpLDxicj4NCjxicj4NCiZndDsgSSBh Z3JlZSB0aGUgYmVsb3cgcHJvYmxlbXMgYXJlIGFwcGxpY2FibGUgZm9yIHNlcnZlci1zaWRlIERP VFMgZ2F0ZXdheSwgaXQgbXVzdCBjb252ZXkgdGhlIOKAnGNsaWVudCBpZGVudGl0eeKAnSB0byB0 aGUgRE9UUyBzZXJ2ZXIuDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UE1pbmdMaVUm cXVvdDssc2VyaWYiPjxicj4NCjwvc3Bhbj5JIGFncmVlIHdpdGggdGhpcyBzZXJ2ZXItc2lkZSBE T1RTIGdhdGV3YXkgY2FzZS48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UE1pbmdMaVUm cXVvdDssc2VyaWYiPjxicj4NCjwvc3Bhbj5BdCB0aGUgc2FtZSB0aW1lLCBJIGFncmVlIHdpdGgg YmVsb3c6PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BNaW5nTGlVJnF1b3Q7LHNlcmlm Ij48YnI+DQo8L3NwYW4+Jmd0OyBJIGFncmVlIHRoYXQgaXMgbm90IGEgZ29vZCB0aGluZyB0byDi gJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1hdGlvbiB3aGVuIHBhc3NpbmcgdGhyb3VnaCBh IERPVFMgR1csDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UE1pbmdMaVUmcXVvdDss c2VyaWYiPjxicj4NCjxicj4NCjwvc3Bhbj5UaGVuLCBzaG91bGQgRE9UUyBHVyBzZW5kIOKAnGNs aWVudCBpZGVudGl0eeKAnSAoaS5lLiBjZXJ0aWZpY2F0ZXMgb2YgRE9UUyBjbGllbnRzKSBpdHNl bGYgb3IgaGFzaGVkKOKAnGNsaWVudCBpZGVudGl0eeKAnSkgdG8gRE9UUyBzZXJ2ZXI/PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BNaW5nTGlVJnF1b3Q7LHNlcmlmIj48YnI+DQo8L3Nw YW4+SWYgbGF0ZXIsIGhvdyBjYW4gRE9UUyBzZXJ2ZXIgcmVhY3QgdG8gdGhlIGFtYmlndW91cyBp bmZvcm1hdGlvbiBvZiB0aGUgaGFzaGVkKOKAnGNsaWVudCBpZGVudGl0eeKAnSkuPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BNaW5nTGlVJnF1b3Q7LHNlcmlmIj48YnI+DQo8YnI+DQo8 L3NwYW4+cmVnYXJkcyw8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UE1pbmdMaVUmcXVv dDssc2VyaWYiPjxicj4NCjwvc3Bhbj5LYW5hbWU8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7UE1pbmdMaVUmcXVvdDssc2VyaWYiPjxicj4NCjxicj4NCjwvc3Bhbj48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5PbiAyMDE3LzEwLzA5IDIyOjM0LCBLb25kYSwgVGlydW1hbGVzd2FyIFJl ZGR5IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgSm9uLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5JIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJsZSBmb3Igc2Vy dmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50 aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gQnV0IGZvciB0aGUgY2xpZW50LXNpZGUNCiBET1RT IGdhdGV3YXksIGl0IHNob3VsZCByZXNvbHZlIGNvbmZsaWN0aW5nIHJ1bGVzIGIvdyBET1RTIGNs aWVudHMgKGUuZy4gb25lIGNsaWVudCBpbnN0YWxsaW5nIGJsYWNrLWxpc3QgQUNMIGZvciBhbiBJ UCBhZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xpZW50IGluc3RhbGxzIHdoaXRlLWxpc3QgQUNMIGZv ciB0aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1lIGFsaWFzLW5hbWVzIGZvciBkaWZmZXJlbnQgbWl0 aWdhdGlvbiBzY29wZXMpLiBJIGRvbuKAmXQNCiBzZWUgdGhlIG5lZWQgZm9yIGEgY2xpZW50LXNp ZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRo ZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgb3IgRE9UUyBzZXJ2ZXIuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi1U aXJ1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEpvbiBTaGFsbG93IFs8YSBocmVmPSJtYWlsdG86 c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5j b208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBPY3RvYmVyIDcsIDIwMTcgMjow NyBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8YSBocmVmPSJt YWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+DQombHQ7VGlydW1hbGVz d2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSZndDs8L2E+OyA8YSBocmVmPSJtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9h PjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xh bmQgRG9iYmlucw0KPGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+Jmx0O3Jkb2Ji aW5zQGFyYm9yLm5ldCZndDs8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9U UyBHYXRld2F5cyBDaGFsbGVuZ2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGRpc2N1c3Npb24gZ29lcyBiZXlv bmQganVzdCB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0LiZuYnNwOyBXZSBuZWVkIHRvIGNvbnNpZGVy IHdoYXQgaGFwcGVucyB3aXRoIGJvdGggYWxpYXMtbmFtZSBhbmQgYWNsLW5hbWUgKGRhdGENCiBj aGFubmVsKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIHNpbXBs ZSBjYXNlIG9mIGEgbWl0aWdhdGlvbiByZXF1ZXN0IHdpdGggbm8gYWxpYXMtbmFtZSBkb2VzIG5v dCByZXF1aXJlIGFueSBrbm93bGVkZ2Ugb2YgdGhlIG9yaWdpbmFsIGNsaWVudC4mbmJzcDsNCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgaWYgdGhlIG1p dGlnYXRpb24gcmVxdWVzdCB1c2VzIGFsaWFzLW5hbWUsIHRoZW4gdGhlcmUgYXJlIDMgd2F5cyBv ZiBoYW5kbGluZyB0aGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmEpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RTIEdX IHJlcGxhY2VzIHRoZSBhbGlhcy1uYW1lIHdpdGggaXRzIGFjdHVhbCBkZWZpbml0aW9uICh0YXJn ZXQtaXBzIGV0Yy4gbWVyZ2VkIGFzIGFwcHJvcHJpYXRlKSwgc28gYWxpYXMtbmFtZSBpcyBub3Qg Zm9yd2FyZGVkIG9uIHRvIFNlcnZlciDigJMganVzdCB0aGUgZXhwYW5kZWQgbWl0aWdhdGlvbg0K IHJlcXVlc3QgaXMgZm9yd2FyZGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmIpPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RTIEdX IHVwZGF0ZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBhIHVuaXF1ZSBhbGlhcy1uYW1lIHRoYXQgaXMg Zm9yd2FyZGVkIChhbmQgaGFzIHRvIGRvIHRoZSBzYW1lIHRoaW5nIHdoZW4gdGhlIGFsaWFzLW5h bWUgaXMgY29uZmlndXJlZCBvbiB0aGUgZGF0YSBjaGFubmVsKSDigJMgdG8gaGFuZGxlDQogMiBv ciBtb3JlIGNsaWVudHMgZGVmaW5pbmcgdGhlIHNhbWUgYWxpYXMtbmFtZSB3aGljaCBoYXZlIGRp ZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDot MTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Yyk8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhl IERPVFMgR1cgcmVjb2duaXNlcyB0aGF0IGFsaWFzLW5hbWUgaXMgbm90IHVuaXF1ZSBhbmQgYWRk cyBpbiDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdIChJIHRoaW5rIEkgcHJlZmVyIHRoaXMg 4oCcLWluZm/igJ0gbmFtZSB0byBjbGllbnQtaWQgb3Igb3JpZ2luYWwtY2xpZW50LWlkIGFzIOKA nC1pZOKAnSBpcw0KIHRvbyBjbG9zZWx5ICZuYnNwO2Fzc29jaWF0ZWQgd2l0aCBDbGllbnQgSWRl bnRpdHkgZGVyaXZlZCBmcm9tIHRoZSBET1RTIEdXIENsaWVudCBjZXJ0aWZpY2F0ZSk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgaGF2ZSBhZ3JlZWQgdGhh dCB3aGVuIGEgY2xpZW50IHJlcXVlc3RzIG1pdGlnYXRpb24gc3RhdHVzLCB0aGUg4oCcYWxpYXMt bmFtZeKAnSBzaG91bGQgYmUgcmV0dXJuZWQgYXMg4oCcYWxpYXMtbmFtZeKAnSBhbmQgbm90IHRo ZSBzdWJzdGl0dXRlZA0KIGFsaWFzLW5hbWUgY29uZmlndXJhdGlvbiAodGhpcyBkb2VzIG5lZWQg dG8gYmUgc3RhdGVkIGluIHRoZSBzcGVjIGZvciBjbGFyaXR5KS4mbmJzcDsgVGhpcyBtYWtlcyAo YSkgZGlmZmljdWx0IHRvIGJlIGhhbmRsZWQgYnkgRE9UUyBHVyB3aGljaCB0aGVuIHJhaXNlcyB0 aGUgcXVlc3Rpb24g4oCTIGRvIHdlIHJlYWxseSBuZWVkIGFsaWFzLW5hbWU/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZGVmaW5pdGlvbiBhbmQgYXNzb2NpYXRp b24gb2YgQUNMcy9GaWx0ZXJzIG9mIHRoZSBkYXRhIGNoYW5uZWwgaXMgbW9yZSBkaWZmaWN1bHQg 4oCTIHRoZSBTZXJ2ZXIgbXVzdCBpbnN0YWxsIC8gYXBwbHkgdGhlIGFwcHJvcHJpYXRlDQogQUNM cyBvbiBhIHBlciAoT3JpZ2luYWwpIENsaWVudCBiYXNpcyB3aGVuIG1pdGlnYXRpb24gaXMgaW52 b2tlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2xpZW50 IDHigJlzIGNvbmNlcHQgb2YgYSBXaGl0ZWxpc3QgSVAgY291bGQgYmUgQ2xpZW50IDLigJlzIGNv bmNlcHQgb2YgYSBCbGFja2xpc3QgSVAuJm5ic3A7IFRoZSBTZXJ2ZXIgbmVlZHMgdG8ga25vdyB3 aGljaCBjbGllbnQgaXMgcmVxdWVzdGluZw0KIHRoZSBtaXRpZ2F0aW9uIGFuZCBpbnN0YWxsIHRo ZSBjb3JyZWN0IEFDTHMg4oCTIGlmIHRoZXJlIHdhcyBubyDigJ1hZGRpdGlvbmFsLWNsaWVudC1p bmZv4oCdLCB0aGUgU2VydmVyIG9ubHkga25vd3MgdGhhdCBoZSBoYXMgdG8gaW5zdGFsbCBBTEwg b2YgdGhlIEFDTHMgKGkuZS4gYm90aCB0aGUgQmxhY2sgYW5kIFdoaXRlIGxpc3Qgb2YgdGhlIHNh bWUgSVAgYXMgZGVmaW5lZCBieSBDbGllbnQgMSBhbmQgQ2xpZW50IDIpIGFzIGRlZmluZWQgYnkg aGlzIGNsaWVudA0KIChET1RTIEdXKSB3aGVuIGhpcyBjbGllbnQgcmVxdWVzdHMgYSBtaXRpZ2F0 aW9uLiZuYnNwOyBIZXJlLCBJIHRoaW5rIHRoYXQgaWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBj bGllbnQgZm9yIHRoZSBET1RTIEdXLCDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdIGlzIHJl cXVpcmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gRG90cyBbbWFpbHRvOg0KPGEgaHJlZj0ibWFpbHRvOmRv dHMtYm91bmNlc0BpZXRmLm9yZyI+ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVo YWxmIE9mDQo8L2I+S29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTxicj4NCjxiPlNlbnQ6PC9iPiAw NyBPY3RvYmVyIDIwMTcgMDQ6Mjg8YnI+DQo8Yj5Ubzo8L2I+IEpvbiBTaGFsbG93OyA8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRm Lm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10g RE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JbiBjYXNlIG9mIGNsaWVudC1zaWRlIERPVFMg Z2F0ZXdheSwgd2h5IGRvZXMgdGhlIERPVFMgc2VydmVyIG5lZWQgdG8ga25vdyB3aGljaCDigJxE T1RTIGNsaWVudOKAnSBoYXMgY29udmV5ZWQgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCA/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgZXhhbXBsZSwgdGhlIERPVFMgY2xpZW50IGNv dWxkIGJlIGEgRERvUyBkZXRlY3RvciBvciBhbiBBcHBsaWNhdGlvbiBzZXJ2ZXIsIGFuZCB0aGUg Y2xpZW50LXNpZGUgZ2F0ZXdheSB3aWxsIGhhdmUgdG8gcmVzb2x2ZSB0aGUgY29uZmxpY3RpbmcN CiBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50cywgYWdncmVnYXRlIHRo ZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50IGFuZCBzZW5kIHRoZSB1 cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pi1UaXJ1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IEpvbiBTaGFsbG93IFs8YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+ bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgT2N0b2JlciA2LCAyMDE3IDc6NDIgUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBU aXJ1bWFsZXN3YXIgUmVkZHkgJmx0OzxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9L b25kYUBNY0FmZWUuY29tIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZn dDs7DQo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3Jn Ij4NCmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJkb2JiaW5zQGFyYm9yLm5ldCI+cmRvYmJpbnNAYXJib3IubmV0PC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SGkgVGlydSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlVubGVzcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBob3cgZG9lcyB0aGUgQ2xpZW50IHNpZGUg b2YgRE9UUyBHVyBjb252ZXkgdG8gdGhlIHVwc3RyZWFtIHNlcnZlciBhIHVuaXF1ZSDigJxjbGll bnQtaWTigJ0gd2hpY2ggaXMgZGlmZmVyZW50DQogdG8gdGhlIGltcGxpZWQgY2xpZW50IGlkIGFz IGRlcml2ZWQgZnJvbSB0aGUgUEtJIGNlcnRpZmljYXRlIHRoYXQgdGhlIERPVFMgR1figJlDbGll bnQgdXNlcy9wcmVzZW50cyB3aGVuIGNvbW11bmljYXRpbmcgdG8gdGhlIHNlcnZlcj88L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG8gbWUsIHRoZXJlIG5lZWRz IHRvIGJlIGFuIG9wdGlvbiBzdWNoIGFzIOKAnG9yaWdpbmFsLWNsaWVudC1pZOKAnSBvciDigJxj bGllbnQtaWTigJ0gKHdoaWNoIGlzIGNvbmZ1c2luZyB3aGVuIGFsc28gcmVmZXJyaW5nIHRvIHRo ZSBjbGllbnQNCiBpZGVudGl0eSBhcyBkZXJpdmVkIGZyb20gdGhlIChET1RTIEdXKSBDbGllbnTi gJlzIFBLSSBjZXJ0aWZpY2F0ZSkgYXMgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCB0aGUgRE9UUyBHVyBj YW4gZ2VuZXJhdGUgaXRzIG93biB1bmlxdWUgY2xpZW50LWlkIHRvIHN0b3AgbXVsdGlwbGUgZW50 cmllcyBiZWluZyBuZWVkZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JIGFncmVlIHRoYXQgaXMgbm90IGEgZ29vZCB0aGluZyB0byDigJxsZWFr4oCdIG91dCBpbnRl cm5hbCBpbmZvcm1hdGlvbiB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR1csIHNvIG15IFJF UVVJUkVEIGRvZXMgbm90IG1ha2Ugc2Vuc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5SZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5Kb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UFMg4oCT IEkgYW0gaGF2aW5nIHRvIGRlYWwgd2l0aCBvdGhlciBzdHVmZiBhdCBwcmVzZW50IOKAkyBJIHdp bGwgZ2V0IGJhY2sgbGF0ZXIgb24gdGhlIG90aGVyIGlzc3VlcyB1bmRlciBkaXNjdXNzaW9uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gS29uZGEsIFRpcnVtYWxlc3dhciBS ZWRkeSBbbWFpbHRvOg0KPGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQG1j YWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQG1jYWZlZS5jb208L2E+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IDA2IE9jdG9iZXIgMjAxNyAxNDo1ODxicj4NCjxiPlRvOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208L2E+OyBKb24gU2hhbGxvdzsgJ0RvYmJpbnMsIFJvbGFuZCc7DQo8YSBocmVm PSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBz ZWUgYSBuZWVkIGZvciBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgdG8gY29udmV5IHRoZSDigJxE T1RTIGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIOKAnERPVFMgY2xpZW50 IGlkZW50aXR54oCdIGxvb2tzIHJlcXVpcmVkIG9ubHkNCiBmb3IgdGhlIHNlcnZlci1zaWRlIERP VFMgZ2F0ZXdheXMuIEluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4g Y29udmV5IHRoZSBjbGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlk ZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJh dGUgYSB1bmlxdWUgY2xpZW50LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4gYXJyYXkg b2YgY2xpZW50LWlkcw0KIHRvIHRoZSBET1RTIHNlcnZlciB0byByZXNvbHZlIGNsYXNoZXMuIDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4tVGlydTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Eb3RzIG1haWxp bmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxhIGhyZWY9Im1haWx0bzpEb3RzQGlldGYub3JnIj5Eb3RzQGlldGYub3JnPC9hPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cyI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kb3RzPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_85E29EEF7B2F48BAB5ECA77F06C7C005verisigncom_-- From nobody Tue Oct 10 04:05:07 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2878113448B for ; Tue, 10 Oct 2017 04:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ib8WwaZ80C1t for ; Tue, 10 Oct 2017 04:05:04 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 8692A134471 for ; Tue, 10 Oct 2017 04:05:03 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e1sLM-00039W-6f; Tue, 10 Oct 2017 12:05:00 +0100 From: "Jon Shallow" To: "'Teague, Nik'" , "kaname nishizuka" , "Konda, Tirumaleswar Reddy" , , , "Roland Dobbins" References: <85E29EEF-7B2F-48BA-B5EC-A77F06C7C005@verisign.com> In-Reply-To: <85E29EEF-7B2F-48BA-B5EC-A77F06C7C005@verisign.com> Date: Tue, 10 Oct 2017 12:05:02 +0100 Message-ID: <0d1a01d341b7$9eec6730$dcc53590$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D1B_01D341C0.00B31920" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGcqZFoMftrQtBzxU5hKyAnUio/fqNKGgtQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 11:05:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0D1B_01D341C0.00B31920 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On reflection, the hash, or C1=E2=80=A6Cn, needs to be passed from the = GW Client side to GW Server side as GW Server side potentially has no = knowledge of what is going on GW Client side. =20 Regards =20 Jon=20 =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Teague, Nik Sent: 10 October 2017 11:40 To: Jon Shallow; 'kaname nishizuka'; Konda, Tirumaleswar Reddy; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi, =20 And that sort of holds with the concept that the DOTS gateway = isn=E2=80=99t a thru path but the logical concatenation we laid out in = the architecture draft=E2=80=A6 =20 Thanks, =20 -Nik =20 On 10/10/2017, 10:23, "Dots on behalf of Jon Shallow" = wrote: =20 Hi Kaname, =20 I do not think that information necessarily needs to be the original = client identity. The GW Client side will have its own identity which = the DOTS Server can use to differentiate between DOTS (GW) Clients. =20 So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash collisions. Or = it could be a simple list such as C1, C2 =E2=80=A6Cn. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 10 October 2017 04:19 To: Konda, Tirumaleswar Reddy; Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi, > I agree the below problems are applicable for server-side DOTS = gateway, it must convey the =E2=80=9Cclient identity=E2=80=9D to the = DOTS server.=20 I agree with this server-side DOTS gateway case. At the same time, I agree with below: > I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW,=20 Then, should DOTS GW send =E2=80=9Cclient identity=E2=80=9D (i.e. = certificates of DOTS clients) itself or hashed(=E2=80=9Cclient = identity=E2=80=9D) to DOTS server? If later, how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient identity=E2=80=9D). regards, Kaname On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote: Hi Jon, =20 I agree the below problems are applicable for server-side DOTS gateway, = it must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. = But for the client-side DOTS gateway, it should resolve conflicting = rules b/w DOTS clients (e.g. one client installing black-list ACL for an = IP address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:07 PM To: Konda, Tirumaleswar Reddy = = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds = in =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0D1B_01D341C0.00B31920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On reflection, the hash, or C1=E2=80=A6Cn, needs to be passed from = the GW Client side to GW Server side as GW Server side potentially has = no knowledge of what is going on GW Client side.

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Teague, Nik
Sent: 10 October 2017 11:40
To: Jon = Shallow; 'kaname nishizuka'; Konda, Tirumaleswar Reddy; = mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi,

 

And that sort of holds with the concept that the DOTS gateway = isn=E2=80=99t a thru path but the logical concatenation we laid out in = the architecture draft=E2=80=A6

 

Thanks,

 

-Nik

 

On 10/10/2017, 10:23, = "Dots on behalf of Jon Shallow" <dots-bounces@ietf.org on = behalf of supjps-ietf@jpshallow.com&g= t; wrote:

 

Hi Kaname,

 

I do not think that information necessarily needs to be the original = client identity.  The GW Client side will have its own identity = which the DOTS Server can use to differentiate between DOTS (GW) = Clients.

 

So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash = collisions.  Or it could be a simple list such as C1, C2 = =E2=80=A6Cn.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of kaname nishizuka
Sent: 10 October 2017 = 04:19
To: Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi,

> I agree the below = problems are applicable for server-side DOTS gateway, it must convey the = =E2=80=9Cclient identity=E2=80=9D to the DOTS server.
I agree with this server-side DOTS gateway = case.
At the same time, I agree with below:
> I agree that is not a good thing to = =E2=80=9Cleak=E2=80=9D out internal information when passing through a = DOTS GW,

Then, should DOTS GW send =E2=80=9Cclient identity=E2=80=9D = (i.e. certificates of DOTS clients) itself or hashed(=E2=80=9Cclient = identity=E2=80=9D) to DOTS server?
If later, how can DOTS server react to the ambiguous = information of the hashed(=E2=80=9Cclient = identity=E2=80=9D).

regards,
Kaname


On 2017/10/09 22:34, = Konda, Tirumaleswar Reddy wrote:

Hi = Jon,

 

I agree = the below problems are applicable for server-side DOTS gateway, it must = convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. But for = the client-side DOTS gateway, it should resolve conflicting rules b/w = DOTS clients (e.g. one client installing black-list ACL for an IP = address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, October 7, 2017 2:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_= Konda@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
S= ubject: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. 

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)     &nb= sp; The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)      = The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)     &nb= sp; The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely  associated with Client = Identity derived from the DOTS GW Client certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).  This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.  The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.  Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:28
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, October 6, 2017 7:42 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= Konda, = Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 06 October 2017 14:58
To: = mohamed.boucadair@orange.com= ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: = [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 

-Tiru




_______________________________________________
Dots =
mailing list
Dots@ietf.org
https://www.ietf.org/= mailman/listinfo/dots

 

------=_NextPart_000_0D1B_01D341C0.00B31920-- From nobody Tue Oct 10 04:49:22 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E220B1344FB for ; Tue, 10 Oct 2017 04:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=mcafee.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 jQCrAp8O-JzP for ; Tue, 10 Oct 2017 04:49:15 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 C0CC6134D2E for ; Tue, 10 Oct 2017 04:47:51 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507636062; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=z 6uW9y3x+ZjJgtVDADNsECDCGU9udeBj8iupg45g9J A=; b=LsWGnklablv+9RLGom9Q9dBaldOiVIBEEhjtoU7laNWN d5VtbRC8ulqiE+rTuTm/EYvic4m/2/yysai+BrYIkq6/Veac/G y/9RjlrFHuvN1PAmR8tWcw3xpGL0tY0F0XX55eQaKgyknLHoiI iHCZcyHCNIR934eiWjTElCOzKSQ= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c29_9400_6efe1354_70df_4348_b213_10b5ce993d1b; Tue, 10 Oct 2017 06:47:41 -0500 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 05:47:36 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 05:47:34 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Oct 2017 05:47:34 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 05:47:32 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 11:47:31 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 11:47:31 +0000 From: "Konda, Tirumaleswar Reddy" To: Flemming Andreasen , Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AdM866F1exiXOD0RS+2TvvngfvHPNAAHYE+AAC3w14AA1RHAgAAAO8mwAAGjSgAAADRgQA== Date: Tue, 10 Oct 2017 11:47:31 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com> In-Reply-To: <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:Aa9oI40vA4avLt7/MZ1fqOu/zRmi5TJuqAPH6LeywCu64C38o73V6nQFVZM62qxNW8WmJMUnZR0M2D52X6rHccr+B3K5H2WbYi9SuO8kIe0wsaIVjWW5jy9bPXi5Pg3qinkUqoAY5LBYN+HXAeUgVKPvvSvgNId1QverF42fL/zq7ez81H8TO845u6zSL09yGgJulTn8BvuJP+6J81wB6oH3L9/WPCVNZsfuybmsQ5uUiPqtZ9KmFMO3p0DpPeYMMrOnrtRAkjpcR3bwjLg35dY7XSEezs454qFK/5+awvvA/m1UipMUWpgzCwV6DiebVzKcVygfNpV30FMpuCSAPQ==; 5:ZeqtfdGyeMaRgX5fcxkgI+4nMuX2dSX5vTCAn8FSfxtzx80C1pjCcX2jrzHpATfjSiFEG4vSfRs3rKc2K5edDXo/tmyVsaewx/JhilO6hTTJzA4uGmC++l2POafHZKOL7FDl/dD8EpjD8HXfkUDqMw==; 24:DVeNTJRCu3tAF3QGNu6cslATdJhsnSLAVdG0thOvi6Wdr0tJxNGetwAbhXdLDs7lhGY4fLJRvsKraRGKlj8Rgu61seKd9ik3eCHeN0HPH0k=; 7:0CdUqzd94FCvjMFZj6esACZevsiVuy+5MQbkBUkKcgcI8II17WbGgaAytK4AViuUXKmbWwy7DBZ+hAXpfelqKsoz2Fbvz+GQDSD5N/SvzTEYzzKW1KN0wQYy7V5f0LUUx8BjWql9O0/y7h60KGqJEAEMmIqVJv7dHaQKlCkeNzLWeZJzasQLR4/ZvRhD9dNpPtYFoPYbN0o5YEtTiAq9Z3/ZLh79bdG9SGgK35Pi+jI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a916a6e3-499d-4e09-164f-08d50fd4b0b6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(346002)(376002)(377454003)(32952001)(199003)(189002)(24454002)(106356001)(102836003)(6116002)(3846002)(97736004)(3280700002)(99286003)(6246003)(66066001)(9686003)(236005)(2501003)(790700001)(966005)(316002)(55016002)(105586002)(53946003)(110136005)(3660700001)(25786009)(2906002)(53936002)(6506006)(229853002)(80792005)(54896002)(77096006)(6306002)(6436002)(2201001)(68736007)(606006)(189998001)(101416001)(14454004)(86362001)(93886005)(74316002)(8676002)(81166006)(81156014)(8936002)(5660300001)(9326002)(2950100002)(2900100001)(33656002)(54356999)(7736002)(478600001)(53546010)(72206003)(50986999)(76176999)(7696004)(562404015)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C15B485932A438A30192EA750DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 11:47:31.4062 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6117> : streams <1766640> : uri <2514239> Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 11:49:20 -0000 --_000_DM5PR16MB1788C15B485932A438A30192EA750DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Flemming, Please see inline From: Flemming Andreasen [mailto:fandreas@cisco.com] Sent: Monday, October 9, 2017 10:06 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; mohamed.boucadair@orange.com; dots@ietf.o= rg Subject: Re: [Dots] Minimum heartbeat-interval On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote: From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen Sent: Monday, October 9, 2017 9:12 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow = ; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. I'm getting different data-points for at least the minimum value. There sti= ll seems to be a lot of NATs out there with a timeout value of ~30 seconds = for UDP traffic (and in rare cases even lower), which suggests that a timeo= ut value slightly lower than 30 seconds is what you would want. Google did = a lot of testing around this and decided they were happy with the values in= https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds). Consent freshness has nothing to do with NAT/FW timeouts. You are missing the point Tiru - testing has been done (in the past and mor= e recently) and a value of ~30 seconds seems to be what works for the major= ity of devices. I'll trust Google on this one. [TR] I see that QUIC is using 15 to 30 seconds keepalives to handle middlebox id= le timeout (https://tools.ietf.org/html/draft-ietf-quic-transport-06#sectio= n-8.7) but I don't see any reference to the results published by Google, C= an you please point to the test results by Google to refer in the DOTS sign= al channel draft? (http://conferences.sigcomm.org/imc/2010/papers/p260.pdf results indicate 3= 0 seconds is only applicable when there is only outbound traffic and no incoming traffic). -Tiru -- Flemming -Tiru Thanks -- Flemming Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). 2) No, if the DOTS agent wants to change the default heartbeat interval the= n the other message transmission parameters will also have to be modified. 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_DM5PR16MB1788C15B485932A438A30192EA750DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Flemming= ,

 

Please see inline

 

From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Monday, October 9, 2017 10:06 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@oran= ge.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

 

On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote= :

From: Dots [mailto:dots-bounces@ietf.org<= span style=3D"color:windowtext;mso-fareast-language:ZH-CN">] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <Tirum= aleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

 

On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote:=

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.o= rg/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices= (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout val= ue observed when packets are exchanged b/w peers in both directions is 54 s= econds.

 

I'm getting differe= nt data-points for at least the minimum value. There still seems to be a lo= t of NATs out there with a timeout value of ~30 seconds for UDP traffic (an= d in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what you would want= . Google did a lot of testing around this and decided they were happy with = the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds).

 

Consent freshness has nothing to do with NAT/FW timeouts.

You are missing the p= oint Tiru - testing has been done (in the past and more recently) and a val= ue of ~30 seconds seems to be what works for the majority of devices. I'll trust Google on this one.

 

[TR]

I see that QUIC is using 15 to 30 seconds keepalives to handle midd= lebox idle timeout (https://tools.ietf.org/html/draft-ietf-quic-transport-06#section-8.7) but I don’t see any reference to the results published by Google,  Can you please point to the test results by Google to refer in the DOTS signal channel draft?=

(http://conferences= .sigcomm.org/imc/2010/papers/p260.pdf results indicate 30 seconds is only applicable when there is only outbound traffic

and no incoming traffic).

 

-Tiru


-- Flemming



 

-Tiru



Thanks

-- Flemming




Responses to the questions below

 

1) The max-retransmit parameter is negotiable and configurable,&nbs= p; DOTS agents can pick suitable values for max-retransmit parameter based = on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds). <= /o:p>

2) No, if the DOTS agent wants to change the default heartbeat inte= rval then the other message transmission parameters will also have to be mo= dified.

3) The client will have to assume the session is disconnected (see = the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.= 1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The he= artbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 

Med – In the below text, recommended value should be 93 secon= ds instead of 90 seconds (see https://tools.ietf.or= g/html/rfc7252#section-4.8.2).

 

-Tiru

 

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadair@orange.com; dots@ietf.org=
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

 <= /span>

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

 <= /span>

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

 <= /span>

Oct 04 10:53:51 DEBG sending CoAP ping:

Oct 04 10:53:51 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to retransmit queue= (2281ms)

Oct 04 10:53:51 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message 295= 48

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending CoAP ping:

Oct 04 10:54:07 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to retransmit queue= (2938ms)

Oct 04 10:54:07 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message 295= 49

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending CoAP ping:

Oct 04 10:54:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to retransmit queue= (2156ms)

Oct 04 10:54:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message 295= 50

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending CoAP ping:

Oct 04 10:54:39 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to retransmit queue= (2813ms)

Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #1=

Oct 04 10:54:42 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #2=

Oct 04 10:54:48 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #3=

Oct 04 10:55:00 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #4=

Oct 04 10:55:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up after 4 attempts=

 <= /span>

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

 <= /span>

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

 <= /span>

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

 <= /span>

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

 <= /span>

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Scenari= o as Q3

 <= /span>

Does th= e client re-use the old session that the heartbeats are failing on?<= o:p>

- The s= erver may have sent a session close, but it never got through

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

 <= /span>

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

 <= /span>

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

Regards=

 <= /span>

Jon

 <= /span>

From: Dots [mailto:ietf-supjps-dots-bounces@iet= f.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange= .com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com)
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during the int= erim meeting: “A: (Jon Shallo= w): The minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with = RFC8085 which says the following:

 

   An application that needs to employ keep-alive messages t=
o deliver
   useful service over UDP in the presence of middleboxes SH=
OULD NOT
           &nbs=
p;            &=
nbsp;           &nbs=
p;         ^^^^^^^^^^^^^^^^^^^^^^
   transmit them more frequently than once every 15 seconds =
and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^
   use longer intervals when possible.  

 


I suggest to add this NEW text to the signal-=
channel draft to clarify the rationale for the recommended values:



 


NEW:


  =
    Note: heartbeat-interval should be tweaked to also assis=
t DOTS


  =
   
messages for NAT traversal (SIG-010 of<=
span lang=3D"DA">


=
     
[I-D.ietf-dots-requirements]).  According to [RFC8085=
], keepalive


  =
    messages must not be sent more frequently than once ever=
y 15


  =
    seconds and should use longer intervals when possible.


  =
    Furthermore, [RFC4787] recommends NATs to use a state ti=
meout of 2


  =
    minutes or longer.  From that standpoint, this spec=
ification


  =
    recommends a minimum heartbeat-interval of 15 seconds an=
d a


  =
    maximum heartbeat-interval of 240 seconds.  The rec=
ommended value


  =
    of 90 seconds is selected to anticipate the expiry of NA=
T states,


  =
    while avoiding overloading the network with frequent kee=
palives


  =
    for NAT state maintenance purposes.  Note that this=
 recommended


  =
    value is close to the one recommended for MAX_TRANSMIT_W=
AIT, whose


  =
    value is derived from transmission parameters (Section 4=
.8.2 of


      [RFC7252]).=



 


Thoughts?



 


Cheers,


Med







_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.iet=
f.org/mailman/listinfo/dots

 <= /o:p>

 

--_000_DM5PR16MB1788C15B485932A438A30192EA750DM5PR16MB1788namp_-- From nobody Tue Oct 10 04:51:14 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF7D134D48 for ; Tue, 10 Oct 2017 04:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=mcafee.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 oTqXXu73Zxbx for ; Tue, 10 Oct 2017 04:51:09 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 08833134D5A for ; Tue, 10 Oct 2017 04:50:15 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507636210; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=/ WfFLiLlc5xrarYt1pG8LulhV3C57r/h8nJjnP8LXw U=; b=dVh7Slvc8APnzKMc4lssdH1QQQ9fBLfMKUrPf3CojWVw yvVZ5O1zByqQvO7fm7rQVBvRmFx7T/Qi8yXn9JsvRQkvnPg06r Y7c3Dd9tQjGjg0yVi/ppgS+4R0dN2lZR2yhN8jq4dPuXjzb/5h +jxxvEggDV3Rm+rf0wiLrGKFlmA= Received: from DNVEXAPP1N04.corpzone.internalzone.com (dnvexapp1n04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c1a_1380_b4dde73e_79da_46cb_ab1e_a5dcb28a80b0; Tue, 10 Oct 2017 06:50:09 -0500 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 05:50:06 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 05:50:04 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Oct 2017 05:50:05 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 05:50:04 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 11:50:02 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 11:50:02 +0000 From: "Konda, Tirumaleswar Reddy" To: kaname nishizuka , Flemming Andreasen , Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AdM866F1exiXOD0RS+2TvvngfvHPNAAHYE+AAC3w14AA1RHAgAAAO8mwAAGjSgAAFud1gAAD7BUg Date: Tue, 10 Oct 2017 11:50:02 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com> <4406f5bc-60ea-96dc-d74b-a74430b83285@nttv6.jp> In-Reply-To: <4406f5bc-60ea-96dc-d74b-a74430b83285@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:w52ZYBGD84bMKJnNeN/j0ZPSUAaOteKvb9Eq8MFGo+QfolXKcr0V0f6n3EF9/FtP80BFCTXGdA6FPu/OWCFPdGAkh6F7vpKizdU1BR7Ne8FaFogixcsAFBs8BAlo7I2jyokBoVhxmAuSPGeC8OLpYEJfqEpoNy8IQMstSNBsQz8hmgG+z3nEJkIMOdaKI4uu2QvUsc1bAW7tuhjKiTnDe/ervPHmBMtQOz/hJtG25tlldUQcyByegsgr1VJXXkcVP99DX8oAS8vVx3+KlXscxWrTEcKuLjuwpz3RY9wE97ahPWxz9H1v8Q9EMjA5AJG8ekdZlk456VtvVLg7vJgElw==; 5:sSZbc9h2ZLlRNHnJL2LizSdTOoMkY8cDLw/qF/5Awd0azlQHKI5rvuxyXwzrrHdqX2H7mokEFo/moM103DqV0ZiKSWiqkPX0iFd+47KkKX1UPPFV34im/ZipYQcBHYAMky1s1XNxj+dLDY0DGrr9qw==; 24:cFSlErOF2F83bbFeThLpfIY+9CYu0eIGBXdM3tistqAVfQj0vud8g0Rg6QCxCRNWn5ycNcq2CBj5qMygx4LKEd46eqC8/RUvM1mX24hG1W0=; 7:k28Abg4HfOFy9oSPBy+a8MopzjJ0trrgNZAnbSdDypcIhB278DZxkr/VTvoBjTGK7yGJ9+LmsDxi1CdKzBX6DHZHgRatdsQX/ppMhO2Pm0QGTVXznN4hUWq03qbXrDs2Dc1piIdUzGRZJwSMfoJSK3koL60WTGjSSlmP2QI8kkD+2LIJHb12PfgvAm1+eQGs1mV7zLNBOhpGED3vfzk4pA04U8y6d+ueQ54WsDT82Gw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 236d9699-23e5-444d-aa9c-08d50fd50ade x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(377454003)(32952001)(199003)(189002)(24454002)(106356001)(102836003)(6116002)(3846002)(97736004)(3280700002)(99286003)(6246003)(66066001)(9686003)(236005)(2501003)(790700001)(966005)(316002)(55016002)(105586002)(53946003)(110136005)(3660700001)(25786009)(2906002)(53936002)(6506006)(229853002)(80792005)(54896002)(77096006)(6306002)(6436002)(2201001)(68736007)(606006)(189998001)(101416001)(14454004)(86362001)(93886005)(74316002)(8676002)(81166006)(81156014)(8936002)(5660300001)(9326002)(2950100002)(2900100001)(33656002)(54356999)(7736002)(478600001)(53546010)(72206003)(50986999)(76176999)(7696004)(562404015)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178835555AFF5E39B4C44545EA750DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 11:50:02.6358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6117> : streams <1766640> : uri <2514239> Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 11:51:13 -0000 --_000_DM5PR16MB178835555AFF5E39B4C44545EA750DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kaname, Is the timeout 30 second fixed irrespective of incoming and outgoing traffi= c seen by the NAT ? Any specific reason for not following the recommendations given in RFC4787 = ? http://conferences.sigcomm.org/imc/2010/papers/p260.pdf shows different re= sults for only outbound traffic verses inbound and outbound traffic. -Tiru From: kaname nishizuka [mailto:kaname@nttv6.jp] Sent: Tuesday, October 10, 2017 9:02 AM To: Flemming Andreasen >; Kon= da, Tirumaleswar Reddy >; Jon Shallow >; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval I agree with Flemming's suggestion. Practically, the timeout will be set to ~30 seconds by operators like us. regards, kaname On 2017/10/10 1:35, Flemming Andreasen wrote: On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote: From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen Sent: Monday, October 9, 2017 9:12 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow = ; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. I'm getting different data-points for at least the minimum value. There sti= ll seems to be a lot of NATs out there with a timeout value of ~30 seconds = for UDP traffic (and in rare cases even lower), which suggests that a timeo= ut value slightly lower than 30 seconds is what you would want. Google did = a lot of testing around this and decided they were happy with the values in= https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds). Consent freshness has nothing to do with NAT/FW timeouts. You are missing the point Tiru - testing has been done (in the past and mor= e recently) and a value of ~30 seconds seems to be what works for the major= ity of devices. I'll trust Google on this one. -- Flemming -Tiru Thanks -- Flemming Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). 2) No, if the DOTS agent wants to change the default heartbeat interval the= n the other message transmission parameters will also have to be modified. 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_DM5PR16MB178835555AFF5E39B4C44545EA750DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kaname,

 

Is the timeout 30 second fixed irrespective of incoming and outgoin= g traffic seen by the NAT ?

Any specific reason for not following the recommendations given in = RFC4787 ?

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf  shows di= fferent results for only outbound traffic verses inbound and outbound traffic.

 

-Tiru

 

From: kaname nishizuka [mailto:ka= name@nttv6.jp]
Sent: Tuesday, October 10, 2017 9:02 AM
To: Flemming Andreasen <fan= dreas@cisco.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>= ;; Jon Shallow <supjps-ietf= @jpshallow.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 


I agree with Flemming's suggestion.
Practically, the timeout will be set to ~30 seconds by operators like us.
regards,
kaname

On 2017/10/10 1:35, Flemming Andreasen wrote:

 

On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote= :

From: Dots [mailto:dots-bounces@ietf.org<= span style=3D"color:windowtext;mso-fareast-language:ZH-CN">] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <Tirum= aleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

 

On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote:=

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.o= rg/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices= (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout val= ue observed when packets are exchanged b/w peers in both directions is 54 s= econds.

 

I'm getting differe= nt data-points for at least the minimum value. There still seems to be a lo= t of NATs out there with a timeout value of ~30 seconds for UDP traffic (an= d in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what you would want= . Google did a lot of testing around this and decided they were happy with = the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds).

 

Consent freshness has nothing to do with NAT/FW timeouts.

You are missing the p= oint Tiru - testing has been done (in the past and more recently) and a val= ue of ~30 seconds seems to be what works for the majority of devices. I'll trust Google on this one.

-- Flemming



 

-Tiru



Thanks

-- Flemming




Responses to the questions below

 

1) The max-retransmit parameter is negotiable and configurable,&nbs= p; DOTS agents can pick suitable values for max-retransmit parameter based = on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds). <= /o:p>

2) No, if the DOTS agent wants to change the default heartbeat inte= rval then the other message transmission parameters will also have to be mo= dified.

3) The client will have to assume the session is disconnected (see = the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.= 1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The he= artbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 

Med – In the below text, recommended value should be 93 secon= ds instead of 90 seconds (see https://tools.ietf.or= g/html/rfc7252#section-4.8.2).

 

-Tiru

 

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadair@orange.com; dots@ietf.org=
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

 <= /span>

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

 <= /span>

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

 <= /span>

Oct 04 10:53:51 DEBG sending CoAP ping:

Oct 04 10:53:51 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to retransmit queue= (2281ms)

Oct 04 10:53:51 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message 295= 48

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending CoAP ping:

Oct 04 10:54:07 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to retransmit queue= (2938ms)

Oct 04 10:54:07 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message 295= 49

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending CoAP ping:

Oct 04 10:54:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to retransmit queue= (2156ms)

Oct 04 10:54:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message 295= 50

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending CoAP ping:

Oct 04 10:54:39 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to retransmit queue= (2813ms)

Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #1=

Oct 04 10:54:42 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #2=

Oct 04 10:54:48 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #3=

Oct 04 10:55:00 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #4=

Oct 04 10:55:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up after 4 attempts=

 <= /span>

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

 <= /span>

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

 <= /span>

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

 <= /span>

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

 <= /span>

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Scenari= o as Q3

 <= /span>

Does th= e client re-use the old session that the heartbeats are failing on?<= o:p>

- The s= erver may have sent a session close, but it never got through

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

 <= /span>

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

 <= /span>

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

Regards=

 <= /span>

Jon

 <= /span>

From: Dots [mailto:ietf-supjps-dots-bounces@iet= f.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange= .com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com)
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during the int= erim meeting: “A: (Jon Shallo= w): The minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with = RFC8085 which says the following:

 

   An application that needs to employ keep-alive messages t=
o deliver
   useful service over UDP in the presence of middleboxes SH=
OULD NOT
           &nbs=
p;            &=
nbsp;           &nbs=
p;         ^^^^^^^^^^^^^^^^^^^^^^
   transmit them more frequently than once every 15 seconds =
and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^
   use longer intervals when possible.  

 


I suggest to add this NEW text to the signal-=
channel draft to clarify the rationale for the recommended values:



 


NEW:


  =
    Note: heartbeat-interval should be tweaked to also assis=
t DOTS


  =
   
messages for NAT traversal (SIG-010 of<=
span lang=3D"DA">


=
     
[I-D.ietf-dots-requirements]).  According to [RFC8085=
], keepalive


  =
    messages must not be sent more frequently than once ever=
y 15


  =
    seconds and should use longer intervals when possible.


  =
    Furthermore, [RFC4787] recommends NATs to use a state ti=
meout of 2


  =
    minutes or longer.  From that standpoint, this spec=
ification


  =
    recommends a minimum heartbeat-interval of 15 seconds an=
d a


  =
    maximum heartbeat-interval of 240 seconds.  The rec=
ommended value


  =
    of 90 seconds is selected to anticipate the expiry of NA=
T states,


  =
    while avoiding overloading the network with frequent kee=
palives


  =
    for NAT state maintenance purposes.  Note that this=
 recommended


  =
    value is close to the one recommended for MAX_TRANSMIT_W=
AIT, whose


  =
    value is derived from transmission parameters (Section 4=
.8.2 of


      [RFC7252]).=



 


Thoughts?



 


Cheers,


Med







_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.iet=
f.org/mailman/listinfo/dots

 <= /o:p>





_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.iet=
f.org/mailman/listinfo/dots

 

--_000_DM5PR16MB178835555AFF5E39B4C44545EA750DM5PR16MB1788namp_-- From nobody Tue Oct 10 04:53:19 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B060134D44 for ; Tue, 10 Oct 2017 04:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=mcafee.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 rSRTuDjdiieb for ; Tue, 10 Oct 2017 04:53:14 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 0517F134D2D for ; Tue, 10 Oct 2017 04:53:13 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507636378; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=l pON8PcvKZrQq3eGKvuhUQniqWlPPjr6DN1HKuMWPX Y=; b=logihMvzCZkhlCy4HI9NvYE6QQHhBLAWTlPcSbElFKkg bpv5ZBrGTfRo79xisF/igu2xA7xSgoTMTVvfzQOpVQDdnfvvKO vsTlEkoOAwtLPVYkT6eUdm0oYg89NTo2kHi66GxYndk1GPba1i /WdFR641Yq3jxRIy8HA4h4+QWXg= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c29_9955_ad5f0490_d17f_4964_a58b_9e5f01d83862; Tue, 10 Oct 2017 06:52:57 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 05:52:56 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Oct 2017 05:52:57 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 05:52:56 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 11:52:54 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 11:52:54 +0000 From: "Konda, Tirumaleswar Reddy" To: kaname nishizuka , Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAACzkMAABuu0fgAB0EBwAABJ3VIA== Date: Tue, 10 Oct 2017 11:52:54 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> In-Reply-To: <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:G6Z5a8rRJ2ZSbCXgT4r8B+8HBYUvLKUjRMB1BTpKl8HREG1dHC0uQirOCBEYkRvW4ODXLkCK46rT13h4RpEowSXd2HsGGLWGiNfHtInDZi50AorM1M7kAIZm4qAGSOG6Xkw2/mnHW7sYjN6lt46/9FGfTlt4TtgycAWZhUrjcj6IaLuqznZsUW7dxEGQAmIDDhBsd6zKNdL8axmu194ix6iF8jbfNcjo6fnJmz2TLFdtjTlxA15fIY46Y73CVLLQh/UWK8W4PQBrJNz/UJRnx4U9YbPWcVfX+Dm1t8T8dBIx2wp4B4scX21AA81uKN5NEc3GS9PklwW2NbW9nKNx/g==; 5:4i2WgWj8ro3MGSXk9NgaZniMs5Sg45xY42lj2f3SP4tjzEjwCDvV2XjE9dR+1nJXzbogMrgeAPvDEoj6er7l45W/syHERsMiPcIJKOO5Vu2zsztZ2ARwybsKmLFW3qoSDoC7mXpwNfr5yGKR1/WZCA==; 24:RsGqfntIAkH9hv5RduRKGyvuaSScP9m80RhcdYG2cXHmB6r1PP0V3vwCH1DhLw2gmBLW0CvlKfHQMAT0dFf2mLaEmwWl4tSs2viQeqfDRd4=; 7:vsgVOGwfGnZSXJ/TUy8VLgEoOCHMcVjc+DkcDR8vnsXakJFqLYbHNL/TGhSs//1pfrE7nXmdkwlocMsp9P7nvtTvsJU4rkRZXyWi3h55QoQsY1zst1prD+MauB475ZtcGciFBjPp8zoFOzP81+jstqnCe43sdaLPo1Eqa676EB0c8apljchAFq56+CZFlDFxVUYgWPPibAFGqSspRotRA7NnDJsZPCuSe+VznvW6QdY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8e4162cc-f522-460d-5860-08d50fd5714f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(377454003)(32952001)(51444003)(199003)(189002)(24454002)(106356001)(102836003)(6116002)(3846002)(97736004)(3280700002)(99286003)(6246003)(66066001)(9686003)(236005)(2501003)(790700001)(966005)(316002)(55016002)(105586002)(110136005)(3660700001)(25786009)(2906002)(53936002)(6506006)(229853002)(80792005)(54896002)(77096006)(6306002)(6436002)(2201001)(68736007)(606006)(189998001)(101416001)(14454004)(86362001)(93886005)(74316002)(8676002)(81166006)(81156014)(8936002)(5660300001)(9326002)(2950100002)(2900100001)(33656002)(54356999)(7736002)(478600001)(53546010)(72206003)(50986999)(76176999)(7696004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788D7BF49E78FD7F415137DEA750DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 11:52:54.2831 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6117> : streams <1766641> : uri <2514240> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 11:53:17 -0000 --_000_DM5PR16MB1788D7BF49E78FD7F415137DEA750DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2FuYW1lLA0KDQpQbGVhc2Ugc2VlIGlubGluZQ0KDQpGcm9tOiBEb3RzIFttYWlsdG86ZG90 cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yga2FuYW1lIG5pc2hpenVrYQ0KU2VudDog VHVlc2RheSwgT2N0b2JlciAxMCwgMjAxNyA4OjQ5IEFNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dh ciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGlydW1h bGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4+OyBKb24gU2hhbGxvdyA8c3VwanBzLWlldGZA anBzaGFsbG93LmNvbTxtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbT4+OyBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zIDxy ZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQpTdWJqZWN0OiBS ZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSwNCg0KPiBJIGFncmVlIHRo ZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJsZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBnYXRl d2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RT IHNlcnZlci4NCkkgYWdyZWUgd2l0aCB0aGlzIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBjYXNl Lg0KQXQgdGhlIHNhbWUgdGltZSwgSSBhZ3JlZSB3aXRoIGJlbG93Og0KPiBJIGFncmVlIHRoYXQg aXMgbm90IGEgZ29vZCB0aGluZyB0byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1hdGlv biB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR1csDQoNClRoZW4sIHNob3VsZCBET1RTIEdX IHNlbmQg4oCcY2xpZW50IGlkZW50aXR54oCdIChpLmUuIGNlcnRpZmljYXRlcyBvZiBET1RTIGNs aWVudHMpIGl0c2VsZiBvciBoYXNoZWQo4oCcY2xpZW50IGlkZW50aXR54oCdKSB0byBET1RTIHNl cnZlcj8NCklmIGxhdGVyLCBob3cgY2FuIERPVFMgc2VydmVyIHJlYWN0IHRvIHRoZSBhbWJpZ3Vv dXMgaW5mb3JtYXRpb24gb2YgdGhlIGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHnigJ0pLg0KW1RS XSBUaGUgRE9UUyBjbGllbnQgY2VydGlmaWNhdGUgbWF5IG5vdCBmaXQgd2l0aGluIHRoZSBwYXRo IE1UVS4gVGhlIGFsdGVybmF0aXZlIGFwcHJvYWNoIGlzLCB0aGUgc2VydmVyLXNpZGUgRE9UUyBH VyBjb21wdXRlcyBTSEEtMjU2IG9mIHRoZSBTdWJqZWN0IFB1YmxpYyBLZXkgSW5mbyAoU1BLSSkg b2YgdGhlIGNsaWVudCBjZXJ0aWZpY2F0ZSBhbmQgc2VuZCB0aGUgaGFzaGVkIG91dHB1dCB0byB0 aGUgRE9UUyBzZXJ2ZXIgaW4gdGhlIG5ldyBjbGllbnQtaWQgcGFyYW1ldGVyIChzZWUgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0Njkjc2VjdGlvbi0yLjQpLiBTSEEtMjU2IGlzIHJl c2lzdGFudCB0byBjb2xsaXNpb25zLiBGdXJ0aGVyLCBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkg YW5kIERPVFMgc2VydmVyIGFyZSBpbiB0aGUgc2FtZSBkb21haW4gb3BlcmF0aW5nIHRoZSBFU1Qg c2VydmVyLCBET1RTIGNsaWVudCB3aWxsIGJlIHVzaW5nIHRoZSBjZXJ0aWZpY2F0ZSBwcm92aXNp b25lZCBieSB0aGUgRVNUIHNlcnZlciB0byBhdXRoZW50aWNhdGUgaXRzZWxmIHRvIHRoZSBzZXJ2 ZXItc2lkZSBET1RTIGdhdGV3YXkgYW5kIEkgZG9u4oCZdCBzZWUgYW55IGFtYmlndW91cyBpbmZv cm1hdGlvbiBpbiB0aGUgaGFzaGVkIGNsaWVudCBpZGVudGl0eSBnZW5lcmF0ZWQgYW5kIGNvbnZl eWVkIGJ5IHRoZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgdG8gdGhlIERPVFMgc2VydmVyLg0K LVRpcnUNCg0KcmVnYXJkcywNCkthbmFtZQ0KDQoNCk9uIDIwMTcvMTAvMDkgMjI6MzQsIEtvbmRh LCBUaXJ1bWFsZXN3YXIgUmVkZHkgd3JvdGU6DQpIaSBKb24sDQoNCkkgYWdyZWUgdGhlIGJlbG93 IHByb2JsZW1zIGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0 IG11c3QgY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVy LiBCdXQgZm9yIHRoZSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksIGl0IHNob3VsZCByZXNvbHZl IGNvbmZsaWN0aW5nIHJ1bGVzIGIvdyBET1RTIGNsaWVudHMgKGUuZy4gb25lIGNsaWVudCBpbnN0 YWxsaW5nIGJsYWNrLWxpc3QgQUNMIGZvciBhbiBJUCBhZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xp ZW50IGluc3RhbGxzIHdoaXRlLWxpc3QgQUNMIGZvciB0aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1l IGFsaWFzLW5hbWVzIGZvciBkaWZmZXJlbnQgbWl0aWdhdGlvbiBzY29wZXMpLiBJIGRvbuKAmXQg c2VlIHRoZSBuZWVkIGZvciBhIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhl IOKAnGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IG9y IERPVFMgc2VydmVyLg0KDQotVGlydQ0KDQpGcm9tOiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpw cy1pZXRmQGpwc2hhbGxvdy5jb21dDQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3IDI6 MDcgUE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9L b25kYUBNY0FmZWUuY29tPjxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNv bT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5k IERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD48bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4N ClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUs DQoNClRoaXMgZGlzY3Vzc2lvbiBnb2VzIGJleW9uZCBqdXN0IHRoZSBtaXRpZ2F0aW9uIHJlcXVl c3QuICBXZSBuZWVkIHRvIGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3aXRoIGJvdGggYWxpYXMtbmFt ZSBhbmQgYWNsLW5hbWUgKGRhdGEgY2hhbm5lbCkNCg0KVGhlIHNpbXBsZSBjYXNlIG9mIGEgbWl0 aWdhdGlvbiByZXF1ZXN0IHdpdGggbm8gYWxpYXMtbmFtZSBkb2VzIG5vdCByZXF1aXJlIGFueSBr bm93bGVkZ2Ugb2YgdGhlIG9yaWdpbmFsIGNsaWVudC4NCg0KSG93ZXZlciwgaWYgdGhlIG1pdGln YXRpb24gcmVxdWVzdCB1c2VzIGFsaWFzLW5hbWUsIHRoZW4gdGhlcmUgYXJlIDMgd2F5cyBvZiBo YW5kbGluZyB0aGlzDQoNCmEpICAgICBUaGUgRE9UUyBHVyByZXBsYWNlcyB0aGUgYWxpYXMtbmFt ZSB3aXRoIGl0cyBhY3R1YWwgZGVmaW5pdGlvbiAodGFyZ2V0LWlwcyBldGMuIG1lcmdlZCBhcyBh cHByb3ByaWF0ZSksIHNvIGFsaWFzLW5hbWUgaXMgbm90IGZvcndhcmRlZCBvbiB0byBTZXJ2ZXIg 4oCTIGp1c3QgdGhlIGV4cGFuZGVkIG1pdGlnYXRpb24gcmVxdWVzdCBpcyBmb3J3YXJkZWQNCg0K YikgICAgVGhlIERPVFMgR1cgdXBkYXRlcyB0aGUgYWxpYXMtbmFtZSB3aXRoIGEgdW5pcXVlIGFs aWFzLW5hbWUgdGhhdCBpcyBmb3J3YXJkZWQgKGFuZCBoYXMgdG8gZG8gdGhlIHNhbWUgdGhpbmcg d2hlbiB0aGUgYWxpYXMtbmFtZSBpcyBjb25maWd1cmVkIG9uIHRoZSBkYXRhIGNoYW5uZWwpIOKA kyB0byBoYW5kbGUgMiBvciBtb3JlIGNsaWVudHMgZGVmaW5pbmcgdGhlIHNhbWUgYWxpYXMtbmFt ZSB3aGljaCBoYXZlIGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3MNCg0KYykgICAgIFRoZSBET1RT IEdXIHJlY29nbmlzZXMgdGhhdCBhbGlhcy1uYW1lIGlzIG5vdCB1bmlxdWUgYW5kIGFkZHMgaW4g 4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSAoSSB0aGluayBJIHByZWZlciB0aGlzIOKAnC1p bmZv4oCdIG5hbWUgdG8gY2xpZW50LWlkIG9yIG9yaWdpbmFsLWNsaWVudC1pZCBhcyDigJwtaWTi gJ0gaXMgdG9vIGNsb3NlbHkgIGFzc29jaWF0ZWQgd2l0aCBDbGllbnQgSWRlbnRpdHkgZGVyaXZl ZCBmcm9tIHRoZSBET1RTIEdXIENsaWVudCBjZXJ0aWZpY2F0ZSkNCldlIGhhdmUgYWdyZWVkIHRo YXQgd2hlbiBhIGNsaWVudCByZXF1ZXN0cyBtaXRpZ2F0aW9uIHN0YXR1cywgdGhlIOKAnGFsaWFz LW5hbWXigJ0gc2hvdWxkIGJlIHJldHVybmVkIGFzIOKAnGFsaWFzLW5hbWXigJ0gYW5kIG5vdCB0 aGUgc3Vic3RpdHV0ZWQgYWxpYXMtbmFtZSBjb25maWd1cmF0aW9uICh0aGlzIGRvZXMgbmVlZCB0 byBiZSBzdGF0ZWQgaW4gdGhlIHNwZWMgZm9yIGNsYXJpdHkpLiAgVGhpcyBtYWtlcyAoYSkgZGlm ZmljdWx0IHRvIGJlIGhhbmRsZWQgYnkgRE9UUyBHVyB3aGljaCB0aGVuIHJhaXNlcyB0aGUgcXVl c3Rpb24g4oCTIGRvIHdlIHJlYWxseSBuZWVkIGFsaWFzLW5hbWU/DQoNClRoZSBkZWZpbml0aW9u IGFuZCBhc3NvY2lhdGlvbiBvZiBBQ0xzL0ZpbHRlcnMgb2YgdGhlIGRhdGEgY2hhbm5lbCBpcyBt b3JlIGRpZmZpY3VsdCDigJMgdGhlIFNlcnZlciBtdXN0IGluc3RhbGwgLyBhcHBseSB0aGUgYXBw cm9wcmlhdGUgQUNMcyBvbiBhIHBlciAoT3JpZ2luYWwpIENsaWVudCBiYXNpcyB3aGVuIG1pdGln YXRpb24gaXMgaW52b2tlZC4NCkNsaWVudCAx4oCZcyBjb25jZXB0IG9mIGEgV2hpdGVsaXN0IElQ IGNvdWxkIGJlIENsaWVudCAy4oCZcyBjb25jZXB0IG9mIGEgQmxhY2tsaXN0IElQLiAgVGhlIFNl cnZlciBuZWVkcyB0byBrbm93IHdoaWNoIGNsaWVudCBpcyByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0 aW9uIGFuZCBpbnN0YWxsIHRoZSBjb3JyZWN0IEFDTHMg4oCTIGlmIHRoZXJlIHdhcyBubyDigJ1h ZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdLCB0aGUgU2VydmVyIG9ubHkga25vd3MgdGhhdCBoZSBo YXMgdG8gaW5zdGFsbCBBTEwgb2YgdGhlIEFDTHMgKGkuZS4gYm90aCB0aGUgQmxhY2sgYW5kIFdo aXRlIGxpc3Qgb2YgdGhlIHNhbWUgSVAgYXMgZGVmaW5lZCBieSBDbGllbnQgMSBhbmQgQ2xpZW50 IDIpIGFzIGRlZmluZWQgYnkgaGlzIGNsaWVudCAoRE9UUyBHVykgd2hlbiBoaXMgY2xpZW50IHJl cXVlc3RzIGEgbWl0aWdhdGlvbi4gIEhlcmUsIEkgdGhpbmsgdGhhdCBpZiB0aGVyZSBpcyBtb3Jl IHRoYW4gb25lIGNsaWVudCBmb3IgdGhlIERPVFMgR1csIOKAnWFkZGl0aW9uYWwtY2xpZW50LWlu Zm/igJ0gaXMgcmVxdWlyZWQuDQoNClJlZ2FyZHMNCg0KSm9uDQoNCkZyb206IERvdHMgW21haWx0 bzogZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KU2VudDogMDcgT2N0b2JlciAy MDE3IDA0OjI4DQpUbzogSm9uIFNoYWxsb3c7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0 bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMNClN1YmplY3Q6IFJlOiBbRG90c10gRE9U UyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkluIGNhc2Ugb2YgY2xpZW50LXNpZGUgRE9UUyBnYXRl d2F5LCB3aHkgZG9lcyB0aGUgRE9UUyBzZXJ2ZXIgbmVlZCB0byBrbm93IHdoaWNoIOKAnERPVFMg Y2xpZW504oCdIGhhcyBjb252ZXllZCB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0ID8NCkZvciBleGFt cGxlLCB0aGUgRE9UUyBjbGllbnQgY291bGQgYmUgYSBERG9TIGRldGVjdG9yIG9yIGFuIEFwcGxp Y2F0aW9uIHNlcnZlciwgYW5kIHRoZSBjbGllbnQtc2lkZSBnYXRld2F5IHdpbGwgaGF2ZSB0byBy ZXNvbHZlIHRoZSBjb25mbGljdGluZyBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMg Y2xpZW50cywgYWdncmVnYXRlIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMg Y2xpZW50IGFuZCBzZW5kIHRoZSB1cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUgRE9U UyBzZXJ2ZXIuDQoNCi1UaXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWll dGZAanBzaGFsbG93LmNvbV0NClNlbnQ6IEZyaWRheSwgT2N0b2JlciA2LCAyMDE3IDc6NDIgUE0N ClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBN Y0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPj47IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJp bnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pj4NClN1Ympl Y3Q6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUsDQoNClVu bGVzcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBob3cgZG9lcyB0aGUgQ2xpZW50IHNpZGUgb2Yg RE9UUyBHVyBjb252ZXkgdG8gdGhlIHVwc3RyZWFtIHNlcnZlciBhIHVuaXF1ZSDigJxjbGllbnQt aWTigJ0gd2hpY2ggaXMgZGlmZmVyZW50IHRvIHRoZSBpbXBsaWVkIGNsaWVudCBpZCBhcyBkZXJp dmVkIGZyb20gdGhlIFBLSSBjZXJ0aWZpY2F0ZSB0aGF0IHRoZSBET1RTIEdX4oCZQ2xpZW50IHVz ZXMvcHJlc2VudHMgd2hlbiBjb21tdW5pY2F0aW5nIHRvIHRoZSBzZXJ2ZXI/DQpUbyBtZSwgdGhl cmUgbmVlZHMgdG8gYmUgYW4gb3B0aW9uIHN1Y2ggYXMg4oCcb3JpZ2luYWwtY2xpZW50LWlk4oCd IG9yIOKAnGNsaWVudC1pZOKAnSAod2hpY2ggaXMgY29uZnVzaW5nIHdoZW4gYWxzbyByZWZlcnJp bmcgdG8gdGhlIGNsaWVudCBpZGVudGl0eSBhcyBkZXJpdmVkIGZyb20gdGhlIChET1RTIEdXKSBD bGllbnTigJlzIFBLSSBjZXJ0aWZpY2F0ZSkgYXMgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbC4NCg0K SSBhZ3JlZSB0aGF0IHRoZSBET1RTIEdXIGNhbiBnZW5lcmF0ZSBpdHMgb3duIHVuaXF1ZSBjbGll bnQtaWQgdG8gc3RvcCBtdWx0aXBsZSBlbnRyaWVzIGJlaW5nIG5lZWRlZC4NCg0KSSBhZ3JlZSB0 aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5mb3Jt YXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLCBzbyBteSBSRVFVSVJFRCBkb2Vz IG5vdCBtYWtlIHNlbnNlLg0KDQpSZWdhcmRzDQoNCkpvbg0KUFMg4oCTIEkgYW0gaGF2aW5nIHRv IGRlYWwgd2l0aCBvdGhlciBzdHVmZiBhdCBwcmVzZW50IOKAkyBJIHdpbGwgZ2V0IGJhY2sgbGF0 ZXIgb24gdGhlIG90aGVyIGlzc3VlcyB1bmRlciBkaXNjdXNzaW9uDQoNCkZyb206IEtvbmRhLCBU aXJ1bWFsZXN3YXIgUmVkZHkgW21haWx0bzogVGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVl LmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbT5dDQpTZW50OiAw NiBPY3RvYmVyIDIwMTcgMTQ6NTgNClRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgSm9uIFNoYWxsb3c7ICdEb2JiaW5z LCBSb2xhbmQnOyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDog UkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSSBkb27igJl0IHNlZSBhIG5l ZWQgZm9yIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKAnERPVFMgY2xp ZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4g4oCcRE9UUyBjbGllbnQgaWRlbnRp dHnigJ0gbG9va3MgcmVxdWlyZWQgb25seSBmb3IgdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdh eXMuIEluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5IHRo ZSBjbGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCd IHRvIHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1bmlx dWUgY2xpZW50LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4gYXJyYXkgb2YgY2xpZW50 LWlkcyB0byB0aGUgRE9UUyBzZXJ2ZXIgdG8gcmVzb2x2ZSBjbGFzaGVzLg0KDQotVGlydQ0KDQoN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpE b3RzIG1haWxpbmcgbGlzdA0KDQpEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGlldGYub3JnPg0K DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg0K --_000_DM5PR16MB1788D7BF49E78FD7F415137DEA750DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ cGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQg MiAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjsNCgljb2xvcjpi bGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiU2Vnb2UgVUkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1 bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpwLlRleHRlZGVidWxs ZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJe21zby1zdHlsZS1uYW1l OiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHls ZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MTIwNjIxNzg3MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6MjA4OTM1NDE2IDEzNDgwNzU3NSAxMzQ4MDc1NzcgMTM0ODA3NTc5 IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3 NTc5O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij5IaSBLYW5hbWUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij5QbGVhc2Ugc2VlIGlubGluZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+ DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gRG90cyBb PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+a2FuYW1lIG5pc2hp enVrYTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDEwLCAyMDE3IDg6NDkgQU08 YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0Ozwvc3Bhbj48YSBo cmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jmd0OzsNCiBKb24gU2hhbGxvdyAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij4mZ3Q7Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij47 DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ ZG90c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi PjsgUm9sYW5kIERvYmJpbnMgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJi b3IubmV0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnJkb2JiaW5zQGFyYm9yLm5ldDwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhp LDxicj4NCjxicj4NCiZndDsgSSBhZ3JlZSB0aGUgYmVsb3cgcHJvYmxlbXMgYXJlIGFwcGxpY2Fi bGUgZm9yIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgbXVzdCBjb252ZXkgdGhlIOKAnGNs aWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuDQo8YnI+DQpJIGFncmVlIHdpdGgg dGhpcyBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgY2FzZS48YnI+DQpBdCB0aGUgc2FtZSB0aW1l LCBJIGFncmVlIHdpdGggYmVsb3c6PGJyPg0KJmd0OyBJIGFncmVlIHRoYXQgaXMgbm90IGEgZ29v ZCB0aGluZyB0byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1hdGlvbiB3aGVuIHBhc3Np bmcgdGhyb3VnaCBhIERPVFMgR1csDQo8YnI+DQo8YnI+DQpUaGVuLCBzaG91bGQgRE9UUyBHVyBz ZW5kIOKAnGNsaWVudCBpZGVudGl0eeKAnSAoaS5lLiBjZXJ0aWZpY2F0ZXMgb2YgRE9UUyBjbGll bnRzKSBpdHNlbGYgb3IgaGFzaGVkKOKAnGNsaWVudCBpZGVudGl0eeKAnSkgdG8gRE9UUyBzZXJ2 ZXI/PGJyPg0KSWYgbGF0ZXIsIGhvdyBjYW4gRE9UUyBzZXJ2ZXIgcmVhY3QgdG8gdGhlIGFtYmln dW91cyBpbmZvcm1hdGlvbiBvZiB0aGUgaGFzaGVkKOKAnGNsaWVudCBpZGVudGl0eeKAnSkuPHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPltUUl0gVGhlIERPVFMgY2xpZW50IGNlcnRpZmljYXRlIG1heSBu b3QgZml0IHdpdGhpbiB0aGUgcGF0aCBNVFUuIFRoZSBhbHRlcm5hdGl2ZSBhcHByb2FjaCBpcywg dGhlIHNlcnZlci1zaWRlIERPVFMgR1cgY29tcHV0ZXMgU0hBLTI1NiBvZiB0aGUgU3ViamVjdCBQ dWJsaWMgS2V5IEluZm8gKFNQS0kpIG9mDQogdGhlIGNsaWVudCBjZXJ0aWZpY2F0ZSBhbmQgc2Vu ZCB0aGUgaGFzaGVkIG91dHB1dCB0byB0aGUgRE9UUyBzZXJ2ZXIgaW4gdGhlIG5ldyBjbGllbnQt aWQgcGFyYW1ldGVyIChzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0Njkjc2Vj dGlvbi0yLjQpLiBTSEEtMjU2IGlzIHJlc2lzdGFudCB0byBjb2xsaXNpb25zLiBGdXJ0aGVyLCBz ZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgYW5kIERPVFMgc2VydmVyIGFyZSBpbiB0aGUgc2FtZQ0K IGRvbWFpbiBvcGVyYXRpbmcgdGhlIEVTVCBzZXJ2ZXIsIERPVFMgY2xpZW50IHdpbGwgYmUgdXNp bmcgdGhlIGNlcnRpZmljYXRlIHByb3Zpc2lvbmVkIGJ5IHRoZSBFU1Qgc2VydmVyIHRvIGF1dGhl bnRpY2F0ZSBpdHNlbGYgdG8gdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBhbmQgSSBkb27i gJl0IHNlZSBhbnkgYW1iaWd1b3VzIGluZm9ybWF0aW9uIGluIHRoZSBoYXNoZWQgY2xpZW50IGlk ZW50aXR5IGdlbmVyYXRlZCBhbmQgY29udmV5ZWQgYnkNCiB0aGUgc2VydmVyLXNpZGUgRE9UUyBn YXRld2F5IHRvIHRoZSBET1RTIHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0Ij4tVGlydTwvc3Bhbj48YnI+DQo8YnI+DQpyZWdhcmRzLDxicj4NCkth bmFtZTxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjAxNy8x MC8wOSAyMjozNCwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEpv biw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+SSBhZ3JlZSB0aGUgYmVsb3cgcHJvYmxlbXMgYXJlIGFwcGxpY2Fi bGUgZm9yIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgbXVzdCBjb252ZXkgdGhlIOKAnGNs aWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIEJ1dCBmb3IgdGhlIGNsaWVudC1z aWRlIERPVFMgZ2F0ZXdheSwgaXQgc2hvdWxkDQogcmVzb2x2ZSBjb25mbGljdGluZyBydWxlcyBi L3cgRE9UUyBjbGllbnRzIChlLmcuIG9uZSBjbGllbnQgaW5zdGFsbGluZyBibGFjay1saXN0IEFD TCBmb3IgYW4gSVAgYWRkcmVzcyBidXQgdGhlIG90aGVyIGNsaWVudCBpbnN0YWxscyB3aGl0ZS1s aXN0IEFDTCBmb3IgdGhlIHNhbWUgSVAgYWRkcmVzcywgc2FtZSBhbGlhcy1uYW1lcyBmb3IgZGlm ZmVyZW50IG1pdGlnYXRpb24gc2NvcGVzKS4gSSBkb27igJl0IHNlZSB0aGUgbmVlZCBmb3IgYSBj bGllbnQtc2lkZQ0KIERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKAnGNsaWVudCBpZGVudGl0 eeKAnSB0byB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IG9yIERPVFMgc2VydmVyLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4tVGlydTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBKb24gU2hhbGxvdyBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzdXBqcHMt aWV0ZkBqcHNoYWxsb3cuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPm1haWx0bzpzdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3IDI6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IEtv bmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDtUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tJmd0Ozwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj47 DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj47DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+ZG90c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj47 IFJvbGFuZCBEb2JiaW5zDQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5l dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbHQ7cmRvYmJpbnNAYXJib3IubmV0Jmd0Ozwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdh dGV3YXlzIENoYWxsZW5nZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRp cnUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoaXMgZGlzY3Vzc2lvbiBnb2VzIGJleW9uZCBqdXN0IHRoZSBtaXRp Z2F0aW9uIHJlcXVlc3QuJm5ic3A7IFdlIG5lZWQgdG8gY29uc2lkZXIgd2hhdCBoYXBwZW5zIHdp dGggYm90aCBhbGlhcy1uYW1lIGFuZCBhY2wtbmFtZSAoZGF0YSBjaGFubmVsKTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5UaGUgc2ltcGxlIGNhc2Ugb2YgYSBtaXRpZ2F0aW9uIHJlcXVlc3Qgd2l0aCBubyBhbGlhcy1u YW1lIGRvZXMgbm90IHJlcXVpcmUgYW55IGtub3dsZWRnZSBvZiB0aGUgb3JpZ2luYWwgY2xpZW50 LiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIGlmIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3Qg dXNlcyBhbGlhcy1uYW1lLCB0aGVuIHRoZXJlIGFyZSAzIHdheXMgb2YgaGFuZGxpbmcgdGhpczwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hKTxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIERPVFMgR1cgcmVwbGFj ZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBpdHMgYWN0dWFsIGRlZmluaXRpb24gKHRhcmdldC1pcHMg ZXRjLiBtZXJnZWQgYXMgYXBwcm9wcmlhdGUpLCBzbyBhbGlhcy1uYW1lIGlzDQogbm90IGZvcndh cmRlZCBvbiB0byBTZXJ2ZXIg4oCTIGp1c3QgdGhlIGV4cGFuZGVkIG1pdGlnYXRpb24gcmVxdWVz dCBpcyBmb3J3YXJkZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yik8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RT IEdXIHVwZGF0ZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBhIHVuaXF1ZSBhbGlhcy1uYW1lIHRoYXQg aXMgZm9yd2FyZGVkIChhbmQgaGFzIHRvIGRvIHRoZSBzYW1lIHRoaW5nIHdoZW4gdGhlIGFsaWFz LW5hbWUNCiBpcyBjb25maWd1cmVkIG9uIHRoZSBkYXRhIGNoYW5uZWwpIOKAkyB0byBoYW5kbGUg MiBvciBtb3JlIGNsaWVudHMgZGVmaW5pbmcgdGhlIHNhbWUgYWxpYXMtbmFtZSB3aGljaCBoYXZl IGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+Yyk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoZSBET1RTIEdXIHJlY29nbmlzZXMgdGhhdCBhbGlhcy1uYW1lIGlzIG5vdCB1 bmlxdWUgYW5kIGFkZHMgaW4g4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSAoSSB0aGluayBJ IHByZWZlciB0aGlzIOKAnC1pbmZv4oCdDQogbmFtZSB0byBjbGllbnQtaWQgb3Igb3JpZ2luYWwt Y2xpZW50LWlkIGFzIOKAnC1pZOKAnSBpcyB0b28gY2xvc2VseSAmbmJzcDthc3NvY2lhdGVkIHdp dGggQ2xpZW50IElkZW50aXR5IGRlcml2ZWQgZnJvbSB0aGUgRE9UUyBHVyBDbGllbnQgY2VydGlm aWNhdGUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XZSBoYXZlIGFncmVlZCB0aGF0 IHdoZW4gYSBjbGllbnQgcmVxdWVzdHMgbWl0aWdhdGlvbiBzdGF0dXMsIHRoZSDigJxhbGlhcy1u YW1l4oCdIHNob3VsZCBiZSByZXR1cm5lZCBhcyDigJxhbGlhcy1uYW1l4oCdIGFuZCBub3QgdGhl IHN1YnN0aXR1dGVkIGFsaWFzLW5hbWUNCiBjb25maWd1cmF0aW9uICh0aGlzIGRvZXMgbmVlZCB0 byBiZSBzdGF0ZWQgaW4gdGhlIHNwZWMgZm9yIGNsYXJpdHkpLiZuYnNwOyBUaGlzIG1ha2VzIChh KSBkaWZmaWN1bHQgdG8gYmUgaGFuZGxlZCBieSBET1RTIEdXIHdoaWNoIHRoZW4gcmFpc2VzIHRo ZSBxdWVzdGlvbiDigJMgZG8gd2UgcmVhbGx5IG5lZWQgYWxpYXMtbmFtZT88L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhlIGRlZmluaXRpb24gYW5kIGFzc29jaWF0aW9uIG9mIEFDTHMvRmlsdGVycyBvZiB0aGUgZGF0 YSBjaGFubmVsIGlzIG1vcmUgZGlmZmljdWx0IOKAkyB0aGUgU2VydmVyIG11c3QgaW5zdGFsbCAv IGFwcGx5IHRoZSBhcHByb3ByaWF0ZSBBQ0xzIG9uIGENCiBwZXIgKE9yaWdpbmFsKSBDbGllbnQg YmFzaXMgd2hlbiBtaXRpZ2F0aW9uIGlzIGludm9rZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5DbGllbnQgMeKAmXMgY29uY2VwdCBvZiBhIFdoaXRlbGlzdCBJUCBjb3VsZCBiZSBD bGllbnQgMuKAmXMgY29uY2VwdCBvZiBhIEJsYWNrbGlzdCBJUC4mbmJzcDsgVGhlIFNlcnZlciBu ZWVkcyB0byBrbm93IHdoaWNoIGNsaWVudCBpcyByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uDQog YW5kIGluc3RhbGwgdGhlIGNvcnJlY3QgQUNMcyDigJMgaWYgdGhlcmUgd2FzIG5vIOKAnWFkZGl0 aW9uYWwtY2xpZW50LWluZm/igJ0sIHRoZSBTZXJ2ZXIgb25seSBrbm93cyB0aGF0IGhlIGhhcyB0 byBpbnN0YWxsIEFMTCBvZiB0aGUgQUNMcyAoaS5lLiBib3RoIHRoZSBCbGFjayBhbmQgV2hpdGUg bGlzdCBvZiB0aGUgc2FtZSBJUCBhcyBkZWZpbmVkIGJ5IENsaWVudCAxIGFuZCBDbGllbnQgMikg YXMgZGVmaW5lZCBieSBoaXMgY2xpZW50IChET1RTIEdXKQ0KIHdoZW4gaGlzIGNsaWVudCByZXF1 ZXN0cyBhIG1pdGlnYXRpb24uJm5ic3A7IEhlcmUsIEkgdGhpbmsgdGhhdCBpZiB0aGVyZSBpcyBt b3JlIHRoYW4gb25lIGNsaWVudCBmb3IgdGhlIERPVFMgR1csIOKAnWFkZGl0aW9uYWwtY2xpZW50 LWluZm/igJ0gaXMgcmVxdWlyZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IERv dHMgW21haWx0bzoNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZiI+ZG90cy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZiI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Lb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5 PGJyPg0KPGI+U2VudDo8L2I+IDA3IE9jdG9iZXIgMjAxNyAwNDoyODxicj4NCjxiPlRvOjwvYj4g Sm9uIFNoYWxsb3c7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OyxzYW5zLXNlcmlmIj47DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OyxzYW5zLXNlcmlmIj5kb3RzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZiI+OyBSb2xhbmQgRG9iYmluczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNdIERP VFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J biBjYXNlIG9mIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgd2h5IGRvZXMgdGhlIERPVFMgc2Vy dmVyIG5lZWQgdG8ga25vdyB3aGljaCDigJxET1RTIGNsaWVudOKAnSBoYXMgY29udmV5ZWQgdGhl IG1pdGlnYXRpb24gcmVxdWVzdCA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgZXhhbXBsZSwgdGhlIERPVFMgY2xpZW50IGNv dWxkIGJlIGEgRERvUyBkZXRlY3RvciBvciBhbiBBcHBsaWNhdGlvbiBzZXJ2ZXIsIGFuZCB0aGUg Y2xpZW50LXNpZGUgZ2F0ZXdheSB3aWxsIGhhdmUgdG8gcmVzb2x2ZSB0aGUgY29uZmxpY3Rpbmcg bWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIHRoZQ0KIERPVFMgY2xpZW50cywgYWdncmVnYXRlIHRo ZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50IGFuZCBzZW5kIHRoZSB1 cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPi1UaXJ1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IEpvbiBTaGFsbG93IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpw c2hhbGxvdy5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxv dy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgT2N0b2JlciA2LCAyMDE3IDc6NDIgUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaXJ1bWFsZXN3YXJSZWRkeV9L b25kYUBNY0FmZWUuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7DQo8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj47DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+ZG90c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj47IFJvbGFuZCBE b2JiaW5zICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5yZG9iYmluc0BhcmJvci5uZXQ8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hh bGxlbmdlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgVGlydSw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VW5sZXNzIEkgYW0gbWlzc2luZyBzb21ldGhpbmcsIGhvdyBkb2VzIHRoZSBDbGllbnQg c2lkZSBvZiBET1RTIEdXIGNvbnZleSB0byB0aGUgdXBzdHJlYW0gc2VydmVyIGEgdW5pcXVlIOKA nGNsaWVudC1pZOKAnSB3aGljaCBpcyBkaWZmZXJlbnQgdG8gdGhlIGltcGxpZWQNCiBjbGllbnQg aWQgYXMgZGVyaXZlZCBmcm9tIHRoZSBQS0kgY2VydGlmaWNhdGUgdGhhdCB0aGUgRE9UUyBHV+KA mUNsaWVudCB1c2VzL3ByZXNlbnRzIHdoZW4gY29tbXVuaWNhdGluZyB0byB0aGUgc2VydmVyPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG8gbWUsIHRoZXJlIG5lZWRzIHRvIGJlIGFu IG9wdGlvbiBzdWNoIGFzIOKAnG9yaWdpbmFsLWNsaWVudC1pZOKAnSBvciDigJxjbGllbnQtaWTi gJ0gKHdoaWNoIGlzIGNvbmZ1c2luZyB3aGVuIGFsc28gcmVmZXJyaW5nIHRvIHRoZSBjbGllbnQg aWRlbnRpdHkgYXMNCiBkZXJpdmVkIGZyb20gdGhlIChET1RTIEdXKSBDbGllbnTigJlzIFBLSSBj ZXJ0aWZpY2F0ZSkgYXMgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3Jl ZSB0aGF0IHRoZSBET1RTIEdXIGNhbiBnZW5lcmF0ZSBpdHMgb3duIHVuaXF1ZSBjbGllbnQtaWQg dG8gc3RvcCBtdWx0aXBsZSBlbnRyaWVzIGJlaW5nIG5lZWRlZC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3Jl ZSB0aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5m b3JtYXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLCBzbyBteSBSRVFVSVJFRCBk b2VzIG5vdCBtYWtlIHNlbnNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpvbjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UFMg4oCTIEkgYW0gaGF2aW5nIHRvIGRlYWwg d2l0aCBvdGhlciBzdHVmZiBhdCBwcmVzZW50IOKAkyBJIHdpbGwgZ2V0IGJhY2sgbGF0ZXIgb24g dGhlIG90aGVyIGlzc3VlcyB1bmRlciBkaXNjdXNzaW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkg W21haWx0bzoNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFA bWNhZmVlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQG1jYWZl ZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDYg T2N0b2JlciAyMDE3IDE0OjU4PGJyPg0KPGI+VG86PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5tb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+OyBKb24gU2hhbGxv dzsgJ0RvYmJpbnMsIFJvbGFuZCc7DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmIj5kb3RzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp ZiI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVu Z2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBzZWUgYSBuZWVk IGZvciBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgdG8gY29udmV5IHRoZSDigJxET1RTIGNsaWVu dCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIOKAnERPVFMgY2xpZW50IGlkZW50aXR5 4oCdIGxvb2tzIHJlcXVpcmVkIG9ubHkgZm9yIHRoZSBzZXJ2ZXItc2lkZSBET1RTDQogZ2F0ZXdh eXMuIEluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5IHRo ZSBjbGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCd IHRvIHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1bmlx dWUgY2xpZW50LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4gYXJyYXkgb2YgY2xpZW50 LWlkcyB0byB0aGUgRE9UUyBzZXJ2ZXIgdG8NCiByZXNvbHZlIGNsYXNoZXMuIDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+LVRpcnU8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJGUiI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3Bh biBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkRvdHMgbWFp bGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpE b3RzQGlldGYub3JnIj48c3BhbiBsYW5nPSJGUiI+RG90c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMiPjxzcGFuIGxhbmc9IkZSIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8L3NwYW4+PC9hPjxzcGFu IGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB1788D7BF49E78FD7F415137DEA750DM5PR16MB1788namp_-- From nobody Tue Oct 10 05:02:59 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B57134D87 for ; Tue, 10 Oct 2017 05:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=mcafee.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 BbEDoxwutG6i for ; Tue, 10 Oct 2017 05:02:52 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 E3533134D86 for ; Tue, 10 Oct 2017 05:02:50 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507636963; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=L tH6kMj6F3cEEITEQszR9fdFw27odIgd7dU0Zs8oNO s=; b=GC+KQKNBC4m9uiWnyc1dO2arW4EDbT0BHu+xTDe3UoEG YhBy69aetSm8QgUA98PZTuoOORjIVcRjuiwN/lYDaSLn5e1S61 ZabDYyokaEQB4zqGBdimj+wE0R0P7XUkTtvdA9itzHmjplVGx5 YfM+LmaXm0dIM5eCLyHpLxA9GrA= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c07_a08d_8971cd94_16bd_40ea_9e81_fa214d71eb06; Tue, 10 Oct 2017 07:02:41 -0500 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 06:02:39 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 06:02:38 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Oct 2017 06:02:37 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 06:02:37 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 12:02:35 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 12:02:35 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , 'kaname nishizuka' , "mohamed.boucadair@orange.com" , 'Flemming Andreasen' , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AdM866F1exiXOD0RS+2TvvngfvHPNAAHYE+AAC3w14AA1RHAgAAAO8mwAAGjSgAAFud1gAAMBa+AAAWJ4GA= Date: Tue, 10 Oct 2017 12:02:35 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com> <4406f5bc-60ea-96dc-d74b-a74430b83285@nttv6.jp> <0cc001d341a8$5e8238a0$1b86a9e0$@jpshallow.com> In-Reply-To: <0cc001d341a8$5e8238a0$1b86a9e0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:fTmDYvI1KKcC8xZjb+Ir0yVG4KY6Qe6g5HyIYmks8Q8gfkgRQxTwmzXOfqCtwtwY3iW5bZ8ZRBb9x9gY5ZA9mdymreGVLwyniXuu7RObosjN1rjLYcuMxo1peLE5mX/OJaBWJXZAf/jNuApAA4Jkc+p0ePcbdMuCzjB+AV+pySbLLqt9MHRj+v498DzQ6x22ugjQDXc/Hqpqpk/bP8eBOrGJGv4brfslOZNOa9tufJ0Av+TtY6IOrBU7U4h9OGhqZsQxvw//Snlo53pIQSwjeqUh3oQ4H2RtErpy47wA8FwFE9njErhIXV6h6GYAWcInwg1qq1YZtgR6CUAq+2d8Hw==; 5:V5y2LhIvT3wCcrNa1USbi2Sjh5yX3CL14GYfl0RY5CS7ZeHwHWRwE6kmEg9nJfxaEA31SF6DoJ85m98x+itDbB+6XWr5fthRaQ0e7xtO1fnykl/5p0dUyg1vs9XIGGezePERWijyxzlJXb5sxvcc2w==; 24:Ot40yq0VXR14hGlkjIKAJuY3S1dUdHHJ+sZmHRmsKIy7d4O/mGmxt7Az78FYgjxdt3CxlFAGNOr1+MD/NmMxrwC1V9oJqFMLP2VpYxm97Z0=; 7:Ks9ShnhlddjXae4W49Pcinx4h82CVQXplQRUzeiHCNQhOdDO3y++qru3Q0rGZXVYPYTy91UJid6JP3r8aZmN8YzVuC+o1ipMg/3F5qRhnQpYlh+OmGXUBB5Fb8bEU6c9bSpzZi+QiKHljfZt/CDugi8keJzYMfjHQMTYnSY0AYRLCs2m05joAE7XTh7wHxAWuu4KPW05xTmXitICFV18T2n7DGvy/2YJbT0eJ81dt74= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d1a1b830-65dc-4e30-f56a-08d50fd6cb67 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(189002)(24454002)(32952001)(377454003)(199003)(51444003)(53546010)(236005)(93886005)(2906002)(5660300001)(68736007)(189998001)(33656002)(6436002)(790700001)(102836003)(6116002)(7736002)(3846002)(2950100002)(316002)(606006)(14454004)(53936002)(110136005)(55016002)(99286003)(7696004)(86362001)(53946003)(6246003)(9686003)(54896002)(6306002)(966005)(76176999)(2900100001)(3660700001)(25786009)(66066001)(101416001)(50986999)(72206003)(478600001)(80792005)(2501003)(97736004)(54356999)(77096006)(6506006)(229853002)(74316002)(106356001)(8936002)(3280700002)(81156014)(81166006)(8676002)(105586002)(562404015)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788ECEF23B6A0BDE222F73EEA750DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 12:02:35.1705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6117> : streams <1766642> : uri <2514243> Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 12:02:56 -0000 --_000_DM5PR16MB1788ECEF23B6A0BDE222F73EEA750DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, October 10, 2017 2:46 PM To: 'kaname nishizuka' ; Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; 'Flemming Andr= easen' ; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval I also agree - my experience since the 80's is a (firewall/NAT) UDP session= timeout value default of 30 seconds - RFC4787 came out some 20 years later= in 2007. The "heartbeat-interval" needs to be retained - with a minimum value of les= s than 30 seconds (perhaps 15 seconds) so that DOTS signal will work throug= h (?broken?) firewalls/NAT devices that maintain some sort of state. Even = if the heartbeat is every 30 seconds, this is a packet of less than 100 byt= es every 30 seconds - this is not going to add to a DDoS situation. I think that text similar to the following also needs to be added "A heartbeat is not allowed to be transmitted while a previous heartbeat ha= s not been responded to - which could be longer than the heartbeat interval= if there is packet loss and could be up to MAX_TRANSMIT_WAIT (RFC7252) sec= onds. If MAX_TRANSMIT_WAIT is greater than the heartbeat interval and the = previous heartbeat has had no response, then the next heartbeat should be s= ent as soon as possible. Otherwise heartbeats should be sent no more frequ= ently than the heartbeat interval." [TR] I don't think the above logic addresses the 30 second NAT/FW idle time= out problem, the recommended default max-retransmit has to be reduced to 2 = to get a MAX_TRANSMIT_WAIT time of 21 seconds. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of kaname nishizuka Sent: 10 October 2017 04:32 To: Flemming Andreasen; Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.bou= cadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval I agree with Flemming's suggestion. Practically, the timeout will be set to ~30 seconds by operators like us. regards, kaname On 2017/10/10 1:35, Flemming Andreasen wrote: On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote: From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen Sent: Monday, October 9, 2017 9:12 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow = ; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. I'm getting different data-points for at least the minimum value. There sti= ll seems to be a lot of NATs out there with a timeout value of ~30 seconds = for UDP traffic (and in rare cases even lower), which suggests that a timeo= ut value slightly lower than 30 seconds is what you would want. Google did = a lot of testing around this and decided they were happy with the values in= https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds). Consent freshness has nothing to do with NAT/FW timeouts. You are missing the point Tiru - testing has been done (in the past and mor= e recently) and a value of ~30 seconds seems to be what works for the major= ity of devices. I'll trust Google on this one. -- Flemming -Tiru Thanks -- Flemming Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). 2) No, if the DOTS agent wants to change the default heartbeat interval the= n the other message transmission parameters will also have to be modified. 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. >From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_DM5PR16MB1788ECEF23B6A0BDE222F73EEA750DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, October 10, 2017 2:46 PM
To: 'kaname nishizuka' <kaname@nttv6.jp>; Konda, Tirumaleswar = Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.= com; 'Flemming Andreasen' <fandreas@cisco.com>; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

I also = agree – my experience since the 80’s is a (firewall/NAT) UDP se= ssion timeout value default of 30 seconds – RFC4787 came out some 20 = years later in 2007.

&n= bsp;

The = 220;heartbeat-interval” needs to be retained – with a minimum v= alue of less than 30 seconds (perhaps 15 seconds) so that DOTS signal will = work through (?broken?) firewalls/NAT devices that maintain some sort of state.  Even if the heartbeat is every 30 seconds, this = is a packet of less than 100 bytes every 30 seconds – this is not goi= ng to add to a DDoS situation.

&n= bsp;

I think= that text similar to the following also needs to be added

&n= bsp;

“= A heartbeat is not allowed to be transmitted while a previous heartbeat has= not been responded to – which could be longer than the heartbeat int= erval if there is packet loss and could be up to MAX_TRANSMIT_WAIT (RFC7252) seconds.  If MAX_TRANSMIT_WAIT is g= reater than the heartbeat interval and the previous heartbeat has had no re= sponse, then the next heartbeat should be sent as soon as possible.  Otherwise heartbeats should be sent no mor= e frequently than the heartbeat interval.”

 

[TR]= I don’t think the above logic addresses the 30 second NAT/FW idle ti= meout problem, the recommended default max-retransmit has to be reduced to = 2 to get a MAX_TRANSMIT_WAIT time of 21 seconds.

 

-Tir= u

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

 

=
I agree with Flemming's suggestion.
Practically, the timeout will be set to ~30 seconds by operators like us.
regards,
kaname

On 2017/10/10 1:35, Flemming An= dreasen wrote:

=  

On 10/9/17 11:55 AM, Konda, Tir= umaleswar Reddy wrote:

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

 

On 10/5/17 6:54 AM, Konda, Tiru= maleswar Reddy wrote:

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf= referenced by https://tools.ietf.org/html= /rfc7925 has tested NAT behavior with various routers and lists the tim= eout results. The majority of the devices (62%) have a timeout between 2 an= d 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is = 54 seconds.

 =

I'm = getting different data-points for at least the minimum value. There still s= eems to be a lot of NATs out there with a timeout value of ~30 seconds for = UDP traffic (and in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what= you would want. Google did a lot of testing around this and decided they w= ere happy with the values in https://tools.ietf.org/html= /rfc7675 (i.e. 30 seconds).

 =

Consent freshness has nothing to do with NAT/FW time= outs.

You are missing the point Tiru - testing has been = done (in the past and more recently) and a value of ~30 seconds seems to be what works for the majority of devices. I'll trust= Google on this one.

-- Flemming


 =

-Tiru<= /p>



Thanks

-- Flemming



Responses to the questions below

 =

1) The max-retransmit parameter is negotiable and co= nfigurable,  DOTS agents can pick suitable values for max-retransmit p= arameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).=

2) No, if the DOTS agent wants to change the default= heartbeat interval then the other message transmission parameters will als= o have to be modified.

3) The client will have to assume the session is dis= connected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will cl= ose the (D)TLS session, the client will have to initiate (D)TLS session res= umption. The heartbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 =

Med – In the below text, recommended value sho= uld be 93 seconds instead of 90 seconds (see https://tools= .ietf.org/html/rfc7252#section-4.8.2).

 =

-Tiru<= /p>

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

 <= /span>

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

 <= /span>

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

 <= /span>

Oct 04 10:53:51 DEBG sending CoAP ping:

Oct 04 10:53:51 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to retransmit queue= (2281ms)

Oct 04 10:53:51 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message 295= 48

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending CoAP ping:

Oct 04 10:54:07 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to retransmit queue= (2938ms)

Oct 04 10:54:07 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message 295= 49

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending CoAP ping:

Oct 04 10:54:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to retransmit queue= (2156ms)

Oct 04 10:54:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message 295= 50

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending CoAP ping:

Oct 04 10:54:39 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to retransmit queue= (2813ms)

Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #1=

Oct 04 10:54:42 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #2=

Oct 04 10:54:48 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #3=

Oct 04 10:55:00 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #4=

Oct 04 10:55:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up after 4 attempts=

 <= /span>

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

 <= /span>

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests=

 <= /span>

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

 <= /span>

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

 <= /span>

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.=

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Scenari= o as Q3

 <= /span>

Does th= e client re-use the old session that the heartbeats are failing on?<= span lang=3D"EN-GB">

- The s= erver may have sent a session close, but it never got through

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

 <= /span>

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

 <= /span>

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

Regards=

 <= /span>

Jon

 <= /span>

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.or= g] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow = (supjps-ietf@jpshallow.com= )
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment= during the interim meeting: “A: (Jon Shallow): The minimum for the heartbeat should be 10s”

 

Actually, the use of 10s is no= t aligned with RFC8085 which says the following:

 

   An application that needs to employ =
keep-alive messages to deliver
   useful service over UDP in the prese=
nce of middleboxes SHOULD NOT
        &=
nbsp;           &nbs=
p;            &=
nbsp;            ^^^=
^^^^^^^^^^^^^^^^^^^
   transmit them more frequently than o=
nce every 15 seconds and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   use longer intervals when possible.&=
nbsp;

 

I suggest to add this NEW text= to the signal-channel draft to clarify the rationale for the recommended v= alues:

 

NEW:

      Note: heartbeat-interval should be tweake= d to also assist DOTS

      messages for NAT traversal (SIG-010 of

      [I-D.ietf-dots-requirements]).  Acco= rding to [RFC8085], keepalive=

      messages must not be sent more frequently= than once every 15

      seconds and should use longer intervals w= hen possible.

      Furthermore, [RFC4787] recommends NATs to= use a state timeout of 2

      minutes or longer.  >From that st= andpoint, this specification<= /p>

      recommends a minimum heartbeat-interval o= f 15 seconds and a

      maximum heartbeat-interval of 240 seconds= .  The recommended value=

      of 90 seconds is selected to anticipate t= he expiry of NAT states,

      while avoiding overloading the network wi= th frequent keepalives

      for NAT state maintenance purposes. = Note that this recommended

      value is close to the one recommended for= MAX_TRANSMIT_WAIT, whose

      value is derived from transmission parame= ters (Section 4.8.2 of

    &nb= sp; [RFC7252]).

 

Thoughts?

 

Cheers,

Med




_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

&nbs= p;




_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

&= nbsp;

--_000_DM5PR16MB1788ECEF23B6A0BDE222F73EEA750DM5PR16MB1788namp_-- From nobody Tue Oct 10 05:17:50 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA98134DF5 for ; Tue, 10 Oct 2017 05:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=mcafee.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 qjIBmrbreiZb for ; Tue, 10 Oct 2017 05:17:46 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 7E3BB134DF7 for ; Tue, 10 Oct 2017 05:17:04 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507637808; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=s QSxZddyNKf1854guREvnHoxl3F9Y9VDpm/xESuTkL E=; b=h0wjhpAup2B70avG+2Cw2XpgpehpG2BJ2U69gg/OWqjK Wk4HzwEh8GvUAigdX3sUtonU1XMKnBn/WoZWiRf6nTMo2QOZmR 6e4H+tjBjc01hFhQ3Yfi/AyOx0m0uAAZvsp+34mw3FHbGE6mDO z0jmB7EvTayoL2SARLMTG6Zdol8= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c29_b6b8_ebee76e7_8f8d_4e61_81b4_26ccc8bc6199; Tue, 10 Oct 2017 07:16:47 -0500 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 06:16:24 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Oct 2017 06:16:24 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 06:16:23 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 12:16:23 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 12:16:23 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , 'kaname nishizuka' , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAACzkMAABuu0fgAB0EBwAADL1rgAAF4fWw Date: Tue, 10 Oct 2017 12:16:23 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> In-Reply-To: <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:4Pv8iOAfGcbATFc/UX3AVb25CsSiVf00sIDfwcdONpnbC9q1+fjnAGpqlFwBO564VjPACs7yw8ibNZZc4/0kQQxKyrxU2euOHqF7sTHrqYuGfHmRGr8l3lXmT40UJ0S84MQSpe3ZvYU/HclkQwvrYD++8NIDMJ/fsPty8+oavT1re1AkREwn6Qc8gPwtinaSEmmmKPgi5dpLYSa6uuy3r3HKZy/6OeiH6rnoX360YG3cpUMnpN0fU4D/pllo5qT9uYUyY+U56ojpg3yhdZcb1wbfSaCKrHQcE8DX8sTBaxitvBnxPjCamCO78yYxYMm8daA3r+9KdL2g6o1x3+SnCA==; 5:iK+X+I+UIn1B3OWxWMqMaycEcLX1ddXeAyjqZTieooaDqtUwUctAGnga7CW7uaqmg1Qou3WePy3q3N4gTm2Ye6QEBMUxgrp3ZUXU9vwq9FsJLnSInfNzEC2qfq8F9pqttrKAyclONqyMRGgfxXaxew==; 24:oUcPk76SjvPXNQU5HYa5k01+fBJVZbFqi6w9qGdoO1XXYvMCWsxKmq6RhGiAl9VW3dYEev4gmefShX2Fu059GNVdkj/D7qSFe3AINGrmOMc=; 7:Ogl0v5Mk4Lmp1NGZ477RfyFXwwSEZ65Y5IiKbXdH8Fks4sxO/V5T4fmcZJRWDskEhu8UHHqPQKwZrJB2irFndpCdQkkM4FKKNbVe0tGxk0Mj+fcom+jTKSwhc7BUx0lKI63oMh8soTMq/fHVlndS49I1MHMQo8FvD7gAh0MAR4ZmoEFWsYvVVfucO8BS2hvJPnIXosijlLNmoJKEtRzQn/VgsVik0hrynDGii+bRG+I= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 125e07b8-64ff-4311-2c73-08d50fd8b8f5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(199003)(32952001)(189002)(24454002)(51444003)(377454003)(9686003)(2201001)(229853002)(236005)(6306002)(316002)(54896002)(2950100002)(53936002)(7696004)(5660300001)(93886005)(66066001)(7736002)(74316002)(3280700002)(2906002)(3660700001)(110136005)(6246003)(80792005)(55016002)(97736004)(86362001)(99286003)(68736007)(2501003)(14454004)(478600001)(6436002)(6506006)(76176999)(25786009)(50986999)(54356999)(77096006)(105586002)(2900100001)(106356001)(53546010)(189998001)(790700001)(6116002)(102836003)(3846002)(33656002)(8936002)(8676002)(966005)(72206003)(81156014)(81166006)(101416001)(606006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C7E28E29DEFF732D2877EA750DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 12:16:23.2127 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6117> : streams <1766643> : uri <2514250> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 12:17:49 -0000 --_000_DM5PR16MB1788C7E28E29DEFF732D2877EA750DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aG91Z2h0IHdlIGFncmVlZCB0aGF0IGJhc2VkIG9uIHRoZSBjdXJyZW50IERPVFMgcmVxdWly ZW1lbnRzIG9ubHkgdGhlIHNlcnZlci1zaWRlIERPVFMgR1cgbmVlZHMgdG8gY29udmV5IHRoZSBE T1RTIGNsaWVudCAob3IgY2xpZW50LXNpZGUgRE9UUyBXRykgaWRlbnRpdHkgdG8gdGhlIERPVFMg c2VydmVyLg0KDQotVGlydQ0KDQpGcm9tOiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1pZXRm QGpwc2hhbGxvdy5jb21dDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDEwLCAyMDE3IDI6NTMgUE0N ClRvOiAna2FuYW1lIG5pc2hpenVrYScgPGthbmFtZUBudHR2Ni5qcD47IEtvbmRhLCBUaXJ1bWFs ZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tOyBkb3RzQGlldGYub3JnOyBSb2xhbmQgRG9iYmlucyA8cmRv YmJpbnNAYXJib3IubmV0Pg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxs ZW5nZXMNCg0KSGkgS2FuYW1lLA0KDQpJIGRvIG5vdCB0aGluayB0aGF0IGluZm9ybWF0aW9uIG5l Y2Vzc2FyaWx5IG5lZWRzIHRvIGJlIHRoZSBvcmlnaW5hbCBjbGllbnQgaWRlbnRpdHkuICBUaGUg R1cgQ2xpZW50IHNpZGUgd2lsbCBoYXZlIGl0cyBvd24gaWRlbnRpdHkgd2hpY2ggdGhlIERPVFMg U2VydmVyIGNhbiB1c2UgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIERPVFMgKEdXKSBDbGllbnRz Lg0KDQpTbywgeWVzLCBhIGhhc2hlZCBzZXQgb2YgbmFtZXMgY2FuIGJlIHVzZWQg4oCTIGl0IGlz IHVwIHRvIHRoZSBET1RTIEdXIENsaWVudCBzaWRlIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZXJlIGFy ZSBubyBoYXNoIGNvbGxpc2lvbnMuICBPciBpdCBjb3VsZCBiZSBhIHNpbXBsZSBsaXN0IHN1Y2gg YXMgQzEsIEMyIOKApkNuLg0KDQpSZWdhcmRzDQoNCkpvbg0KDQpGcm9tOiBEb3RzIFttYWlsdG86 IGRvdHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnPl0gT24g QmVoYWxmIE9mIGthbmFtZSBuaXNoaXp1a2ENClNlbnQ6IDEwIE9jdG9iZXIgMjAxNyAwNDoxOQ0K VG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk7IEpvbiBTaGFsbG93OyBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90 c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zDQpTdWJqZWN0 OiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSwNCg0KPiBJIGFncmVl IHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJsZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBn YXRld2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBE T1RTIHNlcnZlci4NCkkgYWdyZWUgd2l0aCB0aGlzIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBj YXNlLg0KQXQgdGhlIHNhbWUgdGltZSwgSSBhZ3JlZSB3aXRoIGJlbG93Og0KPiBJIGFncmVlIHRo YXQgaXMgbm90IGEgZ29vZCB0aGluZyB0byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1h dGlvbiB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR1csDQoNClRoZW4sIHNob3VsZCBET1RT IEdXIHNlbmQg4oCcY2xpZW50IGlkZW50aXR54oCdIChpLmUuIGNlcnRpZmljYXRlcyBvZiBET1RT IGNsaWVudHMpIGl0c2VsZiBvciBoYXNoZWQo4oCcY2xpZW50IGlkZW50aXR54oCdKSB0byBET1RT IHNlcnZlcj8NCklmIGxhdGVyLCBob3cgY2FuIERPVFMgc2VydmVyIHJlYWN0IHRvIHRoZSBhbWJp Z3VvdXMgaW5mb3JtYXRpb24gb2YgdGhlIGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHnigJ0pLg0K DQpyZWdhcmRzLA0KS2FuYW1lDQoNCk9uIDIwMTcvMTAvMDkgMjI6MzQsIEtvbmRhLCBUaXJ1bWFs ZXN3YXIgUmVkZHkgd3JvdGU6DQpIaSBKb24sDQoNCkkgYWdyZWUgdGhlIGJlbG93IHByb2JsZW1z IGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IG11c3QgY29u dmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiBCdXQgZm9y IHRoZSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksIGl0IHNob3VsZCByZXNvbHZlIGNvbmZsaWN0 aW5nIHJ1bGVzIGIvdyBET1RTIGNsaWVudHMgKGUuZy4gb25lIGNsaWVudCBpbnN0YWxsaW5nIGJs YWNrLWxpc3QgQUNMIGZvciBhbiBJUCBhZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xpZW50IGluc3Rh bGxzIHdoaXRlLWxpc3QgQUNMIGZvciB0aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1lIGFsaWFzLW5h bWVzIGZvciBkaWZmZXJlbnQgbWl0aWdhdGlvbiBzY29wZXMpLiBJIGRvbuKAmXQgc2VlIHRoZSBu ZWVkIGZvciBhIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKAnGNsaWVu dCBpZGVudGl0eeKAnSB0byB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IG9yIERPVFMgc2Vy dmVyLg0KDQotVGlydQ0KDQpGcm9tOiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1pZXRmQGpw c2hhbGxvdy5jb21dDQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3IDI6MDcgUE0NClRv OiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0Fm ZWUuY29tPjxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47IG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMg PHJkb2JiaW5zQGFyYm9yLm5ldD48bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4NClN1YmplY3Q6 IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUsDQoNClRoaXMg ZGlzY3Vzc2lvbiBnb2VzIGJleW9uZCBqdXN0IHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QuICBXZSBu ZWVkIHRvIGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3aXRoIGJvdGggYWxpYXMtbmFtZSBhbmQgYWNs LW5hbWUgKGRhdGEgY2hhbm5lbCkNCg0KVGhlIHNpbXBsZSBjYXNlIG9mIGEgbWl0aWdhdGlvbiBy ZXF1ZXN0IHdpdGggbm8gYWxpYXMtbmFtZSBkb2VzIG5vdCByZXF1aXJlIGFueSBrbm93bGVkZ2Ug b2YgdGhlIG9yaWdpbmFsIGNsaWVudC4NCg0KSG93ZXZlciwgaWYgdGhlIG1pdGlnYXRpb24gcmVx dWVzdCB1c2VzIGFsaWFzLW5hbWUsIHRoZW4gdGhlcmUgYXJlIDMgd2F5cyBvZiBoYW5kbGluZyB0 aGlzDQoNCmEpICAgICAgIFRoZSBET1RTIEdXIHJlcGxhY2VzIHRoZSBhbGlhcy1uYW1lIHdpdGgg aXRzIGFjdHVhbCBkZWZpbml0aW9uICh0YXJnZXQtaXBzIGV0Yy4gbWVyZ2VkIGFzIGFwcHJvcHJp YXRlKSwgc28gYWxpYXMtbmFtZSBpcyBub3QgZm9yd2FyZGVkIG9uIHRvIFNlcnZlciDigJMganVz dCB0aGUgZXhwYW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGZvcndhcmRlZA0KDQpiKSAgICAg IFRoZSBET1RTIEdXIHVwZGF0ZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBhIHVuaXF1ZSBhbGlhcy1u YW1lIHRoYXQgaXMgZm9yd2FyZGVkIChhbmQgaGFzIHRvIGRvIHRoZSBzYW1lIHRoaW5nIHdoZW4g dGhlIGFsaWFzLW5hbWUgaXMgY29uZmlndXJlZCBvbiB0aGUgZGF0YSBjaGFubmVsKSDigJMgdG8g aGFuZGxlIDIgb3IgbW9yZSBjbGllbnRzIGRlZmluaW5nIHRoZSBzYW1lIGFsaWFzLW5hbWUgd2hp Y2ggaGF2ZSBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNzDQoNCmMpICAgICAgIFRoZSBET1RTIEdX IHJlY29nbmlzZXMgdGhhdCBhbGlhcy1uYW1lIGlzIG5vdCB1bmlxdWUgYW5kIGFkZHMgaW4g4oCd YWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSAoSSB0aGluayBJIHByZWZlciB0aGlzIOKAnC1pbmZv 4oCdIG5hbWUgdG8gY2xpZW50LWlkIG9yIG9yaWdpbmFsLWNsaWVudC1pZCBhcyDigJwtaWTigJ0g aXMgdG9vIGNsb3NlbHkgIGFzc29jaWF0ZWQgd2l0aCBDbGllbnQgSWRlbnRpdHkgZGVyaXZlZCBm cm9tIHRoZSBET1RTIEdXIENsaWVudCBjZXJ0aWZpY2F0ZSkNCldlIGhhdmUgYWdyZWVkIHRoYXQg d2hlbiBhIGNsaWVudCByZXF1ZXN0cyBtaXRpZ2F0aW9uIHN0YXR1cywgdGhlIOKAnGFsaWFzLW5h bWXigJ0gc2hvdWxkIGJlIHJldHVybmVkIGFzIOKAnGFsaWFzLW5hbWXigJ0gYW5kIG5vdCB0aGUg c3Vic3RpdHV0ZWQgYWxpYXMtbmFtZSBjb25maWd1cmF0aW9uICh0aGlzIGRvZXMgbmVlZCB0byBi ZSBzdGF0ZWQgaW4gdGhlIHNwZWMgZm9yIGNsYXJpdHkpLiAgVGhpcyBtYWtlcyAoYSkgZGlmZmlj dWx0IHRvIGJlIGhhbmRsZWQgYnkgRE9UUyBHVyB3aGljaCB0aGVuIHJhaXNlcyB0aGUgcXVlc3Rp b24g4oCTIGRvIHdlIHJlYWxseSBuZWVkIGFsaWFzLW5hbWU/DQoNClRoZSBkZWZpbml0aW9uIGFu ZCBhc3NvY2lhdGlvbiBvZiBBQ0xzL0ZpbHRlcnMgb2YgdGhlIGRhdGEgY2hhbm5lbCBpcyBtb3Jl IGRpZmZpY3VsdCDigJMgdGhlIFNlcnZlciBtdXN0IGluc3RhbGwgLyBhcHBseSB0aGUgYXBwcm9w cmlhdGUgQUNMcyBvbiBhIHBlciAoT3JpZ2luYWwpIENsaWVudCBiYXNpcyB3aGVuIG1pdGlnYXRp b24gaXMgaW52b2tlZC4NCkNsaWVudCAx4oCZcyBjb25jZXB0IG9mIGEgV2hpdGVsaXN0IElQIGNv dWxkIGJlIENsaWVudCAy4oCZcyBjb25jZXB0IG9mIGEgQmxhY2tsaXN0IElQLiAgVGhlIFNlcnZl ciBuZWVkcyB0byBrbm93IHdoaWNoIGNsaWVudCBpcyByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9u IGFuZCBpbnN0YWxsIHRoZSBjb3JyZWN0IEFDTHMg4oCTIGlmIHRoZXJlIHdhcyBubyDigJ1hZGRp dGlvbmFsLWNsaWVudC1pbmZv4oCdLCB0aGUgU2VydmVyIG9ubHkga25vd3MgdGhhdCBoZSBoYXMg dG8gaW5zdGFsbCBBTEwgb2YgdGhlIEFDTHMgKGkuZS4gYm90aCB0aGUgQmxhY2sgYW5kIFdoaXRl IGxpc3Qgb2YgdGhlIHNhbWUgSVAgYXMgZGVmaW5lZCBieSBDbGllbnQgMSBhbmQgQ2xpZW50IDIp IGFzIGRlZmluZWQgYnkgaGlzIGNsaWVudCAoRE9UUyBHVykgd2hlbiBoaXMgY2xpZW50IHJlcXVl c3RzIGEgbWl0aWdhdGlvbi4gIEhlcmUsIEkgdGhpbmsgdGhhdCBpZiB0aGVyZSBpcyBtb3JlIHRo YW4gb25lIGNsaWVudCBmb3IgdGhlIERPVFMgR1csIOKAnWFkZGl0aW9uYWwtY2xpZW50LWluZm/i gJ0gaXMgcmVxdWlyZWQuDQoNClJlZ2FyZHMNCg0KSm9uDQoNCkZyb206IERvdHMgW21haWx0bzog ZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KU2VudDogMDcgT2N0b2JlciAyMDE3 IDA0OjI4DQpUbzogSm9uIFNoYWxsb3c7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpk b3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMNClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBH YXRld2F5cyBDaGFsbGVuZ2VzDQoNCkluIGNhc2Ugb2YgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5 LCB3aHkgZG9lcyB0aGUgRE9UUyBzZXJ2ZXIgbmVlZCB0byBrbm93IHdoaWNoIOKAnERPVFMgY2xp ZW504oCdIGhhcyBjb252ZXllZCB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0ID8NCkZvciBleGFtcGxl LCB0aGUgRE9UUyBjbGllbnQgY291bGQgYmUgYSBERG9TIGRldGVjdG9yIG9yIGFuIEFwcGxpY2F0 aW9uIHNlcnZlciwgYW5kIHRoZSBjbGllbnQtc2lkZSBnYXRld2F5IHdpbGwgaGF2ZSB0byByZXNv bHZlIHRoZSBjb25mbGljdGluZyBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xp ZW50cywgYWdncmVnYXRlIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xp ZW50IGFuZCBzZW5kIHRoZSB1cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUgRE9UUyBz ZXJ2ZXIuDQoNCi1UaXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZA anBzaGFsbG93LmNvbV0NClNlbnQ6IEZyaWRheSwgT2N0b2JlciA2LCAyMDE3IDc6NDIgUE0NClRv OiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0Fm ZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPj47IG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMg PHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pj4NClN1YmplY3Q6 IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUsDQoNClVubGVz cyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBob3cgZG9lcyB0aGUgQ2xpZW50IHNpZGUgb2YgRE9U UyBHVyBjb252ZXkgdG8gdGhlIHVwc3RyZWFtIHNlcnZlciBhIHVuaXF1ZSDigJxjbGllbnQtaWTi gJ0gd2hpY2ggaXMgZGlmZmVyZW50IHRvIHRoZSBpbXBsaWVkIGNsaWVudCBpZCBhcyBkZXJpdmVk IGZyb20gdGhlIFBLSSBjZXJ0aWZpY2F0ZSB0aGF0IHRoZSBET1RTIEdX4oCZQ2xpZW50IHVzZXMv cHJlc2VudHMgd2hlbiBjb21tdW5pY2F0aW5nIHRvIHRoZSBzZXJ2ZXI/DQpUbyBtZSwgdGhlcmUg bmVlZHMgdG8gYmUgYW4gb3B0aW9uIHN1Y2ggYXMg4oCcb3JpZ2luYWwtY2xpZW50LWlk4oCdIG9y IOKAnGNsaWVudC1pZOKAnSAod2hpY2ggaXMgY29uZnVzaW5nIHdoZW4gYWxzbyByZWZlcnJpbmcg dG8gdGhlIGNsaWVudCBpZGVudGl0eSBhcyBkZXJpdmVkIGZyb20gdGhlIChET1RTIEdXKSBDbGll bnTigJlzIFBLSSBjZXJ0aWZpY2F0ZSkgYXMgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbC4NCg0KSSBh Z3JlZSB0aGF0IHRoZSBET1RTIEdXIGNhbiBnZW5lcmF0ZSBpdHMgb3duIHVuaXF1ZSBjbGllbnQt aWQgdG8gc3RvcCBtdWx0aXBsZSBlbnRyaWVzIGJlaW5nIG5lZWRlZC4NCg0KSSBhZ3JlZSB0aGF0 IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5mb3JtYXRp b24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLCBzbyBteSBSRVFVSVJFRCBkb2VzIG5v dCBtYWtlIHNlbnNlLg0KDQpSZWdhcmRzDQoNCkpvbg0KUFMg4oCTIEkgYW0gaGF2aW5nIHRvIGRl YWwgd2l0aCBvdGhlciBzdHVmZiBhdCBwcmVzZW50IOKAkyBJIHdpbGwgZ2V0IGJhY2sgbGF0ZXIg b24gdGhlIG90aGVyIGlzc3VlcyB1bmRlciBkaXNjdXNzaW9uDQoNCkZyb206IEtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkgW21haWx0bzogVGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNv bTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbT5dDQpTZW50OiAwNiBP Y3RvYmVyIDIwMTcgMTQ6NTgNClRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgSm9uIFNoYWxsb3c7ICdEb2JiaW5zLCBS b2xhbmQnOyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDogUkU6 IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSSBkb27igJl0IHNlZSBhIG5lZWQg Zm9yIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKAnERPVFMgY2xpZW50 IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4g4oCcRE9UUyBjbGllbnQgaWRlbnRpdHni gJ0gbG9va3MgcmVxdWlyZWQgb25seSBmb3IgdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheXMu IEluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5IHRoZSBj bGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRv IHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1bmlxdWUg Y2xpZW50LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4gYXJyYXkgb2YgY2xpZW50LWlk cyB0byB0aGUgRE9UUyBzZXJ2ZXIgdG8gcmVzb2x2ZSBjbGFzaGVzLg0KDQotVGlydQ0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRG90cyBt YWlsaW5nIGxpc3QNCg0KRG90c0BpZXRmLm9yZzxtYWlsdG86RG90c0BpZXRmLm9yZz4NCg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoNCg== --_000_DM5PR16MB1788C7E28E29DEFF732D2877EA750DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ cGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQg MiAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjsNCgljb2xvcjpi bGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiU2Vnb2UgVUkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1 bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpwLlRleHRlZGVidWxs ZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJe21zby1zdHlsZS1uYW1l OiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHls ZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5J IHRob3VnaHQgd2UgYWdyZWVkIHRoYXQgYmFzZWQgb24gdGhlIGN1cnJlbnQgRE9UUyByZXF1aXJl bWVudHMgb25seSB0aGUgc2VydmVyLXNpZGUgRE9UUyBHVyBuZWVkcyB0byBjb252ZXkgdGhlIERP VFMgY2xpZW50IChvciBjbGllbnQtc2lkZSBET1RTIFdHKSBpZGVudGl0eQ0KIHRvIHRoZSBET1RT IHNlcnZlci4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0 Ij4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5h bWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIw MTcgMjo1MyBQTTxicj4NCjxiPlRvOjwvYj4gJ2thbmFtZSBuaXNoaXp1a2EnICZsdDtrYW5hbWVA bnR0djYuanAmZ3Q7OyBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDtUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tJmd0OzsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsg ZG90c0BpZXRmLm9yZzsgUm9sYW5kIERvYmJpbnMgJmx0O3Jkb2JiaW5zQGFyYm9yLm5ldCZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEthbmFtZSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SSBkbyBub3QgdGhpbmsgdGhhdCBpbmZvcm1hdGlvbiBuZWNlc3NhcmlseSBuZWVkcyB0byBiZSB0 aGUgb3JpZ2luYWwgY2xpZW50IGlkZW50aXR5LiZuYnNwOyBUaGUgR1cgQ2xpZW50IHNpZGUgd2ls bCBoYXZlIGl0cyBvd24gaWRlbnRpdHkgd2hpY2ggdGhlIERPVFMNCiBTZXJ2ZXIgY2FuIHVzZSB0 byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gRE9UUyAoR1cpIENsaWVudHMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNv LCB5ZXMsIGEgaGFzaGVkIHNldCBvZiBuYW1lcyBjYW4gYmUgdXNlZCDigJMgaXQgaXMgdXAgdG8g dGhlIERPVFMgR1cgQ2xpZW50IHNpZGUgdG8gbWFrZSBzdXJlIHRoYXQgdGhlcmUgYXJlIG5vIGhh c2ggY29sbGlzaW9ucy4mbmJzcDsgT3IgaXQgY291bGQgYmUNCiBhIHNpbXBsZSBsaXN0IHN1Y2gg YXMgQzEsIEMyIOKApkNuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gRG90cyBbbWFpbHRvOg0KPGEgaHJlZj0ibWFpbHRv OmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24g QmVoYWxmIE9mDQo8L2I+a2FuYW1lIG5pc2hpenVrYTxicj4NCjxiPlNlbnQ6PC9iPiAxMCBPY3Rv YmVyIDIwMTcgMDQ6MTk8YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk7 IEpvbiBTaGFsbG93OyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRv dHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmluczxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+SGks PGJyPg0KPGJyPg0KJmd0OyBJIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJs ZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xp ZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4NCjxicj4NCkkgYWdyZWUgd2l0aCB0 aGlzIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBjYXNlLjxicj4NCkF0IHRoZSBzYW1lIHRpbWUs IEkgYWdyZWUgd2l0aCBiZWxvdzo8YnI+DQomZ3Q7IEkgYWdyZWUgdGhhdCBpcyBub3QgYSBnb29k IHRoaW5nIHRvIOKAnGxlYWvigJ0gb3V0IGludGVybmFsIGluZm9ybWF0aW9uIHdoZW4gcGFzc2lu ZyB0aHJvdWdoIGEgRE9UUyBHVywNCjxicj4NCjxicj4NClRoZW4sIHNob3VsZCBET1RTIEdXIHNl bmQg4oCcY2xpZW50IGlkZW50aXR54oCdIChpLmUuIGNlcnRpZmljYXRlcyBvZiBET1RTIGNsaWVu dHMpIGl0c2VsZiBvciBoYXNoZWQo4oCcY2xpZW50IGlkZW50aXR54oCdKSB0byBET1RTIHNlcnZl cj88YnI+DQpJZiBsYXRlciwgaG93IGNhbiBET1RTIHNlcnZlciByZWFjdCB0byB0aGUgYW1iaWd1 b3VzIGluZm9ybWF0aW9uIG9mIHRoZSBoYXNoZWQo4oCcY2xpZW50IGlkZW50aXR54oCdKS48YnI+ DQo8YnI+DQpyZWdhcmRzLDxicj4NCkthbmFtZTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+T24g MjAxNy8xMC8wOSAyMjozNCwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgSm9uLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5JIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJsZSBmb3Igc2Vy dmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50 aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gQnV0IGZvciB0aGUgY2xpZW50LXNpZGUgRE9UUyBn YXRld2F5LA0KIGl0IHNob3VsZCByZXNvbHZlIGNvbmZsaWN0aW5nIHJ1bGVzIGIvdyBET1RTIGNs aWVudHMgKGUuZy4gb25lIGNsaWVudCBpbnN0YWxsaW5nIGJsYWNrLWxpc3QgQUNMIGZvciBhbiBJ UCBhZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xpZW50IGluc3RhbGxzIHdoaXRlLWxpc3QgQUNMIGZv ciB0aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1lIGFsaWFzLW5hbWVzIGZvciBkaWZmZXJlbnQgbWl0 aWdhdGlvbiBzY29wZXMpLiBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkDQogZm9yIGEgY2xpZW50LXNp ZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRo ZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgb3IgRE9UUyBzZXJ2ZXIuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi1UaXJ1PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBKb24gU2hhbGxvdyBbPGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20i Pm1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3IDI6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRh LCBUaXJ1bWFsZXN3YXIgUmVkZHkgPGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tv bmRhQE1jQWZlZS5jb20iPg0KJmx0O1RpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20m Z3Q7PC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0K bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGll dGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnMNCjxhIGhyZWY9Im1haWx0 bzpyZG9iYmluc0BhcmJvci5uZXQiPiZsdDtyZG9iYmluc0BhcmJvci5uZXQmZ3Q7PC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGRpc2N1c3Npb24g Z29lcyBiZXlvbmQganVzdCB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0LiZuYnNwOyBXZSBuZWVkIHRv IGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3aXRoIGJvdGggYWxpYXMtbmFtZSBhbmQgYWNsLW5hbWUg KGRhdGEgY2hhbm5lbCk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBzaW1wbGUgY2FzZSBvZiBhIG1pdGlnYXRpb24gcmVx dWVzdCB3aXRoIG5vIGFsaWFzLW5hbWUgZG9lcyBub3QgcmVxdWlyZSBhbnkga25vd2xlZGdlIG9m IHRoZSBvcmlnaW5hbCBjbGllbnQuJm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIGlmIHRoZSBtaXRp Z2F0aW9uIHJlcXVlc3QgdXNlcyBhbGlhcy1uYW1lLCB0aGVuIHRoZXJlIGFyZSAzIHdheXMgb2Yg aGFuZGxpbmcgdGhpczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YSk8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgRE9UUyBHVyByZXBsYWNlcyB0aGUg YWxpYXMtbmFtZSB3aXRoIGl0cyBhY3R1YWwgZGVmaW5pdGlvbiAodGFyZ2V0LWlwcyBldGMuIG1l cmdlZCBhcyBhcHByb3ByaWF0ZSksIHNvIGFsaWFzLW5hbWUgaXMgbm90IGZvcndhcmRlZCBvbiB0 byBTZXJ2ZXIg4oCTIGp1c3QgdGhlDQogZXhwYW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGZv cndhcmRlZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Yik8L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgRE9UUyBHVyB1cGRhdGVzIHRoZSBhbGlhcy1uYW1lIHdp dGggYSB1bmlxdWUgYWxpYXMtbmFtZSB0aGF0IGlzIGZvcndhcmRlZCAoYW5kIGhhcyB0byBkbyB0 aGUgc2FtZSB0aGluZyB3aGVuIHRoZSBhbGlhcy1uYW1lIGlzIGNvbmZpZ3VyZWQgb24gdGhlIGRh dGEgY2hhbm5lbCkNCiDigJMgdG8gaGFuZGxlIDIgb3IgbW9yZSBjbGllbnRzIGRlZmluaW5nIHRo ZSBzYW1lIGFsaWFzLW5hbWUgd2hpY2ggaGF2ZSBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNzPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5jKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RTIEdXIHJlY29nbmlzZXMgdGhhdCBhbGlhcy1uYW1lIGlz IG5vdCB1bmlxdWUgYW5kIGFkZHMgaW4g4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSAoSSB0 aGluayBJIHByZWZlciB0aGlzIOKAnC1pbmZv4oCdIG5hbWUgdG8gY2xpZW50LWlkIG9yIG9yaWdp bmFsLWNsaWVudC1pZA0KIGFzIOKAnC1pZOKAnSBpcyB0b28gY2xvc2VseSAmbmJzcDthc3NvY2lh dGVkIHdpdGggQ2xpZW50IElkZW50aXR5IGRlcml2ZWQgZnJvbSB0aGUgRE9UUyBHVyBDbGllbnQg Y2VydGlmaWNhdGUpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPldlIGhhdmUgYWdyZWVkIHRoYXQgd2hlbiBhIGNsaWVudCByZXF1ZXN0cyBt aXRpZ2F0aW9uIHN0YXR1cywgdGhlIOKAnGFsaWFzLW5hbWXigJ0gc2hvdWxkIGJlIHJldHVybmVk IGFzIOKAnGFsaWFzLW5hbWXigJ0gYW5kIG5vdCB0aGUgc3Vic3RpdHV0ZWQgYWxpYXMtbmFtZQ0K IGNvbmZpZ3VyYXRpb24gKHRoaXMgZG9lcyBuZWVkIHRvIGJlIHN0YXRlZCBpbiB0aGUgc3BlYyBm b3IgY2xhcml0eSkuJm5ic3A7IFRoaXMgbWFrZXMgKGEpIGRpZmZpY3VsdCB0byBiZSBoYW5kbGVk IGJ5IERPVFMgR1cgd2hpY2ggdGhlbiByYWlzZXMgdGhlIHF1ZXN0aW9uIOKAkyBkbyB3ZSByZWFs bHkgbmVlZCBhbGlhcy1uYW1lPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGRlZmluaXRpb24gYW5kIGFzc29jaWF0aW9u IG9mIEFDTHMvRmlsdGVycyBvZiB0aGUgZGF0YSBjaGFubmVsIGlzIG1vcmUgZGlmZmljdWx0IOKA kyB0aGUgU2VydmVyIG11c3QgaW5zdGFsbCAvIGFwcGx5IHRoZSBhcHByb3ByaWF0ZSBBQ0xzIG9u IGENCiBwZXIgKE9yaWdpbmFsKSBDbGllbnQgYmFzaXMgd2hlbiBtaXRpZ2F0aW9uIGlzIGludm9r ZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkNsaWVudCAx4oCZcyBjb25jZXB0IG9mIGEgV2hpdGVsaXN0IElQIGNvdWxkIGJlIENsaWVu dCAy4oCZcyBjb25jZXB0IG9mIGEgQmxhY2tsaXN0IElQLiZuYnNwOyBUaGUgU2VydmVyIG5lZWRz IHRvIGtub3cgd2hpY2ggY2xpZW50IGlzIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24NCiBhbmQg aW5zdGFsbCB0aGUgY29ycmVjdCBBQ0xzIOKAkyBpZiB0aGVyZSB3YXMgbm8g4oCdYWRkaXRpb25h bC1jbGllbnQtaW5mb+KAnSwgdGhlIFNlcnZlciBvbmx5IGtub3dzIHRoYXQgaGUgaGFzIHRvIGlu c3RhbGwgQUxMIG9mIHRoZSBBQ0xzIChpLmUuIGJvdGggdGhlIEJsYWNrIGFuZCBXaGl0ZSBsaXN0 IG9mIHRoZSBzYW1lIElQIGFzIGRlZmluZWQgYnkgQ2xpZW50IDEgYW5kIENsaWVudCAyKSBhcyBk ZWZpbmVkIGJ5IGhpcyBjbGllbnQgKERPVFMgR1cpDQogd2hlbiBoaXMgY2xpZW50IHJlcXVlc3Rz IGEgbWl0aWdhdGlvbi4mbmJzcDsgSGVyZSwgSSB0aGluayB0aGF0IGlmIHRoZXJlIGlzIG1vcmUg dGhhbiBvbmUgY2xpZW50IGZvciB0aGUgRE9UUyBHVywg4oCdYWRkaXRpb25hbC1jbGllbnQtaW5m b+KAnSBpcyByZXF1aXJlZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpvbjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWYiPiBEb3RzIFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn Ij5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Lb25kYSwg VGlydW1hbGVzd2FyIFJlZGR5PGJyPg0KPGI+U2VudDo8L2I+IDA3IE9jdG9iZXIgMjAxNyAwNDoy ODxicj4NCjxiPlRvOjwvYj4gSm9uIFNoYWxsb3c7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsNCjxh IGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERv YmJpbnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxs ZW5nZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+SW4gY2FzZSBvZiBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXks IHdoeSBkb2VzIHRoZSBET1RTIHNlcnZlciBuZWVkIHRvIGtub3cgd2hpY2gg4oCcRE9UUyBjbGll bnTigJ0gaGFzIGNvbnZleWVkIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgPzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Rm9yIGV4YW1wbGUsIHRoZSBET1RTIGNsaWVu dCBjb3VsZCBiZSBhIEREb1MgZGV0ZWN0b3Igb3IgYW4gQXBwbGljYXRpb24gc2VydmVyLCBhbmQg dGhlIGNsaWVudC1zaWRlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHJlc29sdmUgdGhlIGNvbmZsaWN0 aW5nIG1pdGlnYXRpb24gcmVxdWVzdHMNCiBmcm9tIHRoZSBET1RTIGNsaWVudHMsIGFnZ3JlZ2F0 ZSB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIHRoZSBET1RTIGNsaWVudCBhbmQgc2VuZCB0 aGUgdXBkYXRlZCBtaXRpZ2F0aW9uIHJlcXVlc3QgdG8gdGhlIERPVFMgc2VydmVyLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tVGlydTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gSm9uIFNoYWxsb3cgWzxhIGhyZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxs b3cuY29tIj5tYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDYsIDIwMTcgNzo0MiBQTTxicj4NCjxiPlRvOjwvYj4g S29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dh clJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5j b208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t Ij5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNA aWV0Zi5vcmciPg0KZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVm PSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Vbmxlc3MgSSBhbSBt aXNzaW5nIHNvbWV0aGluZywgaG93IGRvZXMgdGhlIENsaWVudCBzaWRlIG9mIERPVFMgR1cgY29u dmV5IHRvIHRoZSB1cHN0cmVhbSBzZXJ2ZXIgYSB1bmlxdWUg4oCcY2xpZW50LWlk4oCdIHdoaWNo IGlzIGRpZmZlcmVudCB0byB0aGUgaW1wbGllZA0KIGNsaWVudCBpZCBhcyBkZXJpdmVkIGZyb20g dGhlIFBLSSBjZXJ0aWZpY2F0ZSB0aGF0IHRoZSBET1RTIEdX4oCZQ2xpZW50IHVzZXMvcHJlc2Vu dHMgd2hlbiBjb21tdW5pY2F0aW5nIHRvIHRoZSBzZXJ2ZXI/PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvIG1lLCB0aGVyZSBuZWVkcyB0 byBiZSBhbiBvcHRpb24gc3VjaCBhcyDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0gb3Ig4oCcY2xp ZW50LWlk4oCdICh3aGljaCBpcyBjb25mdXNpbmcgd2hlbiBhbHNvIHJlZmVycmluZyB0byB0aGUg Y2xpZW50IGlkZW50aXR5IGFzDQogZGVyaXZlZCBmcm9tIHRoZSAoRE9UUyBHVykgQ2xpZW504oCZ cyBQS0kgY2VydGlmaWNhdGUpIGFzIGEgcGFydCBvZiB0aGUgcHJvdG9jb2wuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFn cmVlIHRoYXQgdGhlIERPVFMgR1cgY2FuIGdlbmVyYXRlIGl0cyBvd24gdW5pcXVlIGNsaWVudC1p ZCB0byBzdG9wIG11bHRpcGxlIGVudHJpZXMgYmVpbmcgbmVlZGVkLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0 aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5mb3Jt YXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLCBzbyBteSBSRVFVSVJFRCBkb2Vz IG5vdCBtYWtlIHNlbnNlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9uPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBTIOKAkyBJIGFtIGhh dmluZyB0byBkZWFsIHdpdGggb3RoZXIgc3R1ZmYgYXQgcHJlc2VudCDigJMgSSB3aWxsIGdldCBi YWNrIGxhdGVyIG9uIHRoZSBvdGhlciBpc3N1ZXMgdW5kZXIgZGlzY3Vzc2lvbjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWYiPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IFttYWlsdG86DQo8YSBocmVmPSJtYWls dG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbSI+VGlydW1hbGVzd2FyUmVkZHlf S29uZGFAbWNhZmVlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDYgT2N0b2JlciAyMDE3 IDE0OjU4PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IEpvbiBTaGFsbG93 OyAnRG9iYmlucywgUm9sYW5kJzsNCjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3Rz QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdh eXMgQ2hhbGxlbmdlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGRvbuKAmXQgc2VlIGEgbmVlZCBmb3IgY2xp ZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRp dHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSBsb29r cyByZXF1aXJlZCBvbmx5IGZvciB0aGUgc2VydmVyLXNpZGUNCiBET1RTIGdhdGV3YXlzLiBJbiBj YXNlIG9mIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgY2FuIGNvbnZleSB0aGUgY2xpZW50 LWlkIGdlbmVyYXRlZCBmcm9tIHRoZSDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUg RE9UUyBzZXJ2ZXIuIFRoZSBET1RTIGdhdGV3YXkgY2FuIGdlbmVyYXRlIGEgdW5pcXVlIGNsaWVu dC1pZCBhbmQgZG9lcyBub3QgaGF2ZSB0byBzZW5kIGFuIGFycmF5IG9mIGNsaWVudC1pZHMgdG8g dGhlIERPVFMgc2VydmVyDQogdG8gcmVzb2x2ZSBjbGFzaGVzLiA8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+LVRpcnU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+RG90cyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPjxhIGhyZWY9Im1haWx0bzpE b3RzQGlldGYub3JnIj5Eb3RzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kb3RzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR16MB1788C7E28E29DEFF732D2877EA750DM5PR16MB1788namp_-- From nobody Tue Oct 10 05:23:07 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACC9134545 for ; Tue, 10 Oct 2017 05:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 1Dj6f6y2H2Og for ; Tue, 10 Oct 2017 05:23:04 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 60E42134D96 for ; Tue, 10 Oct 2017 05:21:48 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507638107; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=i0ypDRsdMZIbWcdK0W3Veg35sqrzDdZoKfrjwp 6gQMI=; b=n+8M2Guxqliw/mntOElQxVyRVQIJNSph8eowaJLO 5ppAruk6R/psPOACkqMF+q0hrXVozNUfWDT2uoVGTuimVmxRaL 4oxtjwqRV43bGxKxEKwkGKXPu9ZvlBgEWRB0kvr30LRoKQYIRA sym5SnbuvGbXugsVz2dFOAMSgIivXl8= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c1a_1528_3f11e8fa_8028_4ec3_b124_ddfec6194464; Tue, 10 Oct 2017 07:21:46 -0500 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 06:21:37 -0600 Received: from DNVEX10N01.corpzone.internalzone.com (10.44.82.192) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Oct 2017 06:21:37 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEX10N01.corpzone.internalzone.com (10.44.82.192) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 10 Oct 2017 06:21:37 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 06:21:36 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 12:21:36 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 12:21:36 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: New DOTS signal and data channel requirements Thread-Index: AdNBwk09lvTBkcrPTyu7yNIocIr0sw== Date: Tue, 10 Oct 2017 12:21:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:79oZ4UZQuppzfxjbE+LPNSWlGOb8B4joRYmwiUqmrm8VIphFLBXEaJNLQkO6E1uIj+dwjCNEUxBefP7MiqWkfrbbkw90PBTOD+zKxtKeAQCC6yV2rZsWC2KEeqmYKFYaF6pmrpxWg1791DgLLWLkwC9Mvt2VHQCqrSU1rDH2C34XFGiEUkcBux+59sTJSvMjngdbBJ89a5rPpr1xHF4Z96WWO28sijVyKV/qU8mDmDIahpQxwooW6p7PhO4HdUIyjon29ds8HDOqWcApzTQSvNQqwIZ1jm7iVY6j2oCx4NrN3CBvbE0K+g5zLb3HK/sIGRLZv3toOYUoZV0PNpPfrg==; 5:w0G2ieeMjIwp6VPdvlYfIduJVssnFRfjodgWlLoIlfUXvF0sa0j8EN10sTT2fLcAtTReq4Zwe04mZj+eBUWVt8QpNCPojLOPlDNP2MziokX5pU2xXB9EEfqIxnyPvlJcoQcMkudGIpp48mdCL6QYoQ==; 24:DMgbsVvJJLbmvXwRyS5hpKm0xj3hIRzrZQeG8b2+oWBPAckEAsFgTod7jHQ7tAmDG6LI6vekpG/WrfKgj0Qt5Wv8U0V9zmweztuCCy4GQq8=; 7:n+PdxZ1PAgcL6Yn8skm5oHYFRaCxAafKIkWrx8BiKwAydmMbEKLrdXWT4gLbC7Dehm3S5WuU6mwEF1zLPZTYJ8Oy0FKhLVz25eXyKGATaTJLwaDK9RnmbwWvBLh9iOflXMm/j2LLmMqAYD+x6iSnyxuVBKbMyIlLDVA4imgSbSqEmpTx0eOwGdL5dol/cp6Rza5T/qnRwpBu5ybmyU0jRuNysXZ/fjRAKpWYm+mHEtU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e532fd7a-368c-4bb7-2056-08d50fd97375 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(32952001)(199003)(189002)(106356001)(2900100001)(105586002)(77096006)(189998001)(6436002)(14454004)(478600001)(25786009)(50986999)(54356999)(6506006)(72206003)(81156014)(101416001)(81166006)(8936002)(8676002)(790700001)(6116002)(102836003)(3846002)(33656002)(7736002)(66066001)(74316002)(316002)(54896002)(6306002)(9686003)(2201001)(5660300001)(53936002)(7696004)(86362001)(97736004)(99286003)(80792005)(55016002)(19609705001)(2501003)(68736007)(3660700001)(3280700002)(2906002)(110136005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788AABF403E65161CE8CC78EA750DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 12:21:36.0606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6117> : streams <1766644> : uri <2514251> Archived-At: Subject: [Dots] New DOTS signal and data channel requirements X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 12:23:06 -0000 --_000_DM5PR16MB1788AABF403E65161CE8CC78EA750DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3RhcnRpbmcgYSBuZXcgdGhyZWFkIHRvIGRpc2N1c3MgdGhlIGJlbG93IG5ldyByZXF1aXJlbWVu dCBmcm9tIEpvbjoNCg0KW0pvbl0gSSBoYXZlIHJlLXJlYWQgdGhlIHJlcXVpcmVtZW50cyAvIGFy Y2hpdGVjdHVyZSBkcmFmdHMuICBJIGFncmVlIHRoYXQgY3VycmVudGx5IHRoZSBXaGl0ZS9CbGFj ay9GaWx0ZXIgZGVmaW5pdGlvbnMgaGF2ZSBubyBkZXBlbmRlbmN5IG9uIHRoZSBtaXRpZ2F0aW9u IHJlcXVlc3Qg4oCTIGl0IGlzIHVwIHRvIHRoZSBET1RTIHNlcnZlciAoR1cgb3Igbm90KSBhcyB0 byBob3cgdGhlIFdoaXRlL0JsYWNrL0ZpbHRlciBkZWZpbml0aW9ucyBnZXQgcGFzc2VkIG9uIHRv IERPVFMgbWl0aWdhdG9yIChvdXQgb2Ygc3BlYyksIGJ1dCB0aGUgRE9UUyBzZXJ2ZXIgbmVlZHMg dG8ga25vdyB3aGljaCBvZiB0aGUgV2hpdGUvQmxhY2svRmlsdGVyIGRlZmluaXRpb25zIGFyZSBy ZWxldmFudCB3aGVuIGEgbWl0aWdhdGlvbiByZXF1ZXN0IGNvbWVzIGluLiAgQ3VycmVudGx5LCBp dCBpcyBwb3NzaWJsZSBmb3IgdGhlIERPVFMgU2VydmVyIHRvIGhvbGQgV2hpdGUvQmxhY2svRmls dGVyIGRlZmluaXRpb25zIG9uIGEgcGVyIGNsaWVudCBpZGVudGl0eS4gIFdoZW4gdGhlIFdoaXRl L0JsYWNrL0ZpbHRlciBkZWZpbml0aW9ucyBhcmUgcGFzc2VkIGZyb20gYSBHVyBDbGllbnQgc2lk ZSB0byBhIEdXIHNlcnZlciBzaWRlIGFuZCBvbiB0byB0aGUgbmV4dCBET1RTIHNlcnZlciwgR1cg c2VydmVyIHNpZGUgaGFzIHRvIGNvbnZleSBhbHNvIHNvbWV0aGluZyBhYm91dCB0aGUgY2xpZW50 cyBvbiB0aGUgR1cgY2xpZW50IHNpZGUgZm9yIHRoZSBET1RTIHNlcnZlciB0byBtYWludGFpbiB0 aGUgV2hpdGUvQmxhY2svRmlsdGVyIGRlZmluaXRpb25zIG9uIGEgcGVyIHBzZXVkbyDigJxjbGll bnQgaWRlbnRpdHnigJ0g4oCTIHNvIHdoZW4gdGhlIG1pZ3JhdGlvbiByZXF1ZXN0IGlzIHBhc3Nl ZCB0byB0aGUgRE9TIHNlcnZlciB2aWEgYSBHVyBpdCBrbm93cyB3aGF0IFdoaXRlL0JsYWNrL0Zp bHRlciBkZWZpbml0aW9ucyB0byBhcHBseSB0byB0aGF0IG1pdGlnYXRpb24gcmVxdWVzdC4NCg0K LVRpcnUNCg0K --_000_DM5PR16MB1788AABF403E65161CE8CC78EA750DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQg MiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs c2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1s ZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkJhbGxvb25UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWls eToiU2Vnb2UgVUkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1z dHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsc2Fucy1zZXJpZjt9DQpwLlRleHRlZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5U ZXh0ZWRlYnVsbGVzDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1z dHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUzMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTMzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3RhcnRpbmcgYSBuZXcg dGhyZWFkIHRvIGRpc2N1c3MgdGhlIGJlbG93IG5ldyByZXF1aXJlbWVudCBmcm9tIEpvbjo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+W0pvbl0gSSBoYXZlIHJlLXJlYWQgdGhlIHJlcXVpcmVtZW50cyAvIGFyY2hpdGVj dHVyZSBkcmFmdHMuJm5ic3A7IEkgYWdyZWUgdGhhdCBjdXJyZW50bHkgdGhlIFdoaXRlL0JsYWNr L0ZpbHRlciBkZWZpbml0aW9ucyBoYXZlIG5vIGRlcGVuZGVuY3kgb24gdGhlDQogbWl0aWdhdGlv biByZXF1ZXN0IOKAkyBpdCBpcyB1cCB0byB0aGUgRE9UUyBzZXJ2ZXIgKEdXIG9yIG5vdCkgYXMg dG8gaG93IHRoZSBXaGl0ZS9CbGFjay9GaWx0ZXIgZGVmaW5pdGlvbnMgZ2V0IHBhc3NlZCBvbiB0 byBET1RTIG1pdGlnYXRvciAob3V0IG9mIHNwZWMpLCBidXQgdGhlIERPVFMgc2VydmVyIG5lZWRz IHRvIGtub3cgd2hpY2ggb2YgdGhlIFdoaXRlL0JsYWNrL0ZpbHRlciBkZWZpbml0aW9ucyBhcmUg cmVsZXZhbnQgd2hlbiBhIG1pdGlnYXRpb24NCiByZXF1ZXN0IGNvbWVzIGluLiZuYnNwOyBDdXJy ZW50bHksIGl0IGlzIHBvc3NpYmxlIGZvciB0aGUgRE9UUyBTZXJ2ZXIgdG8gaG9sZCBXaGl0ZS9C bGFjay9GaWx0ZXIgZGVmaW5pdGlvbnMgb24gYSBwZXIgY2xpZW50IGlkZW50aXR5LiZuYnNwOyBX aGVuIHRoZSBXaGl0ZS9CbGFjay9GaWx0ZXIgZGVmaW5pdGlvbnMgYXJlIHBhc3NlZCBmcm9tIGEg R1cgQ2xpZW50IHNpZGUgdG8gYSBHVyBzZXJ2ZXIgc2lkZSBhbmQgb24gdG8gdGhlIG5leHQgRE9U UyBzZXJ2ZXIsDQogR1cgc2VydmVyIHNpZGUgaGFzIHRvIGNvbnZleSBhbHNvIHNvbWV0aGluZyBh Ym91dCB0aGUgY2xpZW50cyBvbiB0aGUgR1cgY2xpZW50IHNpZGUgZm9yIHRoZSBET1RTIHNlcnZl ciB0byBtYWludGFpbiB0aGUgV2hpdGUvQmxhY2svRmlsdGVyIGRlZmluaXRpb25zIG9uIGEgcGVy IHBzZXVkbyDigJxjbGllbnQgaWRlbnRpdHnigJ0g4oCTIHNvIHdoZW4gdGhlIG1pZ3JhdGlvbiBy ZXF1ZXN0IGlzIHBhc3NlZCB0byB0aGUgRE9TIHNlcnZlciB2aWEgYSBHVyBpdA0KIGtub3dzIHdo YXQgV2hpdGUvQmxhY2svRmlsdGVyIGRlZmluaXRpb25zIHRvIGFwcGx5IHRvIHRoYXQgbWl0aWdh dGlvbiByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR16MB1788AABF403E65161CE8CC78EA750DM5PR16MB1788namp_-- From nobody Tue Oct 10 05:44:52 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5D9134508 for ; Tue, 10 Oct 2017 05:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb-rk-gbb5wr for ; Tue, 10 Oct 2017 05:44:48 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 7636E134512 for ; Tue, 10 Oct 2017 05:44:47 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e1tts-0003El-BV; Tue, 10 Oct 2017 13:44:44 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "kaname nishizuka" , , , "Roland Dobbins" References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> In-Reply-To: Date: Tue, 10 Oct 2017 13:44:46 +0100 Message-ID: <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D8A_01D341CD.EF7F6100" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIAJQ6kjUASRe9X8Bri7ZGgMYlBpaAoe6cxMBVc+iCQKRB52aomKe36A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 12:44:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0D8A_01D341CD.EF7F6100 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 Agreed that only a DOTS GW server facing needs to send information to = the upstream DOTS Server =E2=80=93 which could also be a DOTS GW. +-------------+ | | D | | +----+ | | O | | +----+ | c1 |----------| s1 | T | c2 |---------| s2 | +----+ | | S | | +----+ | | G | | +-------------+ https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-2.2.3= =20 However, the DOTS GW client facing (s1) is the one with knowledge of the = individual clients that are currently using the DOTS server running on = the DOTS GW. This information has to somehow be passed over to the DOTS = GW server facing (c2), but separate DOTS stacks are being run for (s1) = and (c2) as per architecture spec 2.2.3. I was referring to what (s1) = may need to pass on to (c2) in my email response to Kaname, not what is = sent by (c1). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 13:16 To: Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 I thought we agreed that based on the current DOTS requirements only the = server-side DOTS GW needs to convey the DOTS client (or client-side DOTS = WG) identity to the DOTS server.=20 =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 2:53 PM To: 'kaname nishizuka' ; Konda, Tirumaleswar Reddy = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Kaname, =20 I do not think that information necessarily needs to be the original = client identity. The GW Client side will have its own identity which = the DOTS Server can use to differentiate between DOTS (GW) Clients. =20 So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash collisions. Or = it could be a simple list such as C1, C2 =E2=80=A6Cn. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 10 October 2017 04:19 To: Konda, Tirumaleswar Reddy; Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi, > I agree the below problems are applicable for server-side DOTS = gateway, it must convey the =E2=80=9Cclient identity=E2=80=9D to the = DOTS server.=20 I agree with this server-side DOTS gateway case. At the same time, I agree with below: > I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW,=20 Then, should DOTS GW send =E2=80=9Cclient identity=E2=80=9D (i.e. = certificates of DOTS clients) itself or hashed(=E2=80=9Cclient = identity=E2=80=9D) to DOTS server? If later, how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient identity=E2=80=9D). regards, Kaname On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote: Hi Jon, =20 I agree the below problems are applicable for server-side DOTS gateway, = it must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. = But for the client-side DOTS gateway, it should resolve conflicting = rules b/w DOTS clients (e.g. one client installing black-list ACL for an = IP address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:07 PM To: Konda, Tirumaleswar Reddy = = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds = in =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0D8A_01D341CD.EF7F6100 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Agreed that only a DOTS GW server facing needs to send information to = the upstream DOTS Server =E2=80=93 which could also be a DOTS = GW.

=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=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0 | D |=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0 | O |=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | c1 = |----------| s1 | T | c2 |---------| s2 |

=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=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0 | S = |=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0 | G |=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=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 +-------------+

https://tools.ietf.org/html/draft-ietf-dots-architecture-04#sec= tion-2.2.3

 

However, the DOTS GW client facing (s1) is the one with knowledge of = the individual clients that are currently using =C2=A0the DOTS server = running on the DOTS GW.=C2=A0 This information has to somehow be passed = over to the DOTS GW server facing (c2), but separate DOTS stacks are = being run for (s1) and (c2) as per architecture spec 2.2.3.=C2=A0 I was = referring to what (s1) may need to pass on to (c2) in my email response = to Kaname, not what is sent by (c1).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy
Sent: 10 October 2017 13:16
To: = Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS = Gateways Challenges

 

I thought we agreed that based on the current DOTS requirements = only the server-side DOTS GW needs to convey the DOTS client (or = client-side DOTS WG) identity to the DOTS server. =

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 2:53 PM
To: = 'kaname nishizuka' <kaname@nttv6.jp>; Konda, = Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Kaname,

 

I do not think that information necessarily needs to be the original = client identity.  The GW Client side will have its own identity = which the DOTS Server can use to differentiate between DOTS (GW) = Clients.

 

So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash = collisions.  Or it could be a simple list such as C1, C2 = =E2=80=A6Cn.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of kaname nishizuka
Sent: 10 October 2017 = 04:19
To: Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi,

> I agree the below = problems are applicable for server-side DOTS gateway, it must convey the = =E2=80=9Cclient identity=E2=80=9D to the DOTS server.
I agree with = this server-side DOTS gateway case.
At the same time, I agree with = below:
> I agree that is not a good thing to = =E2=80=9Cleak=E2=80=9D out internal information when passing through a = DOTS GW,

Then, should DOTS GW send =E2=80=9Cclient = identity=E2=80=9D (i.e. certificates of DOTS clients) itself or = hashed(=E2=80=9Cclient identity=E2=80=9D) to DOTS server?
If later, = how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient = identity=E2=80=9D).

regards,
Kaname

On 2017/10/09 22:34, Konda, Tirumaleswar Reddy = wrote:

Hi = Jon,

 

I agree = the below problems are applicable for server-side DOTS gateway, it must = convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. But for = the client-side DOTS gateway, it should resolve conflicting rules b/w = DOTS clients (e.g. one client installing black-list ACL for an IP = address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, October 7, 2017 2:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_= Konda@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
S= ubject: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client.  =

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)     &nb= sp; The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)      = The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)     &nb= sp; The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely  associated with Client = Identity derived from the DOTS GW Client = certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).  This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.  The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.  Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= = Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:28
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, October 6, 2017 7:42 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= = Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 06 October 2017 14:58
To: = mohamed.boucadair@orange.com= ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: = [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 

-Tiru

 

________________=
_______________________________
Dots mailing =
list
Dots@ietf.org
https://www.ietf.org/=
mailman/listinfo/dots

 

------=_NextPart_000_0D8A_01D341CD.EF7F6100-- From nobody Tue Oct 10 05:58:02 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D63133020 for ; Tue, 10 Oct 2017 05:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axWqwxJyXiOr for ; Tue, 10 Oct 2017 05:57:57 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 3D761134504 for ; Tue, 10 Oct 2017 05:57:57 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e1u6c-0003FQ-01; Tue, 10 Oct 2017 13:57:54 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , "kaname nishizuka" , "Roland Dobbins" , References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> In-Reply-To: Date: Tue, 10 Oct 2017 13:57:56 +0100 Message-ID: <0da501d341c7$6460d000$2d227000$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0DA6_01D341CF.C627A900" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIAJQ6kjUASRe9X8Bri7ZGgMYlBpaAoe6cxMBQFNvqqJ3zaAA Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 12:58:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0DA6_01D341CF.C627A900 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 I am having trouble parsing this =E2=80=93 it is definition of terms = =E2=80=93 server and client when referring to DOTS Client, DOTS Server = and DOTS Gateway. I think there is a typo. [I many times have got = muddled in my thinking when referring to, say, DOTS GW client side = =E2=80=93 which actually is a DOTS server in its own rights.] =20 [TR] The DOTS client certificate may not fit within the path MTU. The = alternative approach is, the server-side DOTS GW computes SHA-256 of the = Subject Public Key Info (SPKI) of the client certificate and send the = hashed output to the DOTS server in the new client-id parameter (see = https://tools.ietf.org/html/rfc7469#section-2.4). SHA-256 is resistant = to collisions. Further, server-side DOTS gateway and DOTS server are in = the same domain operating the EST server, DOTS client will be using the = certificate provisioned by the EST server to authenticate itself to the = server-side DOTS gateway and I don=E2=80=99t see any ambiguous = information in the hashed client identity generated and conveyed by the = server-side DOTS gateway to the DOTS server. To me, server-side DOTS gateway definition is the upstream DOTS server = facing part of the DOTS Gateway =E2=80=93 c2 in =20 +-------------+ | | D | | +----+ | | O | | +----+ | c1 |----------| s1 | T | c2 |---------| s2 | +----+ | | S | | +----+ | | G | | +-------------+ https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-2.2.3= =20 Issue 1 =3D=3D=3D=3D=3D=3D=3D=3D So how does =E2=80=9CDOTS client will be using the certificate = provisioned by the EST server to authenticate itself to the server-side = DOTS gateway=E2=80=9D work? - ((c1) to (c2) is illegal!) =20 Issue 2 =3D=3D=3D=3D=3D =E2=80=9Cserver-side DOTS gateway and DOTS server are in the same domain = operating the EST server, DOTS client will be using the certificate = provisioned by the EST server=E2=80=9D =20 Whilst (c2) and (s2) will be in the same domain for mutual = authentication, the same is not necessarily true for (c1) and (s2). = However the use of SPKI will work if all the (c1) type clients talking = to (s1) are using PKI. If there is another trust mechanism for = (c1)<->((s1), then it is going to have to be a hash on something = different. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 12:53 To: kaname nishizuka; Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi Kaname, =20 Please see inline =20 From: Dots [ = mailto:dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: Tuesday, October 10, 2017 8:49 AM To: Konda, Tirumaleswar Reddy < = = TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow < = supjps-ietf@jpshallow.com>; = mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins < = rdobbins@arbor.net> Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi, > I agree the below problems are applicable for server-side DOTS = gateway, it must convey the =E2=80=9Cclient identity=E2=80=9D to the = DOTS server.=20 I agree with this server-side DOTS gateway case. At the same time, I agree with below: > I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW,=20 Then, should DOTS GW send =E2=80=9Cclient identity=E2=80=9D (i.e. = certificates of DOTS clients) itself or hashed(=E2=80=9Cclient = identity=E2=80=9D) to DOTS server? If later, how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient identity=E2=80=9D). [TR] The DOTS client certificate may not fit within the path MTU. The = alternative approach is, the server-side DOTS GW computes SHA-256 of the = Subject Public Key Info (SPKI) of the client certificate and send the = hashed output to the DOTS server in the new client-id parameter (see = https://tools.ietf.org/html/rfc7469#section-2.4). SHA-256 is resistant = to collisions. Further, server-side DOTS gateway and DOTS server are in = the same domain operating the EST server, DOTS client will be using the = certificate provisioned by the EST server to authenticate itself to the = server-side DOTS gateway and I don=E2=80=99t see any ambiguous = information in the hashed client identity generated and conveyed by the = server-side DOTS gateway to the DOTS server. -Tiru regards, Kaname On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote: Hi Jon, =20 I agree the below problems are applicable for server-side DOTS gateway, = it must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. = But for the client-side DOTS gateway, it should resolve conflicting = rules b/w DOTS clients (e.g. one client installing black-list ACL for an = IP address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server. =20 -Tiru =20 From: Jon Shallow [ = mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:07 PM To: Konda, Tirumaleswar Reddy = = ; = mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; = Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [ = mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy < = = TirumaleswarReddy_Konda@McAfee.com>; = mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins < = rdobbins@arbor.net> Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; = Jon Shallow; 'Dobbins, Roland'; dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru _______________________________________________ Dots mailing list Dots@ietf.org = https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0DA6_01D341CF.C627A900 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I am having trouble parsing this =E2=80=93 it is definition of terms = =E2=80=93 server and client when referring to DOTS Client, DOTS Server = and DOTS Gateway.=C2=A0 I think there is a typo.=C2=A0 [I many times = have got muddled in my thinking when referring to, say, DOTS GW client = side =E2=80=93 which actually is a DOTS server in its own = rights.]

 

[TR] The DOTS client certificate may not fit = within the path MTU. The alternative approach is, the server-side DOTS = GW computes SHA-256 of the Subject Public Key Info (SPKI) of the client = certificate and send the hashed output to the DOTS server in the new = client-id parameter (see https://tools.ie= tf.org/html/rfc7469#section-2.4). SHA-256 is resistant to = collisions. Further, server-side DOTS gateway and DOTS server are in the = same domain operating the EST server, DOTS client will be using the = certificate provisioned by the EST server to authenticate itself to the = server-side DOTS gateway and I don=E2=80=99t see any ambiguous = information in the hashed client identity generated and conveyed by the = server-side DOTS gateway to the DOTS server.

To me, server-side DOTS gateway definition is the = upstream DOTS server facing part of the DOTS Gateway =E2=80=93 c2 = in

 

=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=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+-------------+<= /p>

=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=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 | D |=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0 | O |=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | c1 = |----------| s1 | T | c2 |---------| s2 |

=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=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0 | S = |=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0 | G |=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=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 +-------------+

https://tools.ietf.org/html/draft-ietf-dots-architecture-04#sec= tion-2.2.3

 

Issue 1

=3D=3D=3D=3D=3D=3D=3D=3D

So how does =E2=80=9CDOTS client will be using the certificate = provisioned by the EST server to authenticate itself to the server-side = DOTS gateway=E2=80=9D work?

- ((c1) = to (c2) is illegal!)

 

Issue = 2

=3D=3D=3D=3D=3D

=E2=80=9Cserver-side DOTS gateway and DOTS = server are in the same domain operating the EST server, DOTS client will = be using the certificate provisioned by the EST = server=E2=80=9D

 

Whilst = (c2) and (s2) will be in the same domain for mutual authentication, the = same is not necessarily true for (c1) and (s2).=C2=A0 However the use of = SPKI will work if all the (c1) type clients talking to (s1) are using = PKI.=C2=A0 If there is another trust mechanism for (c1)<->((s1), = then it is going to have to be a hash on something = different.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy
Sent: 10 October 2017 12:53
To: = kaname nishizuka; Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS = Gateways Challenges

 

Hi Kaname,

 

Please see inline

 

From: Dots [mailto:dots= -bounces@ietf.org] On Behalf Of kaname nishizuka
Sent: Tuesday, = October 10, 2017 8:49 AM
To: Konda, Tirumaleswar Reddy = <Tirumaleswa= rReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf= @jpshallow.com>; mohamed.bou= cadair@orange.com; dots@ietf.o= rg; Roland Dobbins <rdobbins@ar= bor.net>
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi,

> I = agree the below problems are applicable for server-side DOTS gateway, it = must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. =
I agree with this server-side DOTS gateway case.
At the same = time, I agree with below:
> I agree that is not a good thing to = =E2=80=9Cleak=E2=80=9D out internal information when passing through a = DOTS GW,

Then, should DOTS GW send =E2=80=9Cclient = identity=E2=80=9D (i.e. certificates of DOTS clients) itself or = hashed(=E2=80=9Cclient identity=E2=80=9D) to DOTS server?
If later, = how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient identity=E2=80=9D).

[TR] The DOTS client certificate may not fit = within the path MTU. The alternative approach is, the server-side DOTS = GW computes SHA-256 of the Subject Public Key Info (SPKI) of the client = certificate and send the hashed output to the DOTS server in the new = client-id parameter (see https://tools.ie= tf.org/html/rfc7469#section-2.4). SHA-256 is resistant to = collisions. Further, server-side DOTS gateway and DOTS server are in the = same domain operating the EST server, DOTS client will be using the = certificate provisioned by the EST server to authenticate itself to the = server-side DOTS gateway and I don=E2=80=99t see any ambiguous = information in the hashed client identity generated and conveyed by the = server-side DOTS gateway to the DOTS server.

-Tiru

regards,
Kaname

On 2017/10/09 22:34, Konda, = Tirumaleswar Reddy wrote:

Hi = Jon,

 

I agree = the below problems are applicable for server-side DOTS gateway, it must = convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. But for = the client-side DOTS gateway, it should resolve conflicting rules b/w = DOTS clients (e.g. one client installing black-list ACL for an IP = address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supj= ps-ietf@jpshallow.com] =
Sent: Saturday, October 7, 2017 2:07 PM
To: Konda, = Tirumaleswar Reddy <Tirumal= eswarReddy_Konda@McAfee.com>; = mohamed.bou= cadair@orange.com; = dots@ietf.o= rg; Roland = Dobbins <rdobbin= s@arbor.net>
Subj= ect: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. 

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)     The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)    The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)     The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely  associated with Client = Identity derived from the DOTS GW Client certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).  This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.  The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.  Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces= @ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:28
To: Jon Shallow; mohamed.bouc= adair@orange.com; = dots@ietf.or= g; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supj= ps-ietf@jpshallow.com] =
Sent: Friday, October 6, 2017 7:42 PM
To: Konda, = Tirumaleswar Reddy <Tirumaleswa= rReddy_Konda@McAfee.com>; = mohamed.bou= cadair@orange.com; = dots@ietf.o= rg; Roland = Dobbins <rdobbins@ar= bor.net>
= Subject: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= Konda, = Tirumaleswar Reddy [mailto: Tirumaleswar= Reddy_Konda@mcafee.com] =
Sent: 06 October 2017 14:58
To: mohamed.bouc= adair@orange.com; Jon = Shallow; 'Dobbins, Roland'; dots@ietf.or= g
Subje= ct: RE: [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 

-Tiru



_______________________________________________
Dots mailing =
list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

 

------=_NextPart_000_0DA6_01D341CF.C627A900-- From nobody Tue Oct 10 07:17:38 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A29E134DEC for ; Tue, 10 Oct 2017 07:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.989 X-Spam-Level: X-Spam-Status: No, score=-6.989 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_KAM_HTML_FONT_INVALID=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=mcafee.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 vBM2yLgVSz7z for ; Tue, 10 Oct 2017 07:17:32 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 3023E132331 for ; Tue, 10 Oct 2017 07:15:49 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507644929; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=k y0uAUGQKBrzebWebGhiDC7y0ABXeeIaUBCdQud/rD M=; b=OnYO5QXpqTumi3TihGjPqTjayMyzXnNKFWdeDlJQehRV TU5EeYRXnQpirgNcrDA702GZqJtxN7iNz0i+S3q0tKFI+JNSoc YmDSIaY44c9vQcxkKfUQgY+BzLe2ZI/wfsIIuwSz8ICLToX8VI n8LwPNxwbFT2PEFPQgLWIIZvJA4= Received: from MIVEXAPP1N02.corpzone.internalzone.com (mivexapp1n02.corpzone.internalzone.com [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 1536_b844_e326bae6_1894_40a3_9d1e_26bce5db0c07; Tue, 10 Oct 2017 09:15:28 -0500 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 10:15:17 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Oct 2017 10:15:17 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 10:15:16 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 14:15:16 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 14:15:16 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , kaname nishizuka , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAACzkMAABuu0fgAB0EBwAADL1rgAAF4fWwAAEncgAAAJP24A== Date: Tue, 10 Oct 2017 14:15:16 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> In-Reply-To: <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.17.191] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:ej0ZanBB575Qg22qz/rKtwR5ziqVUmmqWKppHDd20UJqf+nldKSPX+doAX0fIbBDM1nPwnmrAauDkEdcFudUkTgxcR7Lf1bVPvyGnY8FozJpTZPy8MAqciZK7wArVDauwQIiHrHIdY0MOA/X10Ugu3CfiJkU3ePCMZrzQ8wgUmEyGsuO/uLUUUlCo9s++NsbmGMDI2RfTDMQJ0f53Sr3ixf055fFSQrDHZNHlTQdwz78sXWriUY2kx2dY6HQI1BnovlvtQOPKoh8jGtyXp3OPno0Bp/wx3SCv8LNQtRPTJCd3yJFEFjHr4sXCop0HMBL+5P6XPRIm7Th4CHgz404jA==; 5:R6Lc6gKeit5QsZ0iINbW5IB9vkBsHeOBDD4fMANA0U4p8r3cStyvN522QCZWwb9Fs5CEs5dC42R/KYyRkFirXAC3Yf/By5TRpb3YkTlmFgsxewOI0AZHzoSiitYMbY620lVBpyCFLxLSHl8YqWsXyd5vwmZz9fldmI/X/w3A3oU=; 24:Aetd2eXG7IEqW9AGDXm9DO2oWHO0p2xTMzBHZRNqfwHj09QJJBIE3LNXkzM6viXSJvqz/wLu6/y1zkeUUQ/Q9S9iOpJrcUAuN4gAolPcpo8=; 7:NyrU9V50naRAx7H9KE4VLxUp6wyFcClTgWkOOanhyU1TbRoiROf/PRzldY4kUOTeKMb5OnrRFSRnQKeqLRG8bwWamN1+xG3l7+WECuK+iSVk0tcs5gsDLDmDZ8ZBh8UGb5uZrr3XaoCFZ7e4iUQNEc000WzSTUfHT3yn5psPMiYmQ/MlugH7Nnz8144boQGhw2Oc+Yb3QgL0QbjX7NnpISbrx8P+NMeILD+5GsbYHBQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8db96879-e0a5-4e04-2973-08d50fe9547e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(32952001)(377454003)(189002)(199003)(24454002)(51444003)(53546010)(77096006)(80792005)(6506006)(606006)(236005)(99286003)(54896002)(966005)(9686003)(72206003)(53936002)(478600001)(2950100002)(14454004)(97736004)(6306002)(55016002)(6246003)(7696004)(81166006)(8676002)(7736002)(5660300001)(8936002)(25786009)(74316002)(81156014)(2906002)(3280700002)(2201001)(2501003)(3660700001)(33656002)(6436002)(2900100001)(106356001)(93886005)(102836003)(6116002)(229853002)(105586002)(3846002)(790700001)(86362001)(316002)(53946003)(68736007)(101416001)(50986999)(66066001)(189998001)(76176999)(54356999)(110136005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178891B6FD0CBB5AC5B18179EA750DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 14:15:16.1050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6117> : streams <1766655> : uri <2514292> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 14:17:37 -0000 --_000_DM5PR16MB178891B6FD0CBB5AC5B18179EA750DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgd2l0aCB5b3VyIHJlc3BvbnNlLCBjb25zaWRlciBhIGRlcGxveW1lbnQgd2hpY2ggaGFz IHRoZSBmb2xsb3dpbmcgRE9UUyBhZ2VudHMuDQoNCkRPVFMgY2xpZW50cyAoYzEpIDwtLS0tLS0t LS0tLS0tLS0tLS0tLT4gKHMxKSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgKGMyKSA8LS0tLS0t LS0tLS0tLS0tLT4gKHMyKSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgKGMzKSA8LS0tLS0tLS0t LS0tLS0+IChzMykgRE9UUyBzZXJ2ZXINCg0KTXkgcG9pbnQgaXMsIChjMikgbmVlZCBub3QgY29u dmV5IHRoZSDigJxjMSBpZGVudGl0eeKAnSB0byAoczIpIGJ1dCAoczIpIG5lZWRzIHRvIGNvbnZl eSB0aGUg4oCcYzIgaWRlbnRpdHnigJ0gdG8gKGMzKSBhbmQgKGMzKSBpbi10dXJuIHByb3BhZ2F0 ZXMgdGhlIOKAnGMyIGlkZW50aXR54oCdIHRvIChzMykuDQoNCi1UaXJ1DQoNCkZyb206IEpvbiBT aGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NClNlbnQ6IFR1ZXNkYXks IE9jdG9iZXIgMTAsIDIwMTcgNjoxNSBQTQ0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkg PFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyBrYW5hbWUgbmlzaGl6dWthIDxr YW5hbWVAbnR0djYuanA+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBkb3RzQGlldGYu b3JnOyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0Pg0KU3ViamVjdDogUkU6IFtE b3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KQWdyZWVkIHRoYXQg b25seSBhIERPVFMgR1cgc2VydmVyIGZhY2luZyBuZWVkcyB0byBzZW5kIGluZm9ybWF0aW9uIHRv IHRoZSB1cHN0cmVhbSBET1RTIFNlcnZlciDigJMgd2hpY2ggY291bGQgYWxzbyBiZSBhIERPVFMg R1cuDQogICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQogICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICB8IEQgfCAgICB8DQogICAgICAgICArLS0tLSsgICAgICAgICAg fCAgICB8IE8gfCAgICB8ICAgICAgICAgKy0tLS0rDQogICAgICAgICB8IGMxIHwtLS0tLS0tLS0t fCBzMSB8IFQgfCBjMiB8LS0tLS0tLS0tfCBzMiB8DQogICAgICAgICArLS0tLSsgICAgICAgICAg fCAgICB8IFMgfCAgICB8ICAgICAgICAgKy0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAg fCAgICB8IEcgfCAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0r DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLWFyY2hpdGVjdHVy ZS0wNCNzZWN0aW9uLTIuMi4zDQoNCkhvd2V2ZXIsIHRoZSBET1RTIEdXIGNsaWVudCBmYWNpbmcg KHMxKSBpcyB0aGUgb25lIHdpdGgga25vd2xlZGdlIG9mIHRoZSBpbmRpdmlkdWFsIGNsaWVudHMg dGhhdCBhcmUgY3VycmVudGx5IHVzaW5nICB0aGUgRE9UUyBzZXJ2ZXIgcnVubmluZyBvbiB0aGUg RE9UUyBHVy4gIFRoaXMgaW5mb3JtYXRpb24gaGFzIHRvIHNvbWVob3cgYmUgcGFzc2VkIG92ZXIg dG8gdGhlIERPVFMgR1cgc2VydmVyIGZhY2luZyAoYzIpLCBidXQgc2VwYXJhdGUgRE9UUyBzdGFj a3MgYXJlIGJlaW5nIHJ1biBmb3IgKHMxKSBhbmQgKGMyKSBhcyBwZXIgYXJjaGl0ZWN0dXJlIHNw ZWMgMi4yLjMuICBJIHdhcyByZWZlcnJpbmcgdG8gd2hhdCAoczEpIG1heSBuZWVkIHRvIHBhc3Mg b24gdG8gKGMyKSBpbiBteSBlbWFpbCByZXNwb25zZSB0byBLYW5hbWUsIG5vdCB3aGF0IGlzIHNl bnQgYnkgKGMxKS4NCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFpbHRvOiBkb3Rz LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAxMCBPY3RvYmVyIDIwMTcgMTM6 MTYNClRvOiBKb24gU2hhbGxvdzsgJ2thbmFtZSBuaXNoaXp1a2EnOyBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0Bp ZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zDQpTdWJqZWN0OiBS ZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpJIHRob3VnaHQgd2UgYWdyZWVk IHRoYXQgYmFzZWQgb24gdGhlIGN1cnJlbnQgRE9UUyByZXF1aXJlbWVudHMgb25seSB0aGUgc2Vy dmVyLXNpZGUgRE9UUyBHVyBuZWVkcyB0byBjb252ZXkgdGhlIERPVFMgY2xpZW50IChvciBjbGll bnQtc2lkZSBET1RTIFdHKSBpZGVudGl0eSB0byB0aGUgRE9UUyBzZXJ2ZXIuDQoNCi1UaXJ1DQoN CkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NClNl bnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgMjo1MyBQTQ0KVG86ICdrYW5hbWUgbmlzaGl6 dWthJyA8a2FuYW1lQG50dHY2LmpwPG1haWx0bzprYW5hbWVAbnR0djYuanA+PjsgS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTxtYWls dG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4+OyBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0Bp ZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0Bh cmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQpTdWJqZWN0OiBSRTogW0RvdHNd IERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSBLYW5hbWUsDQoNCkkgZG8gbm90IHRoaW5r IHRoYXQgaW5mb3JtYXRpb24gbmVjZXNzYXJpbHkgbmVlZHMgdG8gYmUgdGhlIG9yaWdpbmFsIGNs aWVudCBpZGVudGl0eS4gIFRoZSBHVyBDbGllbnQgc2lkZSB3aWxsIGhhdmUgaXRzIG93biBpZGVu dGl0eSB3aGljaCB0aGUgRE9UUyBTZXJ2ZXIgY2FuIHVzZSB0byBkaWZmZXJlbnRpYXRlIGJldHdl ZW4gRE9UUyAoR1cpIENsaWVudHMuDQoNClNvLCB5ZXMsIGEgaGFzaGVkIHNldCBvZiBuYW1lcyBj YW4gYmUgdXNlZCDigJMgaXQgaXMgdXAgdG8gdGhlIERPVFMgR1cgQ2xpZW50IHNpZGUgdG8gbWFr ZSBzdXJlIHRoYXQgdGhlcmUgYXJlIG5vIGhhc2ggY29sbGlzaW9ucy4gIE9yIGl0IGNvdWxkIGJl IGEgc2ltcGxlIGxpc3Qgc3VjaCBhcyBDMSwgQzIg4oCmQ24uDQoNClJlZ2FyZHMNCg0KSm9uDQoN CkZyb206IERvdHMgW21haWx0bzogZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJv dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yga2FuYW1lIG5pc2hpenVrYQ0KU2VudDogMTAg T2N0b2JlciAyMDE3IDA0OjE5DQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsgSm9uIFNo YWxsb3c7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9s YW5kIERvYmJpbnMNClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2Vz DQoNCkhpLA0KDQo+IEkgYWdyZWUgdGhlIGJlbG93IHByb2JsZW1zIGFyZSBhcHBsaWNhYmxlIGZv ciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IG11c3QgY29udmV5IHRoZSDigJxjbGllbnQg aWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLg0KSSBhZ3JlZSB3aXRoIHRoaXMgc2VydmVy LXNpZGUgRE9UUyBnYXRld2F5IGNhc2UuDQpBdCB0aGUgc2FtZSB0aW1lLCBJIGFncmVlIHdpdGgg YmVsb3c6DQo+IEkgYWdyZWUgdGhhdCBpcyBub3QgYSBnb29kIHRoaW5nIHRvIOKAnGxlYWvigJ0g b3V0IGludGVybmFsIGluZm9ybWF0aW9uIHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHVywN Cg0KVGhlbiwgc2hvdWxkIERPVFMgR1cgc2VuZCDigJxjbGllbnQgaWRlbnRpdHnigJ0gKGkuZS4g Y2VydGlmaWNhdGVzIG9mIERPVFMgY2xpZW50cykgaXRzZWxmIG9yIGhhc2hlZCjigJxjbGllbnQg aWRlbnRpdHnigJ0pIHRvIERPVFMgc2VydmVyPw0KSWYgbGF0ZXIsIGhvdyBjYW4gRE9UUyBzZXJ2 ZXIgcmVhY3QgdG8gdGhlIGFtYmlndW91cyBpbmZvcm1hdGlvbiBvZiB0aGUgaGFzaGVkKOKAnGNs aWVudCBpZGVudGl0eeKAnSkuDQoNCnJlZ2FyZHMsDQpLYW5hbWUNCk9uIDIwMTcvMTAvMDkgMjI6 MzQsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgd3JvdGU6DQpIaSBKb24sDQoNCkkgYWdyZWUg dGhlIGJlbG93IHByb2JsZW1zIGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdh dGV3YXksIGl0IG11c3QgY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERP VFMgc2VydmVyLiBCdXQgZm9yIHRoZSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksIGl0IHNob3Vs ZCByZXNvbHZlIGNvbmZsaWN0aW5nIHJ1bGVzIGIvdyBET1RTIGNsaWVudHMgKGUuZy4gb25lIGNs aWVudCBpbnN0YWxsaW5nIGJsYWNrLWxpc3QgQUNMIGZvciBhbiBJUCBhZGRyZXNzIGJ1dCB0aGUg b3RoZXIgY2xpZW50IGluc3RhbGxzIHdoaXRlLWxpc3QgQUNMIGZvciB0aGUgc2FtZSBJUCBhZGRy ZXNzLCBzYW1lIGFsaWFzLW5hbWVzIGZvciBkaWZmZXJlbnQgbWl0aWdhdGlvbiBzY29wZXMpLiBJ IGRvbuKAmXQgc2VlIHRoZSBuZWVkIGZvciBhIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBj b252ZXkgdGhlIOKAnGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgc2VydmVyLXNpZGUgRE9UUyBn YXRld2F5IG9yIERPVFMgc2VydmVyLg0KDQotVGlydQ0KDQpGcm9tOiBKb24gU2hhbGxvdyBbbWFp bHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciA3 LCAyMDE3IDI6MDcgUE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFA TWNBZmVlLmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3Jn PjsgUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD48bWFpbHRvOnJkb2JiaW5zQGFy Ym9yLm5ldD4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoN CkhpIFRpcnUsDQoNClRoaXMgZGlzY3Vzc2lvbiBnb2VzIGJleW9uZCBqdXN0IHRoZSBtaXRpZ2F0 aW9uIHJlcXVlc3QuICBXZSBuZWVkIHRvIGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3aXRoIGJvdGgg YWxpYXMtbmFtZSBhbmQgYWNsLW5hbWUgKGRhdGEgY2hhbm5lbCkNCg0KVGhlIHNpbXBsZSBjYXNl IG9mIGEgbWl0aWdhdGlvbiByZXF1ZXN0IHdpdGggbm8gYWxpYXMtbmFtZSBkb2VzIG5vdCByZXF1 aXJlIGFueSBrbm93bGVkZ2Ugb2YgdGhlIG9yaWdpbmFsIGNsaWVudC4NCg0KSG93ZXZlciwgaWYg dGhlIG1pdGlnYXRpb24gcmVxdWVzdCB1c2VzIGFsaWFzLW5hbWUsIHRoZW4gdGhlcmUgYXJlIDMg d2F5cyBvZiBoYW5kbGluZyB0aGlzDQoNCmEpICAgICAgIFRoZSBET1RTIEdXIHJlcGxhY2VzIHRo ZSBhbGlhcy1uYW1lIHdpdGggaXRzIGFjdHVhbCBkZWZpbml0aW9uICh0YXJnZXQtaXBzIGV0Yy4g bWVyZ2VkIGFzIGFwcHJvcHJpYXRlKSwgc28gYWxpYXMtbmFtZSBpcyBub3QgZm9yd2FyZGVkIG9u IHRvIFNlcnZlciDigJMganVzdCB0aGUgZXhwYW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGZv cndhcmRlZA0KDQpiKSAgICAgIFRoZSBET1RTIEdXIHVwZGF0ZXMgdGhlIGFsaWFzLW5hbWUgd2l0 aCBhIHVuaXF1ZSBhbGlhcy1uYW1lIHRoYXQgaXMgZm9yd2FyZGVkIChhbmQgaGFzIHRvIGRvIHRo ZSBzYW1lIHRoaW5nIHdoZW4gdGhlIGFsaWFzLW5hbWUgaXMgY29uZmlndXJlZCBvbiB0aGUgZGF0 YSBjaGFubmVsKSDigJMgdG8gaGFuZGxlIDIgb3IgbW9yZSBjbGllbnRzIGRlZmluaW5nIHRoZSBz YW1lIGFsaWFzLW5hbWUgd2hpY2ggaGF2ZSBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNzDQoNCmMp ICAgICAgIFRoZSBET1RTIEdXIHJlY29nbmlzZXMgdGhhdCBhbGlhcy1uYW1lIGlzIG5vdCB1bmlx dWUgYW5kIGFkZHMgaW4g4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSAoSSB0aGluayBJIHBy ZWZlciB0aGlzIOKAnC1pbmZv4oCdIG5hbWUgdG8gY2xpZW50LWlkIG9yIG9yaWdpbmFsLWNsaWVu dC1pZCBhcyDigJwtaWTigJ0gaXMgdG9vIGNsb3NlbHkgIGFzc29jaWF0ZWQgd2l0aCBDbGllbnQg SWRlbnRpdHkgZGVyaXZlZCBmcm9tIHRoZSBET1RTIEdXIENsaWVudCBjZXJ0aWZpY2F0ZSkNCldl IGhhdmUgYWdyZWVkIHRoYXQgd2hlbiBhIGNsaWVudCByZXF1ZXN0cyBtaXRpZ2F0aW9uIHN0YXR1 cywgdGhlIOKAnGFsaWFzLW5hbWXigJ0gc2hvdWxkIGJlIHJldHVybmVkIGFzIOKAnGFsaWFzLW5h bWXigJ0gYW5kIG5vdCB0aGUgc3Vic3RpdHV0ZWQgYWxpYXMtbmFtZSBjb25maWd1cmF0aW9uICh0 aGlzIGRvZXMgbmVlZCB0byBiZSBzdGF0ZWQgaW4gdGhlIHNwZWMgZm9yIGNsYXJpdHkpLiAgVGhp cyBtYWtlcyAoYSkgZGlmZmljdWx0IHRvIGJlIGhhbmRsZWQgYnkgRE9UUyBHVyB3aGljaCB0aGVu IHJhaXNlcyB0aGUgcXVlc3Rpb24g4oCTIGRvIHdlIHJlYWxseSBuZWVkIGFsaWFzLW5hbWU/DQoN ClRoZSBkZWZpbml0aW9uIGFuZCBhc3NvY2lhdGlvbiBvZiBBQ0xzL0ZpbHRlcnMgb2YgdGhlIGRh dGEgY2hhbm5lbCBpcyBtb3JlIGRpZmZpY3VsdCDigJMgdGhlIFNlcnZlciBtdXN0IGluc3RhbGwg LyBhcHBseSB0aGUgYXBwcm9wcmlhdGUgQUNMcyBvbiBhIHBlciAoT3JpZ2luYWwpIENsaWVudCBi YXNpcyB3aGVuIG1pdGlnYXRpb24gaXMgaW52b2tlZC4NCkNsaWVudCAx4oCZcyBjb25jZXB0IG9m IGEgV2hpdGVsaXN0IElQIGNvdWxkIGJlIENsaWVudCAy4oCZcyBjb25jZXB0IG9mIGEgQmxhY2ts aXN0IElQLiAgVGhlIFNlcnZlciBuZWVkcyB0byBrbm93IHdoaWNoIGNsaWVudCBpcyByZXF1ZXN0 aW5nIHRoZSBtaXRpZ2F0aW9uIGFuZCBpbnN0YWxsIHRoZSBjb3JyZWN0IEFDTHMg4oCTIGlmIHRo ZXJlIHdhcyBubyDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdLCB0aGUgU2VydmVyIG9ubHkg a25vd3MgdGhhdCBoZSBoYXMgdG8gaW5zdGFsbCBBTEwgb2YgdGhlIEFDTHMgKGkuZS4gYm90aCB0 aGUgQmxhY2sgYW5kIFdoaXRlIGxpc3Qgb2YgdGhlIHNhbWUgSVAgYXMgZGVmaW5lZCBieSBDbGll bnQgMSBhbmQgQ2xpZW50IDIpIGFzIGRlZmluZWQgYnkgaGlzIGNsaWVudCAoRE9UUyBHVykgd2hl biBoaXMgY2xpZW50IHJlcXVlc3RzIGEgbWl0aWdhdGlvbi4gIEhlcmUsIEkgdGhpbmsgdGhhdCBp ZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGNsaWVudCBmb3IgdGhlIERPVFMgR1csIOKAnWFkZGl0 aW9uYWwtY2xpZW50LWluZm/igJ0gaXMgcmVxdWlyZWQuDQoNClJlZ2FyZHMNCg0KSm9uDQoNCkZy b206IERvdHMgW21haWx0bzogZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KU2Vu dDogMDcgT2N0b2JlciAyMDE3IDA0OjI4DQpUbzogSm9uIFNoYWxsb3c7IG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3Rz QGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMNClN1YmplY3Q6 IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkluIGNhc2Ugb2YgY2xpZW50 LXNpZGUgRE9UUyBnYXRld2F5LCB3aHkgZG9lcyB0aGUgRE9UUyBzZXJ2ZXIgbmVlZCB0byBrbm93 IHdoaWNoIOKAnERPVFMgY2xpZW504oCdIGhhcyBjb252ZXllZCB0aGUgbWl0aWdhdGlvbiByZXF1 ZXN0ID8NCkZvciBleGFtcGxlLCB0aGUgRE9UUyBjbGllbnQgY291bGQgYmUgYSBERG9TIGRldGVj dG9yIG9yIGFuIEFwcGxpY2F0aW9uIHNlcnZlciwgYW5kIHRoZSBjbGllbnQtc2lkZSBnYXRld2F5 IHdpbGwgaGF2ZSB0byByZXNvbHZlIHRoZSBjb25mbGljdGluZyBtaXRpZ2F0aW9uIHJlcXVlc3Rz IGZyb20gdGhlIERPVFMgY2xpZW50cywgYWdncmVnYXRlIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3Rz IGZyb20gdGhlIERPVFMgY2xpZW50IGFuZCBzZW5kIHRoZSB1cGRhdGVkIG1pdGlnYXRpb24gcmVx dWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuDQoNCi1UaXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFtt YWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NClNlbnQ6IEZyaWRheSwgT2N0b2JlciA2 LCAyMDE3IDc6NDIgUE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBN Y0FmZWUuY29tPj47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3Jn PjsgUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJi b3IubmV0Pj4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoN CkhpIFRpcnUsDQoNClVubGVzcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBob3cgZG9lcyB0aGUg Q2xpZW50IHNpZGUgb2YgRE9UUyBHVyBjb252ZXkgdG8gdGhlIHVwc3RyZWFtIHNlcnZlciBhIHVu aXF1ZSDigJxjbGllbnQtaWTigJ0gd2hpY2ggaXMgZGlmZmVyZW50IHRvIHRoZSBpbXBsaWVkIGNs aWVudCBpZCBhcyBkZXJpdmVkIGZyb20gdGhlIFBLSSBjZXJ0aWZpY2F0ZSB0aGF0IHRoZSBET1RT IEdX4oCZQ2xpZW50IHVzZXMvcHJlc2VudHMgd2hlbiBjb21tdW5pY2F0aW5nIHRvIHRoZSBzZXJ2 ZXI/DQpUbyBtZSwgdGhlcmUgbmVlZHMgdG8gYmUgYW4gb3B0aW9uIHN1Y2ggYXMg4oCcb3JpZ2lu YWwtY2xpZW50LWlk4oCdIG9yIOKAnGNsaWVudC1pZOKAnSAod2hpY2ggaXMgY29uZnVzaW5nIHdo ZW4gYWxzbyByZWZlcnJpbmcgdG8gdGhlIGNsaWVudCBpZGVudGl0eSBhcyBkZXJpdmVkIGZyb20g dGhlIChET1RTIEdXKSBDbGllbnTigJlzIFBLSSBjZXJ0aWZpY2F0ZSkgYXMgYSBwYXJ0IG9mIHRo ZSBwcm90b2NvbC4NCg0KSSBhZ3JlZSB0aGF0IHRoZSBET1RTIEdXIGNhbiBnZW5lcmF0ZSBpdHMg b3duIHVuaXF1ZSBjbGllbnQtaWQgdG8gc3RvcCBtdWx0aXBsZSBlbnRyaWVzIGJlaW5nIG5lZWRl ZC4NCg0KSSBhZ3JlZSB0aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQg aW50ZXJuYWwgaW5mb3JtYXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLCBzbyBt eSBSRVFVSVJFRCBkb2VzIG5vdCBtYWtlIHNlbnNlLg0KDQpSZWdhcmRzDQoNCkpvbg0KUFMg4oCT IEkgYW0gaGF2aW5nIHRvIGRlYWwgd2l0aCBvdGhlciBzdHVmZiBhdCBwcmVzZW50IOKAkyBJIHdp bGwgZ2V0IGJhY2sgbGF0ZXIgb24gdGhlIG90aGVyIGlzc3VlcyB1bmRlciBkaXNjdXNzaW9uDQoN CkZyb206IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgW21haWx0bzogVGlydW1hbGVzd2FyUmVk ZHlfS29uZGFAbWNhZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVl LmNvbT5dDQpTZW50OiAwNiBPY3RvYmVyIDIwMTcgMTQ6NTgNClRvOiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgSm9uIFNo YWxsb3c7ICdEb2JiaW5zLCBSb2xhbmQnOyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYu b3JnPg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSSBk b27igJl0IHNlZSBhIG5lZWQgZm9yIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252ZXkg dGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4g4oCcRE9U UyBjbGllbnQgaWRlbnRpdHnigJ0gbG9va3MgcmVxdWlyZWQgb25seSBmb3IgdGhlIHNlcnZlci1z aWRlIERPVFMgZ2F0ZXdheXMuIEluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBp dCBjYW4gY29udmV5IHRoZSBjbGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xp ZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4g Z2VuZXJhdGUgYSB1bmlxdWUgY2xpZW50LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4g YXJyYXkgb2YgY2xpZW50LWlkcyB0byB0aGUgRE9UUyBzZXJ2ZXIgdG8gcmVzb2x2ZSBjbGFzaGVz Lg0KDQotVGlydQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCkRvdHMgbWFpbGluZyBsaXN0DQoNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNA aWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K DQo= --_000_DM5PR16MB178891B6FD0CBB5AC5B18179EA750DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1 IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7 DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNl cmlmOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFj azt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpi bGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBVSSIsc2Fu cy1zZXJpZjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRl IGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30N CnAuVGV4dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxsZXMNCgl7 bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRl IGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1h bDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVt YWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMzUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5BZ3JlZSB3aXRo IHlvdXIgcmVzcG9uc2UsIGNvbnNpZGVyIGEgZGVwbG95bWVudCB3aGljaCBoYXMgdGhlIGZvbGxv d2luZyBET1RTIGFnZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPkRPVFMgY2xpZW50cyAoYzEpDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOndpbmRvd3RleHQiPsOfPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4tLS0tLS0tLS0tLS0tLS0tPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xv cjp3aW5kb3d0ZXh0Ij7DoDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ DQogKHMxKSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgKGMyKSA8L3NwYW4+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjp3 aW5kb3d0ZXh0Ij7Dnzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+LS0t LS0tLS0tLS0tPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+w6A8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+KHMyKSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgKGMzKQ0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5n cztjb2xvcjp3aW5kb3d0ZXh0Ij7Dnzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+LS0tLS0tLS0tLTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPg0KIChzMykgRE9UUyBzZXJ2ZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPk15IHBvaW50IGlzLCAoYzIpIG5lZWQg bm90IGNvbnZleSB0aGUg4oCcYzEgaWRlbnRpdHnigJ0gdG8gKHMyKSBidXQgKHMyKSBuZWVkcyB0 byBjb252ZXkgdGhlIOKAnGMyIGlkZW50aXR54oCdIHRvIChjMykgYW5kIChjMykgaW4tdHVybiBw cm9wYWdhdGVzIHRoZSDigJxjMiBpZGVudGl0eeKAnQ0KIHRvIChzMykuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4tVGlydTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv YT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFu Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4g Sm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgNjoxNSBQTTxicj4NCjxiPlRvOjwv Yj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7VGlydW1hbGVzd2FyUmVkZHlfS29uZGFA TWNBZmVlLmNvbSZndDs7IGthbmFtZSBuaXNoaXp1a2EgJmx0O2thbmFtZUBudHR2Ni5qcCZndDs7 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IGRvdHNAaWV0Zi5vcmc7IFJvbGFuZCBEb2Ji aW5zICZsdDtyZG9iYmluc0BhcmJvci5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBb RG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5IaSBUaXJ1LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BZ3JlZWQgdGhhdCBvbmx5IGEgRE9UUyBHVyBz ZXJ2ZXIgZmFjaW5nIG5lZWRzIHRvIHNlbmQgaW5mb3JtYXRpb24gdG8gdGhlIHVwc3RyZWFtIERP VFMgU2VydmVyIOKAkyB3aGljaCBjb3VsZCBhbHNvIGJlIGEgRE9UUyBHVy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmIzQzOy0tLS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsgfCBEIHwmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgfCBPIHwmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmIzQzOy0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwg YzEgfC0tLS0tLS0tLS18IHMxIHwgVCB8IGMyIHwtLS0tLS0tLS18IHMyIHw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwg UyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwgRyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0tLS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1 cmUtMDQjc2VjdGlvbi0yLjIuMyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtZG90cy1hcmNoaXRlY3R1cmUtMDQjc2VjdGlvbi0yLjIuMzwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG93 ZXZlciwgdGhlIERPVFMgR1cgY2xpZW50IGZhY2luZyAoczEpIGlzIHRoZSBvbmUgd2l0aCBrbm93 bGVkZ2Ugb2YgdGhlIGluZGl2aWR1YWwgY2xpZW50cyB0aGF0IGFyZSBjdXJyZW50bHkgdXNpbmcg Jm5ic3A7dGhlIERPVFMgc2VydmVyIHJ1bm5pbmcgb24NCiB0aGUgRE9UUyBHVy4mbmJzcDsgVGhp cyBpbmZvcm1hdGlvbiBoYXMgdG8gc29tZWhvdyBiZSBwYXNzZWQgb3ZlciB0byB0aGUgRE9UUyBH VyBzZXJ2ZXIgZmFjaW5nIChjMiksIGJ1dCBzZXBhcmF0ZSBET1RTIHN0YWNrcyBhcmUgYmVpbmcg cnVuIGZvciAoczEpIGFuZCAoYzIpIGFzIHBlciBhcmNoaXRlY3R1cmUgc3BlYyAyLjIuMy4mbmJz cDsgSSB3YXMgcmVmZXJyaW5nIHRvIHdoYXQgKHMxKSBtYXkgbmVlZCB0byBwYXNzIG9uIHRvIChj MikgaW4gbXkgZW1haWwgcmVzcG9uc2UNCiB0byBLYW5hbWUsIG5vdCB3aGF0IGlzIHNlbnQgYnkg KGMxKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Kb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dCI+IERvdHMgW21haWx0bzoNCjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZg0K PC9iPktvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk8YnI+DQo8Yj5TZW50OjwvYj4gMTAgT2N0b2Jl ciAyMDE3IDEzOjE2PGJyPg0KPGI+VG86PC9iPiBKb24gU2hhbGxvdzsgJ2thbmFtZSBuaXNoaXp1 a2EnOyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5v cmciPmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmluczxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkkgdGhvdWdodCB3ZSBhZ3JlZWQgdGhhdCBi YXNlZCBvbiB0aGUgY3VycmVudCBET1RTIHJlcXVpcmVtZW50cyBvbmx5IHRoZSBzZXJ2ZXItc2lk ZSBET1RTIEdXIG5lZWRzIHRvIGNvbnZleSB0aGUgRE9UUyBjbGllbnQgKG9yIGNsaWVudC1zaWRl IERPVFMgV0cpIGlkZW50aXR5DQogdG8gdGhlIERPVFMgc2VydmVyLiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPi1UaXJ1PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEpvbiBTaGFsbG93IFs8YSBocmVmPSJtYWls dG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxv dy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcg Mjo1MyBQTTxicj4NCjxiPlRvOjwvYj4gJ2thbmFtZSBuaXNoaXp1a2EnICZsdDs8YSBocmVmPSJt YWlsdG86a2FuYW1lQG50dHY2LmpwIj5rYW5hbWVAbnR0djYuanA8L2E+Jmd0OzsgS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tv bmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+Jmd0 OzsNCjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmci Pg0KZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86 cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgS2FuYW1lLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGRvIG5vdCB0 aGluayB0aGF0IGluZm9ybWF0aW9uIG5lY2Vzc2FyaWx5IG5lZWRzIHRvIGJlIHRoZSBvcmlnaW5h bCBjbGllbnQgaWRlbnRpdHkuJm5ic3A7IFRoZSBHVyBDbGllbnQgc2lkZSB3aWxsIGhhdmUgaXRz IG93biBpZGVudGl0eSB3aGljaCB0aGUgRE9UUw0KIFNlcnZlciBjYW4gdXNlIHRvIGRpZmZlcmVu dGlhdGUgYmV0d2VlbiBET1RTIChHVykgQ2xpZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U28sIHllcywgYSBo YXNoZWQgc2V0IG9mIG5hbWVzIGNhbiBiZSB1c2VkIOKAkyBpdCBpcyB1cCB0byB0aGUgRE9UUyBH VyBDbGllbnQgc2lkZSB0byBtYWtlIHN1cmUgdGhhdCB0aGVyZSBhcmUgbm8gaGFzaCBjb2xsaXNp b25zLiZuYnNwOyBPciBpdCBjb3VsZCBiZQ0KIGEgc2ltcGxlIGxpc3Qgc3VjaCBhcyBDMSwgQzIg 4oCmQ24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOndpbmRvd3RleHQiPiBEb3RzIFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YN CjwvYj5rYW5hbWUgbmlzaGl6dWthPGJyPg0KPGI+U2VudDo8L2I+IDEwIE9jdG9iZXIgMjAxNyAw NDoxOTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsgSm9uIFNoYWxs b3c7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4NCm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9y ZyI+ZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5IaSw8YnI+DQo8YnI+ DQomZ3Q7IEkgYWdyZWUgdGhlIGJlbG93IHByb2JsZW1zIGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2 ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IG11c3QgY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRp dHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLg0KPGJyPg0KSSBhZ3JlZSB3aXRoIHRoaXMgc2VydmVy LXNpZGUgRE9UUyBnYXRld2F5IGNhc2UuPGJyPg0KQXQgdGhlIHNhbWUgdGltZSwgSSBhZ3JlZSB3 aXRoIGJlbG93Ojxicj4NCiZndDsgSSBhZ3JlZSB0aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g 4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5mb3JtYXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2gg YSBET1RTIEdXLA0KPGJyPg0KPGJyPg0KVGhlbiwgc2hvdWxkIERPVFMgR1cgc2VuZCDigJxjbGll bnQgaWRlbnRpdHnigJ0gKGkuZS4gY2VydGlmaWNhdGVzIG9mIERPVFMgY2xpZW50cykgaXRzZWxm IG9yIGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHnigJ0pIHRvIERPVFMgc2VydmVyPzxicj4NCklm IGxhdGVyLCBob3cgY2FuIERPVFMgc2VydmVyIHJlYWN0IHRvIHRoZSBhbWJpZ3VvdXMgaW5mb3Jt YXRpb24gb2YgdGhlIGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHnigJ0pLjxicj4NCjxicj4NCnJl Z2FyZHMsPGJyPg0KS2FuYW1lPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiAyMDE3LzEwLzA5IDIyOjM0LCBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5I aSBKb24sPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWdyZWUgdGhlIGJl bG93IHByb2JsZW1zIGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXks IGl0IG11c3QgY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2Vy dmVyLiBCdXQgZm9yIHRoZSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksDQogaXQgc2hvdWxkIHJl c29sdmUgY29uZmxpY3RpbmcgcnVsZXMgYi93IERPVFMgY2xpZW50cyAoZS5nLiBvbmUgY2xpZW50 IGluc3RhbGxpbmcgYmxhY2stbGlzdCBBQ0wgZm9yIGFuIElQIGFkZHJlc3MgYnV0IHRoZSBvdGhl ciBjbGllbnQgaW5zdGFsbHMgd2hpdGUtbGlzdCBBQ0wgZm9yIHRoZSBzYW1lIElQIGFkZHJlc3Ms IHNhbWUgYWxpYXMtbmFtZXMgZm9yIGRpZmZlcmVudCBtaXRpZ2F0aW9uIHNjb3BlcykuIEkgZG9u 4oCZdCBzZWUgdGhlIG5lZWQNCiBmb3IgYSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgdG8gY29u dmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0 ZXdheSBvciBET1RTIHNlcnZlci48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ LVRpcnU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEpvbiBTaGFsbG93IFs8YSBocmVm PSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+bWFpbHRvOnN1cGpwcy1pZXRmQGpw c2hhbGxvdy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBPY3RvYmVyIDcs IDIwMTcgMjowNyBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8 YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+DQombHQ7 VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSZndDs8L2E+OyA8YSBocmVmPSJtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8 L2E+OyBSb2xhbmQgRG9iYmlucw0KPGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+ Jmx0O3Jkb2JiaW5zQGFyYm9yLm5ldCZndDs8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBb RG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGkgVGlydSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgZGlzY3Vzc2lvbiBnb2VzIGJleW9uZCBqdXN0IHRoZSBt aXRpZ2F0aW9uIHJlcXVlc3QuJm5ic3A7IFdlIG5lZWQgdG8gY29uc2lkZXIgd2hhdCBoYXBwZW5z IHdpdGggYm90aCBhbGlhcy1uYW1lIGFuZCBhY2wtbmFtZSAoZGF0YSBjaGFubmVsKTwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhlIHNpbXBsZSBjYXNlIG9mIGEgbWl0aWdhdGlvbiByZXF1ZXN0IHdpdGggbm8gYWxpYXMtbmFt ZSBkb2VzIG5vdCByZXF1aXJlIGFueSBrbm93bGVkZ2Ugb2YgdGhlIG9yaWdpbmFsIGNsaWVudC4m bmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgaWYgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCB1c2VzIGFs aWFzLW5hbWUsIHRoZW4gdGhlcmUgYXJlIDMgd2F5cyBvZiBoYW5kbGluZyB0aGlzPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoZSBET1RTIEdXIHJlcGxhY2VzIHRoZSBhbGlhcy1uYW1lIHdpdGggaXRzIGFj dHVhbCBkZWZpbml0aW9uICh0YXJnZXQtaXBzIGV0Yy4gbWVyZ2VkIGFzIGFwcHJvcHJpYXRlKSwg c28gYWxpYXMtbmFtZSBpcyBub3QgZm9yd2FyZGVkIG9uIHRvIFNlcnZlciDigJMganVzdCB0aGUN CiBleHBhbmRlZCBtaXRpZ2F0aW9uIHJlcXVlc3QgaXMgZm9yd2FyZGVkPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5iKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo ZSBET1RTIEdXIHVwZGF0ZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBhIHVuaXF1ZSBhbGlhcy1uYW1l IHRoYXQgaXMgZm9yd2FyZGVkIChhbmQgaGFzIHRvIGRvIHRoZSBzYW1lIHRoaW5nIHdoZW4gdGhl IGFsaWFzLW5hbWUgaXMgY29uZmlndXJlZCBvbiB0aGUgZGF0YSBjaGFubmVsKQ0KIOKAkyB0byBo YW5kbGUgMiBvciBtb3JlIGNsaWVudHMgZGVmaW5pbmcgdGhlIHNhbWUgYWxpYXMtbmFtZSB3aGlj aCBoYXZlIGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPmMpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIERP VFMgR1cgcmVjb2duaXNlcyB0aGF0IGFsaWFzLW5hbWUgaXMgbm90IHVuaXF1ZSBhbmQgYWRkcyBp biDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdIChJIHRoaW5rIEkgcHJlZmVyIHRoaXMg4oCc LWluZm/igJ0gbmFtZSB0byBjbGllbnQtaWQgb3Igb3JpZ2luYWwtY2xpZW50LWlkDQogYXMg4oCc LWlk4oCdIGlzIHRvbyBjbG9zZWx5ICZuYnNwO2Fzc29jaWF0ZWQgd2l0aCBDbGllbnQgSWRlbnRp dHkgZGVyaXZlZCBmcm9tIHRoZSBET1RTIEdXIENsaWVudCBjZXJ0aWZpY2F0ZSk8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgaGF2ZSBh Z3JlZWQgdGhhdCB3aGVuIGEgY2xpZW50IHJlcXVlc3RzIG1pdGlnYXRpb24gc3RhdHVzLCB0aGUg 4oCcYWxpYXMtbmFtZeKAnSBzaG91bGQgYmUgcmV0dXJuZWQgYXMg4oCcYWxpYXMtbmFtZeKAnSBh bmQgbm90IHRoZSBzdWJzdGl0dXRlZCBhbGlhcy1uYW1lDQogY29uZmlndXJhdGlvbiAodGhpcyBk b2VzIG5lZWQgdG8gYmUgc3RhdGVkIGluIHRoZSBzcGVjIGZvciBjbGFyaXR5KS4mbmJzcDsgVGhp cyBtYWtlcyAoYSkgZGlmZmljdWx0IHRvIGJlIGhhbmRsZWQgYnkgRE9UUyBHVyB3aGljaCB0aGVu IHJhaXNlcyB0aGUgcXVlc3Rpb24g4oCTIGRvIHdlIHJlYWxseSBuZWVkIGFsaWFzLW5hbWU/PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5UaGUgZGVmaW5pdGlvbiBhbmQgYXNzb2NpYXRpb24gb2YgQUNMcy9GaWx0ZXJzIG9mIHRo ZSBkYXRhIGNoYW5uZWwgaXMgbW9yZSBkaWZmaWN1bHQg4oCTIHRoZSBTZXJ2ZXIgbXVzdCBpbnN0 YWxsIC8gYXBwbHkgdGhlIGFwcHJvcHJpYXRlIEFDTHMgb24gYQ0KIHBlciAoT3JpZ2luYWwpIENs aWVudCBiYXNpcyB3aGVuIG1pdGlnYXRpb24gaXMgaW52b2tlZC48L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2xpZW50IDHigJlzIGNvbmNl cHQgb2YgYSBXaGl0ZWxpc3QgSVAgY291bGQgYmUgQ2xpZW50IDLigJlzIGNvbmNlcHQgb2YgYSBC bGFja2xpc3QgSVAuJm5ic3A7IFRoZSBTZXJ2ZXIgbmVlZHMgdG8ga25vdyB3aGljaCBjbGllbnQg aXMgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbg0KIGFuZCBpbnN0YWxsIHRoZSBjb3JyZWN0IEFD THMg4oCTIGlmIHRoZXJlIHdhcyBubyDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdLCB0aGUg U2VydmVyIG9ubHkga25vd3MgdGhhdCBoZSBoYXMgdG8gaW5zdGFsbCBBTEwgb2YgdGhlIEFDTHMg KGkuZS4gYm90aCB0aGUgQmxhY2sgYW5kIFdoaXRlIGxpc3Qgb2YgdGhlIHNhbWUgSVAgYXMgZGVm aW5lZCBieSBDbGllbnQgMSBhbmQgQ2xpZW50IDIpIGFzIGRlZmluZWQgYnkgaGlzIGNsaWVudCAo RE9UUyBHVykNCiB3aGVuIGhpcyBjbGllbnQgcmVxdWVzdHMgYSBtaXRpZ2F0aW9uLiZuYnNwOyBI ZXJlLCBJIHRoaW5rIHRoYXQgaWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBjbGllbnQgZm9yIHRo ZSBET1RTIEdXLCDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdIGlzIHJlcXVpcmVkLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+UmVnYXJkczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Sm9uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IERvdHMgW21haWx0bzoNCjxh IGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRmLm9y ZzwvYT5dIDxiPk9uIEJlaGFsZiBPZg0KPC9iPktvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk8YnI+ DQo8Yj5TZW50OjwvYj4gMDcgT2N0b2JlciAyMDE3IDA0OjI4PGJyPg0KPGI+VG86PC9iPiBKb24g U2hhbGxvdzsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0 Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmluczxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J biBjYXNlIG9mIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgd2h5IGRvZXMgdGhlIERPVFMgc2Vy dmVyIG5lZWQgdG8ga25vdyB3aGljaCDigJxET1RTIGNsaWVudOKAnSBoYXMgY29udmV5ZWQgdGhl IG1pdGlnYXRpb24gcmVxdWVzdCA/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gb3IgZXhhbXBsZSwgdGhlIERPVFMgY2xpZW50IGNvdWxkIGJlIGEgRERvUyBkZXRl Y3RvciBvciBhbiBBcHBsaWNhdGlvbiBzZXJ2ZXIsIGFuZCB0aGUgY2xpZW50LXNpZGUgZ2F0ZXdh eSB3aWxsIGhhdmUgdG8gcmVzb2x2ZSB0aGUgY29uZmxpY3RpbmcgbWl0aWdhdGlvbiByZXF1ZXN0 cw0KIGZyb20gdGhlIERPVFMgY2xpZW50cywgYWdncmVnYXRlIHRoZSBtaXRpZ2F0aW9uIHJlcXVl c3RzIGZyb20gdGhlIERPVFMgY2xpZW50IGFuZCBzZW5kIHRoZSB1cGRhdGVkIG1pdGlnYXRpb24g cmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPi1UaXJ1PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb24gU2hhbGxvdyBb PGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20iPm1haWx0bzpzdXBqcHMt aWV0ZkBqcHNoYWxsb3cuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9i ZXIgNiwgMjAxNyA3OjQyIFBNPGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJl ZGR5ICZsdDs8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNv bSI+VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+DQpkb3RzQGlldGYu b3JnPC9hPjsgUm9sYW5kIERvYmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJv ci5uZXQiPnJkb2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJF OiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SGkgVGlydSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlVubGVzcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBob3cg ZG9lcyB0aGUgQ2xpZW50IHNpZGUgb2YgRE9UUyBHVyBjb252ZXkgdG8gdGhlIHVwc3RyZWFtIHNl cnZlciBhIHVuaXF1ZSDigJxjbGllbnQtaWTigJ0gd2hpY2ggaXMgZGlmZmVyZW50IHRvIHRoZSBp bXBsaWVkDQogY2xpZW50IGlkIGFzIGRlcml2ZWQgZnJvbSB0aGUgUEtJIGNlcnRpZmljYXRlIHRo YXQgdGhlIERPVFMgR1figJlDbGllbnQgdXNlcy9wcmVzZW50cyB3aGVuIGNvbW11bmljYXRpbmcg dG8gdGhlIHNlcnZlcj88L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VG8gbWUsIHRoZXJlIG5lZWRzIHRvIGJlIGFuIG9wdGlvbiBzdWNoIGFz IOKAnG9yaWdpbmFsLWNsaWVudC1pZOKAnSBvciDigJxjbGllbnQtaWTigJ0gKHdoaWNoIGlzIGNv bmZ1c2luZyB3aGVuIGFsc28gcmVmZXJyaW5nIHRvIHRoZSBjbGllbnQgaWRlbnRpdHkgYXMNCiBk ZXJpdmVkIGZyb20gdGhlIChET1RTIEdXKSBDbGllbnTigJlzIFBLSSBjZXJ0aWZpY2F0ZSkgYXMg YSBwYXJ0IG9mIHRoZSBwcm90b2NvbC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCB0aGUgRE9UUyBHVyBj YW4gZ2VuZXJhdGUgaXRzIG93biB1bmlxdWUgY2xpZW50LWlkIHRvIHN0b3AgbXVsdGlwbGUgZW50 cmllcyBiZWluZyBuZWVkZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgaXMgbm90IGEgZ29vZCB0aGlu ZyB0byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1hdGlvbiB3aGVuIHBhc3NpbmcgdGhy b3VnaCBhIERPVFMgR1csIHNvIG15IFJFUVVJUkVEIGRvZXMgbm90IG1ha2Ugc2Vuc2UuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5SZWdhcmRzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Kb248L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+UFMg4oCTIEkgYW0gaGF2aW5nIHRvIGRlYWwgd2l0aCBvdGhl ciBzdHVmZiBhdCBwcmVzZW50IOKAkyBJIHdpbGwgZ2V0IGJhY2sgbGF0ZXIgb24gdGhlIG90aGVy IGlzc3VlcyB1bmRlciBkaXNjdXNzaW9uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IEtvbmRhLCBUaXJ1bWFs ZXN3YXIgUmVkZHkgW21haWx0bzoNCjxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9L b25kYUBtY2FmZWUuY29tIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiAwNiBPY3RvYmVyIDIwMTcgMTQ6NTg8YnI+DQo8Yj5Ubzo8L2I+ IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgSm9uIFNoYWxsb3c7ICdEb2JiaW5zLCBSb2xhbmQnOw0K PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkkgZG9u4oCZdCBzZWUgYSBuZWVkIGZvciBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkg dG8gY29udmV5IHRoZSDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2 ZXIuIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIGxvb2tzIHJlcXVpcmVkIG9ubHkgZm9yIHRo ZSBzZXJ2ZXItc2lkZQ0KIERPVFMgZ2F0ZXdheXMuIEluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9U UyBnYXRld2F5LCBpdCBjYW4gY29udmV5IHRoZSBjbGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhl IOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMg Z2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1bmlxdWUgY2xpZW50LWlkIGFuZCBkb2VzIG5vdCBoYXZl IHRvIHNlbmQgYW4gYXJyYXkgb2YgY2xpZW50LWlkcyB0byB0aGUgRE9UUyBzZXJ2ZXINCiB0byBy ZXNvbHZlIGNsYXNoZXMuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tVGly dTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tR0IiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdC Ij5Eb3RzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1HQiI+PGEgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPkRvdHNAaWV0Zi5vcmc8 L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90czwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB178891B6FD0CBB5AC5B18179EA750DM5PR16MB1788namp_-- From nobody Tue Oct 10 07:35:22 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB97134290 for ; Tue, 10 Oct 2017 07:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.989 X-Spam-Level: X-Spam-Status: No, score=-6.989 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_KAM_HTML_FONT_INVALID=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=mcafee.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 k8Si4nr_5yFa for ; Tue, 10 Oct 2017 07:35:13 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 357D5134231 for ; Tue, 10 Oct 2017 07:35:13 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507646094; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=2 TknuCMUFLXhJJ8fI62piQ4DC04JYhQb3xvMDkQ4jz g=; b=Sc0lXKofbGl1sauIoABgh1cIzNeYfLGDxm+yw5vm1HG7 Eu9LENbC/uWrFzVW6RLSJo9OpGCZfyMlGz+8BGsGAhxuyiDDJo iwTnKAN6IpnbTjqKjRC0qPc3QXnEsniHe4firZJGbH7SImp6p/ FnJpNUbwOqF3TMjLPvcgaOZap1I= Received: from MIVEXAPP1N03.corpzone.internalzone.com (mivexapp1n03.corpzone.internalzone.com [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 1536_c31b_7c032b15_2161_4f8e_8870_3d99ced5db62; Tue, 10 Oct 2017 09:34:53 -0500 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 10:34:37 -0400 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 10:34:36 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Oct 2017 10:34:36 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 10:34:27 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 14:34:26 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 14:34:26 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" , kaname nishizuka , Roland Dobbins , "mohamed.boucadair@orange.com" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAACzkMAABuu0fgAB0EBwAABJ3VIAAPnrUAAALICxA= Date: Tue, 10 Oct 2017 14:34:26 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0da501d341c7$6460d000$2d227000$@jpshallow.com> In-Reply-To: <0da501d341c7$6460d000$2d227000$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.17.191] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:ruFbr+YeTyZw0QSM+Aq5yJHcraqztSoLPM1UmIoYUw8sFartbyDkFk0YrL0bRAZzpKJp6ezOpNnR7uLEbBBNzh+BVQWAWIe9RreSBQbuy/LmZ2/6e9VKWRfTphcQ1YtHNm2+jnRGCqNlxI7SCWupJkmxBfcaLWzuT8J1htMiZjp8pf9DcSMWrrM+f8zS8uqQNx1aZfsXCCje5aCr0wgvHfi1C+epf02XrmeyZAu7z3DFKCOo31MYUBGiyuIbLhOC5ZASQvXoOcQFMb3f9H+aXuNAcvXM/M//TN6JP4p31SDddl7HVJYYXioanTW63SSuPbpaRH35f414Xw+GOvAMvA==; 5:XhTki+B6yydFX9ROeCsVRP7R0pNeiqBHpPlo5/gtDAosUHLrAmLAljoexThfs+IAyAlDFaeoFr/pJv1p5sFbMy0dgpm9uoeqk+ioYAICTnaldvsCrsl27OfI+GV2o9V5LthdhIhxHkYr/6yfEfZ1xw==; 24:uVARg5WQcW7+QzNDFYODTRvfDOU7hl7t6Vjb25bgKcSYdMRzCzgDfYq3/VjEi5mArEsEfV9Lj+1cGge1mIqywftX5xsgXXD89BHeBM2hVOI=; 7:KQc8L88o/dzNjreipH6gxbTAIIB8yxBM/VJOqeZYsi2jx8giOLn17+7EUkIw4Hbug/TjUSucL3i73RngIvRLlQvQTjUPT3dRVwAFNvs7aNsPUo1vR0VALafI1zaXyJLhISCYfJXy9NAY9iYhRKJz25oyoYYchA+mixC98TOZtcU1OOq2D3Ytslm0VfJH4YX3E2A9XUUtlEOLSTTZEp7TUlPcr1SkCvOT42lhgzxLYD4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d500275e-c294-4124-66e7-08d50fec020c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(32952001)(377454003)(189002)(199003)(24454002)(51444003)(53546010)(80792005)(77096006)(6506006)(606006)(236005)(99286003)(54896002)(966005)(72206003)(53936002)(478600001)(9686003)(2950100002)(14454004)(97736004)(9326002)(6306002)(55016002)(6246003)(7696004)(81166006)(8676002)(8936002)(7736002)(5660300001)(74316002)(25786009)(81156014)(2906002)(3280700002)(2501003)(3660700001)(33656002)(6436002)(2900100001)(106356001)(86362001)(93886005)(6116002)(102836003)(229853002)(105586002)(3846002)(790700001)(316002)(53946003)(68736007)(101416001)(50986999)(66066001)(189998001)(76176999)(54356999)(110136005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788BAC514615AF5F13D161DEA750DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 14:34:26.3233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6117> : streams <1766657> : uri <2514297> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 14:35:21 -0000 --_000_DM5PR16MB1788BAC514615AF5F13D161DEA750DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uLA0KDQpQbGVhc2Ugc2VlIGlubGluZQ0KDQpGcm9tOiBKb24gU2hhbGxvdyBbbWFpbHRv OnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDEwLCAy MDE3IDY6MjggUE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsgZG90c0BpZXRmLm9yZzsga2FuYW1lIG5pc2hpenVrYSA8 a2FuYW1lQG50dHY2LmpwPjsgUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD47IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyBHYXRl d2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUsDQoNCkkgYW0gaGF2aW5nIHRyb3VibGUgcGFyc2lu ZyB0aGlzIOKAkyBpdCBpcyBkZWZpbml0aW9uIG9mIHRlcm1zIOKAkyBzZXJ2ZXIgYW5kIGNsaWVu dCB3aGVuIHJlZmVycmluZyB0byBET1RTIENsaWVudCwgRE9UUyBTZXJ2ZXIgYW5kIERPVFMgR2F0 ZXdheS4gIEkgdGhpbmsgdGhlcmUgaXMgYSB0eXBvLiAgW0kgbWFueSB0aW1lcyBoYXZlIGdvdCBt dWRkbGVkIGluIG15IHRoaW5raW5nIHdoZW4gcmVmZXJyaW5nIHRvLCBzYXksIERPVFMgR1cgY2xp ZW50IHNpZGUg4oCTIHdoaWNoIGFjdHVhbGx5IGlzIGEgRE9UUyBzZXJ2ZXIgaW4gaXRzIG93biBy aWdodHMuXQ0KDQpbVFJdIFRoZSBET1RTIGNsaWVudCBjZXJ0aWZpY2F0ZSBtYXkgbm90IGZpdCB3 aXRoaW4gdGhlIHBhdGggTVRVLiBUaGUgYWx0ZXJuYXRpdmUgYXBwcm9hY2ggaXMsIHRoZSBzZXJ2 ZXItc2lkZSBET1RTIEdXIGNvbXB1dGVzIFNIQS0yNTYgb2YgdGhlIFN1YmplY3QgUHVibGljIEtl eSBJbmZvIChTUEtJKSBvZiB0aGUgY2xpZW50IGNlcnRpZmljYXRlIGFuZCBzZW5kIHRoZSBoYXNo ZWQgb3V0cHV0IHRvIHRoZSBET1RTIHNlcnZlciBpbiB0aGUgbmV3IGNsaWVudC1pZCBwYXJhbWV0 ZXIgKHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzQ2OSNzZWN0aW9uLTIuNCku IFNIQS0yNTYgaXMgcmVzaXN0YW50IHRvIGNvbGxpc2lvbnMuIEZ1cnRoZXIsIHNlcnZlci1zaWRl IERPVFMgZ2F0ZXdheSBhbmQgRE9UUyBzZXJ2ZXIgYXJlIGluIHRoZSBzYW1lIGRvbWFpbiBvcGVy YXRpbmcgdGhlIEVTVCBzZXJ2ZXIsIERPVFMgY2xpZW50IHdpbGwgYmUgdXNpbmcgdGhlIGNlcnRp ZmljYXRlIHByb3Zpc2lvbmVkIGJ5IHRoZSBFU1Qgc2VydmVyIHRvIGF1dGhlbnRpY2F0ZSBpdHNl bGYgdG8gdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBhbmQgSSBkb27igJl0IHNlZSBhbnkg YW1iaWd1b3VzIGluZm9ybWF0aW9uIGluIHRoZSBoYXNoZWQgY2xpZW50IGlkZW50aXR5IGdlbmVy YXRlZCBhbmQgY29udmV5ZWQgYnkgdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSB0byB0aGUg RE9UUyBzZXJ2ZXIuDQpUbyBtZSwgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGRlZmluaXRpb24g aXMgdGhlIHVwc3RyZWFtIERPVFMgc2VydmVyIGZhY2luZyBwYXJ0IG9mIHRoZSBET1RTIEdhdGV3 YXkg4oCTIGMyIGluDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsN CiAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwgRCB8ICAgIHwNCiAgICAgICAgICstLS0t KyAgICAgICAgICB8ICAgIHwgTyB8ICAgIHwgICAgICAgICArLS0tLSsNCiAgICAgICAgIHwgYzEg fC0tLS0tLS0tLS18IHMxIHwgVCB8IGMyIHwtLS0tLS0tLS18IHMyIHwNCiAgICAgICAgICstLS0t KyAgICAgICAgICB8ICAgIHwgUyB8ICAgIHwgICAgICAgICArLS0tLSsNCiAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgIHwgRyB8ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLSsNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMt YXJjaGl0ZWN0dXJlLTA0I3NlY3Rpb24tMi4yLjMNCg0KSXNzdWUgMQ0KPT09PT09PT0NClNvIGhv dyBkb2VzIOKAnERPVFMgY2xpZW50IHdpbGwgYmUgdXNpbmcgdGhlIGNlcnRpZmljYXRlIHByb3Zp c2lvbmVkIGJ5IHRoZSBFU1Qgc2VydmVyIHRvIGF1dGhlbnRpY2F0ZSBpdHNlbGYgdG8gdGhlIHNl cnZlci1zaWRlIERPVFMgZ2F0ZXdheeKAnSB3b3JrPw0KLSAoKGMxKSB0byAoYzIpIGlzIGlsbGVn YWwhKQ0KDQpbVFJdIGMxIGF1dGhlbnRpY2F0ZXMgdG8gczEgdXNpbmcgdGhlIGNlcnRpZmljYXRl IGl0IHJlY2VpdmVkIGZyb20gdGhlIEVTVCBzZXJ2ZXIgaW4gdGhlIHNhbWUgZG9tYWluIGFzIHMx LCBjMiBhbmQgczIuDQoNCklzc3VlIDINCj09PT09DQrigJxzZXJ2ZXItc2lkZSBET1RTIGdhdGV3 YXkgYW5kIERPVFMgc2VydmVyIGFyZSBpbiB0aGUgc2FtZSBkb21haW4gb3BlcmF0aW5nIHRoZSBF U1Qgc2VydmVyLCBET1RTIGNsaWVudCB3aWxsIGJlIHVzaW5nIHRoZSBjZXJ0aWZpY2F0ZSBwcm92 aXNpb25lZCBieSB0aGUgRVNUIHNlcnZlcuKAnQ0KDQpXaGlsc3QgKGMyKSBhbmQgKHMyKSB3aWxs IGJlIGluIHRoZSBzYW1lIGRvbWFpbiBmb3IgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCB0aGUgc2Ft ZSBpcyBub3QgbmVjZXNzYXJpbHkgdHJ1ZSBmb3IgKGMxKSBhbmQgKHMyKS4NCg0KDQpIb3dldmVy IHRoZSB1c2Ugb2YgU1BLSSB3aWxsIHdvcmsgaWYgYWxsIHRoZSAoYzEpIHR5cGUgY2xpZW50cyB0 YWxraW5nIHRvIChzMSkgYXJlIHVzaW5nIFBLSS4NCg0KW1RSXSBUaGUgYXNzdW1wdGlvbiBpcyBE T1RTIGFnZW50cyBpbiBkaWZmZXJlbnQgZG9tYWlucyBtdXN0IHVzZSBQS0kgZm9yIG11dHVhbCBh dXRoZW50aWNhdGlvbi4NCg0KSWYgdGhlcmUgaXMgYW5vdGhlciB0cnVzdCBtZWNoYW5pc20gZm9y IChjMSk8LT4oKHMxKSwgdGhlbiBpdCBpcyBnb2luZyB0byBoYXZlIHRvIGJlIGEgaGFzaCBvbiBz b21ldGhpbmcgZGlmZmVyZW50Lg0KDQpbVFJdIFllcywgd2UgY2FuIHByb3Bvc2UgU1BLSSBhcyBv bmUgbWVjaGFuaXNtcyAoc2luY2UgczEsIGMyIGFuZCBzMyBhcmUgaW4gdGhlIHNhbWUgZG9tYWlu LCB0aGV5IGFsbCB3aWxsIGJlIGF3YXJlIG9mIHRoZSBhbHRlcm5hdGUgdHJ1c3QgbWVjaGFuaXNt KS4NCg0KLVRpcnUNCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFpbHRvOiBkb3Rz LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAxMCBPY3RvYmVyIDIwMTcgMTI6 NTMNClRvOiBrYW5hbWUgbmlzaGl6dWthOyBKb24gU2hhbGxvdzsgbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0 Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucw0KU3ViamVjdDogUmU6 IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgS2FuYW1lLA0KDQpQbGVhc2Ug c2VlIGlubGluZQ0KDQpGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2Yga2FuYW1lIG5pc2hpenVrYQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMCwg MjAxNyA4OjQ5IEFNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2Fy UmVkZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNB ZmVlLmNvbT4+OyBKb24gU2hhbGxvdyA8c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTxtYWlsdG86 c3VwanBzLWlldGZAanBzaGFsbG93LmNvbT4+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWls dG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFp bHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQpTdWJqZWN0OiBSZTogW0RvdHNdIERPVFMgR2F0ZXdh eXMgQ2hhbGxlbmdlcw0KDQpIaSwNCg0KPiBJIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUg YXBwbGljYWJsZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0 aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4NCkkgYWdyZWUgd2l0 aCB0aGlzIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBjYXNlLg0KQXQgdGhlIHNhbWUgdGltZSwg SSBhZ3JlZSB3aXRoIGJlbG93Og0KPiBJIGFncmVlIHRoYXQgaXMgbm90IGEgZ29vZCB0aGluZyB0 byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1hdGlvbiB3aGVuIHBhc3NpbmcgdGhyb3Vn aCBhIERPVFMgR1csDQoNClRoZW4sIHNob3VsZCBET1RTIEdXIHNlbmQg4oCcY2xpZW50IGlkZW50 aXR54oCdIChpLmUuIGNlcnRpZmljYXRlcyBvZiBET1RTIGNsaWVudHMpIGl0c2VsZiBvciBoYXNo ZWQo4oCcY2xpZW50IGlkZW50aXR54oCdKSB0byBET1RTIHNlcnZlcj8NCklmIGxhdGVyLCBob3cg Y2FuIERPVFMgc2VydmVyIHJlYWN0IHRvIHRoZSBhbWJpZ3VvdXMgaW5mb3JtYXRpb24gb2YgdGhl IGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHnigJ0pLg0KW1RSXSBUaGUgRE9UUyBjbGllbnQgY2Vy dGlmaWNhdGUgbWF5IG5vdCBmaXQgd2l0aGluIHRoZSBwYXRoIE1UVS4gVGhlIGFsdGVybmF0aXZl IGFwcHJvYWNoIGlzLCB0aGUgc2VydmVyLXNpZGUgRE9UUyBHVyBjb21wdXRlcyBTSEEtMjU2IG9m IHRoZSBTdWJqZWN0IFB1YmxpYyBLZXkgSW5mbyAoU1BLSSkgb2YgdGhlIGNsaWVudCBjZXJ0aWZp Y2F0ZSBhbmQgc2VuZCB0aGUgaGFzaGVkIG91dHB1dCB0byB0aGUgRE9UUyBzZXJ2ZXIgaW4gdGhl IG5ldyBjbGllbnQtaWQgcGFyYW1ldGVyIChzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc0Njkjc2VjdGlvbi0yLjQpLiBTSEEtMjU2IGlzIHJlc2lzdGFudCB0byBjb2xsaXNpb25z LiBGdXJ0aGVyLCBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgYW5kIERPVFMgc2VydmVyIGFyZSBp biB0aGUgc2FtZSBkb21haW4gb3BlcmF0aW5nIHRoZSBFU1Qgc2VydmVyLCBET1RTIGNsaWVudCB3 aWxsIGJlIHVzaW5nIHRoZSBjZXJ0aWZpY2F0ZSBwcm92aXNpb25lZCBieSB0aGUgRVNUIHNlcnZl ciB0byBhdXRoZW50aWNhdGUgaXRzZWxmIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkg YW5kIEkgZG9u4oCZdCBzZWUgYW55IGFtYmlndW91cyBpbmZvcm1hdGlvbiBpbiB0aGUgaGFzaGVk IGNsaWVudCBpZGVudGl0eSBnZW5lcmF0ZWQgYW5kIGNvbnZleWVkIGJ5IHRoZSBzZXJ2ZXItc2lk ZSBET1RTIGdhdGV3YXkgdG8gdGhlIERPVFMgc2VydmVyLg0KLVRpcnUNCg0KcmVnYXJkcywNCkth bmFtZQ0KT24gMjAxNy8xMC8wOSAyMjozNCwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSB3cm90 ZToNCkhpIEpvbiwNCg0KSSBhZ3JlZSB0aGUgYmVsb3cgcHJvYmxlbXMgYXJlIGFwcGxpY2FibGUg Zm9yIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgbXVzdCBjb252ZXkgdGhlIOKAnGNsaWVu dCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIEJ1dCBmb3IgdGhlIGNsaWVudC1zaWRl IERPVFMgZ2F0ZXdheSwgaXQgc2hvdWxkIHJlc29sdmUgY29uZmxpY3RpbmcgcnVsZXMgYi93IERP VFMgY2xpZW50cyAoZS5nLiBvbmUgY2xpZW50IGluc3RhbGxpbmcgYmxhY2stbGlzdCBBQ0wgZm9y IGFuIElQIGFkZHJlc3MgYnV0IHRoZSBvdGhlciBjbGllbnQgaW5zdGFsbHMgd2hpdGUtbGlzdCBB Q0wgZm9yIHRoZSBzYW1lIElQIGFkZHJlc3MsIHNhbWUgYWxpYXMtbmFtZXMgZm9yIGRpZmZlcmVu dCBtaXRpZ2F0aW9uIHNjb3BlcykuIEkgZG9u4oCZdCBzZWUgdGhlIG5lZWQgZm9yIGEgY2xpZW50 LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRv IHRoZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgb3IgRE9UUyBzZXJ2ZXIuDQoNCi1UaXJ1DQoN CkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NClNl bnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDcsIDIwMTcgMjowNyBQTQ0KVG86IEtvbmRhLCBUaXJ1bWFs ZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PG1haWx0bzpU aXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsgbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5v cmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3Iu bmV0PjxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RT IEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KVGhpcyBkaXNjdXNzaW9uIGdvZXMg YmV5b25kIGp1c3QgdGhlIG1pdGlnYXRpb24gcmVxdWVzdC4gIFdlIG5lZWQgdG8gY29uc2lkZXIg d2hhdCBoYXBwZW5zIHdpdGggYm90aCBhbGlhcy1uYW1lIGFuZCBhY2wtbmFtZSAoZGF0YSBjaGFu bmVsKQ0KDQpUaGUgc2ltcGxlIGNhc2Ugb2YgYSBtaXRpZ2F0aW9uIHJlcXVlc3Qgd2l0aCBubyBh bGlhcy1uYW1lIGRvZXMgbm90IHJlcXVpcmUgYW55IGtub3dsZWRnZSBvZiB0aGUgb3JpZ2luYWwg Y2xpZW50Lg0KDQpIb3dldmVyLCBpZiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0IHVzZXMgYWxpYXMt bmFtZSwgdGhlbiB0aGVyZSBhcmUgMyB3YXlzIG9mIGhhbmRsaW5nIHRoaXMNCg0KYSkgICAgIFRo ZSBET1RTIEdXIHJlcGxhY2VzIHRoZSBhbGlhcy1uYW1lIHdpdGggaXRzIGFjdHVhbCBkZWZpbml0 aW9uICh0YXJnZXQtaXBzIGV0Yy4gbWVyZ2VkIGFzIGFwcHJvcHJpYXRlKSwgc28gYWxpYXMtbmFt ZSBpcyBub3QgZm9yd2FyZGVkIG9uIHRvIFNlcnZlciDigJMganVzdCB0aGUgZXhwYW5kZWQgbWl0 aWdhdGlvbiByZXF1ZXN0IGlzIGZvcndhcmRlZA0KDQpiKSAgICBUaGUgRE9UUyBHVyB1cGRhdGVz IHRoZSBhbGlhcy1uYW1lIHdpdGggYSB1bmlxdWUgYWxpYXMtbmFtZSB0aGF0IGlzIGZvcndhcmRl ZCAoYW5kIGhhcyB0byBkbyB0aGUgc2FtZSB0aGluZyB3aGVuIHRoZSBhbGlhcy1uYW1lIGlzIGNv bmZpZ3VyZWQgb24gdGhlIGRhdGEgY2hhbm5lbCkg4oCTIHRvIGhhbmRsZSAyIG9yIG1vcmUgY2xp ZW50cyBkZWZpbmluZyB0aGUgc2FtZSBhbGlhcy1uYW1lIHdoaWNoIGhhdmUgZGlmZmVyZW50IGNo YXJhY3RlcmlzdGljcw0KDQpjKSAgICAgVGhlIERPVFMgR1cgcmVjb2duaXNlcyB0aGF0IGFsaWFz LW5hbWUgaXMgbm90IHVuaXF1ZSBhbmQgYWRkcyBpbiDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv 4oCdIChJIHRoaW5rIEkgcHJlZmVyIHRoaXMg4oCcLWluZm/igJ0gbmFtZSB0byBjbGllbnQtaWQg b3Igb3JpZ2luYWwtY2xpZW50LWlkIGFzIOKAnC1pZOKAnSBpcyB0b28gY2xvc2VseSAgYXNzb2Np YXRlZCB3aXRoIENsaWVudCBJZGVudGl0eSBkZXJpdmVkIGZyb20gdGhlIERPVFMgR1cgQ2xpZW50 IGNlcnRpZmljYXRlKQ0KV2UgaGF2ZSBhZ3JlZWQgdGhhdCB3aGVuIGEgY2xpZW50IHJlcXVlc3Rz IG1pdGlnYXRpb24gc3RhdHVzLCB0aGUg4oCcYWxpYXMtbmFtZeKAnSBzaG91bGQgYmUgcmV0dXJu ZWQgYXMg4oCcYWxpYXMtbmFtZeKAnSBhbmQgbm90IHRoZSBzdWJzdGl0dXRlZCBhbGlhcy1uYW1l IGNvbmZpZ3VyYXRpb24gKHRoaXMgZG9lcyBuZWVkIHRvIGJlIHN0YXRlZCBpbiB0aGUgc3BlYyBm b3IgY2xhcml0eSkuICBUaGlzIG1ha2VzIChhKSBkaWZmaWN1bHQgdG8gYmUgaGFuZGxlZCBieSBE T1RTIEdXIHdoaWNoIHRoZW4gcmFpc2VzIHRoZSBxdWVzdGlvbiDigJMgZG8gd2UgcmVhbGx5IG5l ZWQgYWxpYXMtbmFtZT8NCg0KVGhlIGRlZmluaXRpb24gYW5kIGFzc29jaWF0aW9uIG9mIEFDTHMv RmlsdGVycyBvZiB0aGUgZGF0YSBjaGFubmVsIGlzIG1vcmUgZGlmZmljdWx0IOKAkyB0aGUgU2Vy dmVyIG11c3QgaW5zdGFsbCAvIGFwcGx5IHRoZSBhcHByb3ByaWF0ZSBBQ0xzIG9uIGEgcGVyIChP cmlnaW5hbCkgQ2xpZW50IGJhc2lzIHdoZW4gbWl0aWdhdGlvbiBpcyBpbnZva2VkLg0KQ2xpZW50 IDHigJlzIGNvbmNlcHQgb2YgYSBXaGl0ZWxpc3QgSVAgY291bGQgYmUgQ2xpZW50IDLigJlzIGNv bmNlcHQgb2YgYSBCbGFja2xpc3QgSVAuICBUaGUgU2VydmVyIG5lZWRzIHRvIGtub3cgd2hpY2gg Y2xpZW50IGlzIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24gYW5kIGluc3RhbGwgdGhlIGNvcnJl Y3QgQUNMcyDigJMgaWYgdGhlcmUgd2FzIG5vIOKAnWFkZGl0aW9uYWwtY2xpZW50LWluZm/igJ0s IHRoZSBTZXJ2ZXIgb25seSBrbm93cyB0aGF0IGhlIGhhcyB0byBpbnN0YWxsIEFMTCBvZiB0aGUg QUNMcyAoaS5lLiBib3RoIHRoZSBCbGFjayBhbmQgV2hpdGUgbGlzdCBvZiB0aGUgc2FtZSBJUCBh cyBkZWZpbmVkIGJ5IENsaWVudCAxIGFuZCBDbGllbnQgMikgYXMgZGVmaW5lZCBieSBoaXMgY2xp ZW50IChET1RTIEdXKSB3aGVuIGhpcyBjbGllbnQgcmVxdWVzdHMgYSBtaXRpZ2F0aW9uLiAgSGVy ZSwgSSB0aGluayB0aGF0IGlmIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgY2xpZW50IGZvciB0aGUg RE9UUyBHVywg4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSBpcyByZXF1aXJlZC4NCg0KUmVn YXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBLb25kYSwgVGlydW1h bGVzd2FyIFJlZGR5DQpTZW50OiAwNyBPY3RvYmVyIDIwMTcgMDQ6MjgNClRvOiBKb24gU2hhbGxv dzsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQg RG9iYmlucw0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0K SW4gY2FzZSBvZiBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksIHdoeSBkb2VzIHRoZSBET1RTIHNl cnZlciBuZWVkIHRvIGtub3cgd2hpY2gg4oCcRE9UUyBjbGllbnTigJ0gaGFzIGNvbnZleWVkIHRo ZSBtaXRpZ2F0aW9uIHJlcXVlc3QgPw0KRm9yIGV4YW1wbGUsIHRoZSBET1RTIGNsaWVudCBjb3Vs ZCBiZSBhIEREb1MgZGV0ZWN0b3Igb3IgYW4gQXBwbGljYXRpb24gc2VydmVyLCBhbmQgdGhlIGNs aWVudC1zaWRlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHJlc29sdmUgdGhlIGNvbmZsaWN0aW5nIG1p dGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBjbGllbnRzLCBhZ2dyZWdhdGUgdGhlIG1p dGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBjbGllbnQgYW5kIHNlbmQgdGhlIHVwZGF0 ZWQgbWl0aWdhdGlvbiByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4NCg0KLVRpcnUNCg0KRnJv bTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KU2VudDog RnJpZGF5LCBPY3RvYmVyIDYsIDIwMTcgNzo0MiBQTQ0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFp bHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1h aWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTIEdhdGV3 YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KVW5sZXNzIEkgYW0gbWlzc2luZyBzb21ldGhp bmcsIGhvdyBkb2VzIHRoZSBDbGllbnQgc2lkZSBvZiBET1RTIEdXIGNvbnZleSB0byB0aGUgdXBz dHJlYW0gc2VydmVyIGEgdW5pcXVlIOKAnGNsaWVudC1pZOKAnSB3aGljaCBpcyBkaWZmZXJlbnQg dG8gdGhlIGltcGxpZWQgY2xpZW50IGlkIGFzIGRlcml2ZWQgZnJvbSB0aGUgUEtJIGNlcnRpZmlj YXRlIHRoYXQgdGhlIERPVFMgR1figJlDbGllbnQgdXNlcy9wcmVzZW50cyB3aGVuIGNvbW11bmlj YXRpbmcgdG8gdGhlIHNlcnZlcj8NClRvIG1lLCB0aGVyZSBuZWVkcyB0byBiZSBhbiBvcHRpb24g c3VjaCBhcyDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0gb3Ig4oCcY2xpZW50LWlk4oCdICh3aGlj aCBpcyBjb25mdXNpbmcgd2hlbiBhbHNvIHJlZmVycmluZyB0byB0aGUgY2xpZW50IGlkZW50aXR5 IGFzIGRlcml2ZWQgZnJvbSB0aGUgKERPVFMgR1cpIENsaWVudOKAmXMgUEtJIGNlcnRpZmljYXRl KSBhcyBhIHBhcnQgb2YgdGhlIHByb3RvY29sLg0KDQpJIGFncmVlIHRoYXQgdGhlIERPVFMgR1cg Y2FuIGdlbmVyYXRlIGl0cyBvd24gdW5pcXVlIGNsaWVudC1pZCB0byBzdG9wIG11bHRpcGxlIGVu dHJpZXMgYmVpbmcgbmVlZGVkLg0KDQpJIGFncmVlIHRoYXQgaXMgbm90IGEgZ29vZCB0aGluZyB0 byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1hdGlvbiB3aGVuIHBhc3NpbmcgdGhyb3Vn aCBhIERPVFMgR1csIHNvIG15IFJFUVVJUkVEIGRvZXMgbm90IG1ha2Ugc2Vuc2UuDQoNClJlZ2Fy ZHMNCg0KSm9uDQpQUyDigJMgSSBhbSBoYXZpbmcgdG8gZGVhbCB3aXRoIG90aGVyIHN0dWZmIGF0 IHByZXNlbnQg4oCTIEkgd2lsbCBnZXQgYmFjayBsYXRlciBvbiB0aGUgb3RoZXIgaXNzdWVzIHVu ZGVyIGRpc2N1c3Npb24NCg0KRnJvbTogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSBbbWFpbHRv OiBUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBtY2FmZWUuY29tPl0NClNlbnQ6IDA2IE9jdG9iZXIgMjAxNyAxNDo1OA0KVG86 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+OyBKb24gU2hhbGxvdzsgJ0RvYmJpbnMsIFJvbGFuZCc7IGRvdHNAaWV0Zi5vcmc8 bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMg Q2hhbGxlbmdlcw0KDQpJIGRvbuKAmXQgc2VlIGEgbmVlZCBmb3IgY2xpZW50LXNpZGUgRE9UUyBn YXRld2F5IHRvIGNvbnZleSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERP VFMgc2VydmVyLiDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSBsb29rcyByZXF1aXJlZCBvbmx5 IGZvciB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5cy4gSW4gY2FzZSBvZiBzZXJ2ZXItc2lk ZSBET1RTIGdhdGV3YXksIGl0IGNhbiBjb252ZXkgdGhlIGNsaWVudC1pZCBnZW5lcmF0ZWQgZnJv bSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiBUaGUg RE9UUyBnYXRld2F5IGNhbiBnZW5lcmF0ZSBhIHVuaXF1ZSBjbGllbnQtaWQgYW5kIGRvZXMgbm90 IGhhdmUgdG8gc2VuZCBhbiBhcnJheSBvZiBjbGllbnQtaWRzIHRvIHRoZSBET1RTIHNlcnZlciB0 byByZXNvbHZlIGNsYXNoZXMuDQoNCi1UaXJ1DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KRG90cyBtYWlsaW5nIGxpc3QNCg0KRG90c0BpZXRm Lm9yZzxtYWlsdG86RG90c0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kb3RzDQoNCg== --_000_DM5PR16MB1788BAC514615AF5F13D161DEA750DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAz O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjsNCgljb2xvcjpi bGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiU2Vnb2UgVUkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1 bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpwLlRleHRlZGVidWxs ZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJe21zby1zdHlsZS1uYW1l OiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHls ZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUzNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkhpIEpvbiw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVu ZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij5QbGVhc2Ugc2VlIGlubGluZTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEpvbiBTaGFsbG93IFtt YWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBPY3RvYmVyIDEwLCAyMDE3IDY6MjggUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkgJmx0O1RpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7 OyBkb3RzQGlldGYub3JnOyBrYW5hbWUgbmlzaGl6dWthICZsdDtrYW5hbWVAbnR0djYuanAmZ3Q7 OyBSb2xhbmQgRG9iYmlucyAmbHQ7cmRvYmJpbnNAYXJib3IubmV0Jmd0OzsgbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0 ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgVGly dSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SSBhbSBoYXZpbmcgdHJvdWJsZSBwYXJzaW5nIHRoaXMg4oCTIGl0IGlz IGRlZmluaXRpb24gb2YgdGVybXMg4oCTIHNlcnZlciBhbmQgY2xpZW50IHdoZW4gcmVmZXJyaW5n IHRvIERPVFMgQ2xpZW50LCBET1RTIFNlcnZlciBhbmQgRE9UUyBHYXRld2F5LiZuYnNwOyBJDQog dGhpbmsgdGhlcmUgaXMgYSB0eXBvLiZuYnNwOyBbSSBtYW55IHRpbWVzIGhhdmUgZ290IG11ZGRs ZWQgaW4gbXkgdGhpbmtpbmcgd2hlbiByZWZlcnJpbmcgdG8sIHNheSwgRE9UUyBHVyBjbGllbnQg c2lkZSDigJMgd2hpY2ggYWN0dWFsbHkgaXMgYSBET1RTIHNlcnZlciBpbiBpdHMgb3duIHJpZ2h0 cy5dPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5bVFJdIFRoZSBET1RTIGNsaWVudCBjZXJ0 aWZpY2F0ZSBtYXkgbm90IGZpdCB3aXRoaW4gdGhlIHBhdGggTVRVLiBUaGUgYWx0ZXJuYXRpdmUg YXBwcm9hY2ggaXMsIHRoZSBzZXJ2ZXItc2lkZSBET1RTIEdXIGNvbXB1dGVzIFNIQS0yNTYgb2Yg dGhlIFN1YmplY3QgUHVibGljIEtleSBJbmZvIChTUEtJKSBvZg0KIHRoZSBjbGllbnQgY2VydGlm aWNhdGUgYW5kIHNlbmQgdGhlIGhhc2hlZCBvdXRwdXQgdG8gdGhlIERPVFMgc2VydmVyIGluIHRo ZSBuZXcgY2xpZW50LWlkIHBhcmFtZXRlciAoc2VlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzQ2OSNzZWN0aW9uLTIuNCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzc0Njkjc2VjdGlvbi0yLjQ8L2E+KS4gU0hBLTI1NiBpcyByZXNpc3RhbnQgdG8gY29s bGlzaW9ucy4gRnVydGhlciwgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGFuZCBET1RTIHNlcnZl ciBhcmUgaW4gdGhlIHNhbWUgZG9tYWluIG9wZXJhdGluZyB0aGUgRVNUIHNlcnZlciwgRE9UUyBj bGllbnQNCiB3aWxsIGJlIHVzaW5nIHRoZSBjZXJ0aWZpY2F0ZSBwcm92aXNpb25lZCBieSB0aGUg RVNUIHNlcnZlciB0byBhdXRoZW50aWNhdGUgaXRzZWxmIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RT IGdhdGV3YXkgYW5kIEkgZG9u4oCZdCBzZWUgYW55IGFtYmlndW91cyBpbmZvcm1hdGlvbiBpbiB0 aGUgaGFzaGVkIGNsaWVudCBpZGVudGl0eSBnZW5lcmF0ZWQgYW5kIGNvbnZleWVkIGJ5IHRoZSBz ZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgdG8gdGhlIERPVFMgc2VydmVyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+VG8gbWUsDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPnNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBkZWZpbml0aW9uIGlzIHRoZSB1cHN0cmVh bSBET1RTIHNlcnZlciBmYWNpbmcgcGFydCBvZiB0aGUgRE9UUyBHYXRld2F5IOKAkyBjMiBpbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tLS0tLS0tLS0t LS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgfCBEIHwmbmJzcDsm bmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0t LSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgfCBPIHwmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0mIzQzOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgYzEgfC0tLS0tLS0tLS18IHMxIHwg VCB8IGMyIHwtLS0tLS0tLS18IHMyIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmIzQzOy0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgUyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst LS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0mIzQzOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmUtMDQjc2VjdGlvbi0yLjIuMyI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmUt MDQjc2VjdGlvbi0yLjIuMzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SXNzdWUgMTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNv IGhvdyBkb2VzIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RE9UUyBj bGllbnQgd2lsbCBiZSB1c2luZyB0aGUgY2VydGlmaWNhdGUgcHJvdmlzaW9uZWQgYnkgdGhlIEVT VCBzZXJ2ZXIgdG8gYXV0aGVudGljYXRlIGl0c2VsZg0KIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RT IGdhdGV3YXnigJ0gd29yaz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+LSAoKGMxKSB0byAoYzIpIGlzIGls bGVnYWwhKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ W1RSXSBjMSBhdXRoZW50aWNhdGVzIHRvIHMxIHVzaW5nIHRoZSBjZXJ0aWZpY2F0ZSBpdCByZWNl aXZlZCBmcm9tIHRoZSBFU1Qgc2VydmVyIGluIHRoZSBzYW1lIGRvbWFpbiBhcyBzMSwgYzIgYW5k IHMyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SXNzdWUgMjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0Ij49PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij7igJxzZXJ2ZXItc2lkZSBE T1RTIGdhdGV3YXkgYW5kIERPVFMgc2VydmVyIGFyZSBpbiB0aGUgc2FtZSBkb21haW4gb3BlcmF0 aW5nIHRoZSBFU1Qgc2VydmVyLCBET1RTIGNsaWVudCB3aWxsIGJlIHVzaW5nIHRoZSBjZXJ0aWZp Y2F0ZSBwcm92aXNpb25lZCBieSB0aGUgRVNUIHNlcnZlcuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dCI+V2hpbHN0IChjMikgYW5kIChzMikgd2lsbCBiZSBpbiB0 aGUgc2FtZSBkb21haW4gZm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiwgdGhlIHNhbWUgaXMgbm90 IG5lY2Vzc2FyaWx5IHRydWUgZm9yIChjMSkgYW5kIChzMikuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SG93 ZXZlciB0aGUgdXNlIG9mIFNQS0kgd2lsbCB3b3JrIGlmIGFsbCB0aGUgKGMxKSB0eXBlIGNsaWVu dHMgdGFsa2luZyB0byAoczEpIGFyZSB1c2luZyBQS0kuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPltUUl0gVGhlIGFzc3VtcHRpb24gaXMg RE9UUyBhZ2VudHMgaW4gZGlmZmVyZW50IGRvbWFpbnMgbXVzdCB1c2UgUEtJIGZvciBtdXR1YWwg YXV0aGVudGljYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPklmIHRoZXJlIGlzIGFub3RoZXIgdHJ1c3QgbWVjaGFuaXNtIGZvciAoYzEpJmx0Oy0m Z3Q7KChzMSksIHRoZW4gaXQgaXMgZ29pbmcgdG8gaGF2ZSB0byBiZSBhIGhhc2ggb24gc29tZXRo aW5nIGRpZmZlcmVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv d3RleHQiPltUUl0gWWVzLCB3ZSBjYW4gcHJvcG9zZSBTUEtJIGFzIG9uZSBtZWNoYW5pc21zIChz aW5jZSBzMSwgYzIgYW5kIHMzIGFyZSBpbiB0aGUgc2FtZSBkb21haW4sIHRoZXkgYWxsIHdpbGwg YmUgYXdhcmUgb2YgdGhlIGFsdGVybmF0ZSB0cnVzdCBtZWNoYW5pc20pLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gRG90cyBbbWFpbHRvOg0KPGEg aHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+ZG90cy1ib3VuY2VzQGlldGYub3Jn PC9hPl0gPGI+T24gQmVoYWxmIE9mDQo8L2I+S29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTxicj4N CjxiPlNlbnQ6PC9iPiAxMCBPY3RvYmVyIDIwMTcgMTI6NTM8YnI+DQo8Yj5Ubzo8L2I+IGthbmFt ZSBuaXNoaXp1a2E7IEpvbiBTaGFsbG93OyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmlu czxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdl czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkhpIEth bmFtZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPlBs ZWFzZSBzZWUgaW5saW5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+IERvdHMgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPm1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PmthbmFtZSBuaXNoaXp1a2E8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAxMCwg MjAxNyA4OjQ5IEFNPGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZs dDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5j b20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZndDs7DQogSm9uIFNo YWxsb3cgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNv bSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5zdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jmd0OzsNCjwvc3Bhbj48YSBocmVmPSJt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPmRvdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij47IFJvbGFuZCBEb2JiaW5zICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OnJkb2JiaW5zQGFyYm9yLm5ldCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5yZG9iYmluc0BhcmJvci5uZXQ8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5IaSw8YnI+DQo8YnI+DQomZ3Q7IEkgYWdyZWUgdGhlIGJlbG93IHByb2JsZW1z IGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IG11c3QgY29u dmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLg0KPGJyPg0K SSBhZ3JlZSB3aXRoIHRoaXMgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGNhc2UuPGJyPg0KQXQg dGhlIHNhbWUgdGltZSwgSSBhZ3JlZSB3aXRoIGJlbG93Ojxicj4NCiZndDsgSSBhZ3JlZSB0aGF0 IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5mb3JtYXRp b24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLA0KPGJyPg0KPGJyPg0KVGhlbiwgc2hv dWxkIERPVFMgR1cgc2VuZCDigJxjbGllbnQgaWRlbnRpdHnigJ0gKGkuZS4gY2VydGlmaWNhdGVz IG9mIERPVFMgY2xpZW50cykgaXRzZWxmIG9yIGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHnigJ0p IHRvIERPVFMgc2VydmVyPzxicj4NCklmIGxhdGVyLCBob3cgY2FuIERPVFMgc2VydmVyIHJlYWN0 IHRvIHRoZSBhbWJpZ3VvdXMgaW5mb3JtYXRpb24gb2YgdGhlIGhhc2hlZCjigJxjbGllbnQgaWRl bnRpdHnigJ0pLjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5bVFJdIFRoZSBET1RTIGNsaWVudCBjZXJ0 aWZpY2F0ZSBtYXkgbm90IGZpdCB3aXRoaW4gdGhlIHBhdGggTVRVLiBUaGUgYWx0ZXJuYXRpdmUg YXBwcm9hY2ggaXMsIHRoZSBzZXJ2ZXItc2lkZSBET1RTIEdXIGNvbXB1dGVzIFNIQS0yNTYgb2Yg dGhlIFN1YmplY3QgUHVibGljIEtleSBJbmZvIChTUEtJKSBvZg0KIHRoZSBjbGllbnQgY2VydGlm aWNhdGUgYW5kIHNlbmQgdGhlIGhhc2hlZCBvdXRwdXQgdG8gdGhlIERPVFMgc2VydmVyIGluIHRo ZSBuZXcgY2xpZW50LWlkIHBhcmFtZXRlciAoc2VlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzQ2OSNzZWN0aW9uLTIuNCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzc0Njkjc2VjdGlvbi0yLjQ8L2E+KS4gU0hBLTI1NiBpcyByZXNpc3RhbnQgdG8gY29s bGlzaW9ucy4gRnVydGhlciwgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGFuZCBET1RTIHNlcnZl ciBhcmUgaW4gdGhlIHNhbWUgZG9tYWluIG9wZXJhdGluZyB0aGUgRVNUIHNlcnZlciwgRE9UUyBj bGllbnQNCiB3aWxsIGJlIHVzaW5nIHRoZSBjZXJ0aWZpY2F0ZSBwcm92aXNpb25lZCBieSB0aGUg RVNUIHNlcnZlciB0byBhdXRoZW50aWNhdGUgaXRzZWxmIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RT IGdhdGV3YXkgYW5kIEkgZG9u4oCZdCBzZWUgYW55IGFtYmlndW91cyBpbmZvcm1hdGlvbiBpbiB0 aGUgaGFzaGVkIGNsaWVudCBpZGVudGl0eSBnZW5lcmF0ZWQgYW5kIGNvbnZleWVkIGJ5IHRoZSBz ZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgdG8gdGhlIERPVFMgc2VydmVyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPi1UaXJ1PC9zcGFuPjxicj4NCjxicj4N CnJlZ2FyZHMsPGJyPg0KS2FuYW1lPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMDE3LzEw LzA5IDIyOjM0LCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgSm9u LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJs ZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xp ZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gQnV0IGZvciB0aGUgY2xpZW50LXNp ZGUgRE9UUyBnYXRld2F5LCBpdCBzaG91bGQNCiByZXNvbHZlIGNvbmZsaWN0aW5nIHJ1bGVzIGIv dyBET1RTIGNsaWVudHMgKGUuZy4gb25lIGNsaWVudCBpbnN0YWxsaW5nIGJsYWNrLWxpc3QgQUNM IGZvciBhbiBJUCBhZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xpZW50IGluc3RhbGxzIHdoaXRlLWxp c3QgQUNMIGZvciB0aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1lIGFsaWFzLW5hbWVzIGZvciBkaWZm ZXJlbnQgbWl0aWdhdGlvbiBzY29wZXMpLiBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkIGZvciBhIGNs aWVudC1zaWRlDQogRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR5 4oCdIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgb3IgRE9UUyBzZXJ2ZXIuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPi1UaXJ1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IEpvbiBTaGFsbG93IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1p ZXRmQGpwc2hhbGxvdy5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bWFpbHRvOnN1cGpwcy1pZXRmQGpw c2hhbGxvdy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFNhdHVyZGF5LCBPY3RvYmVyIDcsIDIwMTcgMjowNyBQTTxicj4NCjxiPlRvOjwvYj4gS29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dh clJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmx0O1RpcnVtYWxlc3dh clJlZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjsN Cjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5kb3RzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjsg Um9sYW5kIERvYmJpbnMNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDtyZG9iYmluc0BhcmJvci5uZXQmZ3Q7PC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0 ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgVGly dSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGhpcyBkaXNjdXNzaW9uIGdvZXMgYmV5b25kIGp1c3QgdGhlIG1pdGln YXRpb24gcmVxdWVzdC4mbmJzcDsgV2UgbmVlZCB0byBjb25zaWRlciB3aGF0IGhhcHBlbnMgd2l0 aCBib3RoIGFsaWFzLW5hbWUgYW5kIGFjbC1uYW1lIChkYXRhIGNoYW5uZWwpPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoZSBzaW1wbGUgY2FzZSBvZiBhIG1pdGlnYXRpb24gcmVxdWVzdCB3aXRoIG5vIGFsaWFzLW5h bWUgZG9lcyBub3QgcmVxdWlyZSBhbnkga25vd2xlZGdlIG9mIHRoZSBvcmlnaW5hbCBjbGllbnQu Jm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgaWYgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCB1 c2VzIGFsaWFzLW5hbWUsIHRoZW4gdGhlcmUgYXJlIDMgd2F5cyBvZiBoYW5kbGluZyB0aGlzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW4iPmEpPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGUgRE9UUyBHVyByZXBsYWNlcyB0aGUgYWxpYXMtbmFtZSB3aXRoIGl0 cyBhY3R1YWwgZGVmaW5pdGlvbiAodGFyZ2V0LWlwcyBldGMuIG1lcmdlZCBhcyBhcHByb3ByaWF0 ZSksIHNvIGFsaWFzLW5hbWUgaXMgbm90IGZvcndhcmRlZCBvbiB0byBTZXJ2ZXIg4oCTIGp1c3Qg dGhlDQogZXhwYW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGZvcndhcmRlZDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluIj5iKTxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhlIERPVFMgR1cgdXBkYXRlcyB0aGUgYWxpYXMtbmFtZSB3aXRoIGEgdW5pcXVlIGFsaWFzLW5h bWUgdGhhdCBpcyBmb3J3YXJkZWQgKGFuZCBoYXMgdG8gZG8gdGhlIHNhbWUgdGhpbmcgd2hlbiB0 aGUgYWxpYXMtbmFtZSBpcyBjb25maWd1cmVkIG9uIHRoZSBkYXRhIGNoYW5uZWwpDQog4oCTIHRv IGhhbmRsZSAyIG9yIG1vcmUgY2xpZW50cyBkZWZpbmluZyB0aGUgc2FtZSBhbGlhcy1uYW1lIHdo aWNoIGhhdmUgZGlmZmVyZW50IGNoYXJhY3RlcmlzdGljczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj5j KTxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIERP VFMgR1cgcmVjb2duaXNlcyB0aGF0IGFsaWFzLW5hbWUgaXMgbm90IHVuaXF1ZSBhbmQgYWRkcyBp biDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdIChJIHRoaW5rIEkgcHJlZmVyIHRoaXMg4oCc LWluZm/igJ0gbmFtZSB0byBjbGllbnQtaWQgb3Igb3JpZ2luYWwtY2xpZW50LWlkDQogYXMg4oCc LWlk4oCdIGlzIHRvbyBjbG9zZWx5ICZuYnNwO2Fzc29jaWF0ZWQgd2l0aCBDbGllbnQgSWRlbnRp dHkgZGVyaXZlZCBmcm9tIHRoZSBET1RTIEdXIENsaWVudCBjZXJ0aWZpY2F0ZSk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIGhhdmUgYWdyZWVkIHRoYXQgd2hlbiBhIGNsaWVudCBy ZXF1ZXN0cyBtaXRpZ2F0aW9uIHN0YXR1cywgdGhlIOKAnGFsaWFzLW5hbWXigJ0gc2hvdWxkIGJl IHJldHVybmVkIGFzIOKAnGFsaWFzLW5hbWXigJ0gYW5kIG5vdCB0aGUgc3Vic3RpdHV0ZWQgYWxp YXMtbmFtZQ0KIGNvbmZpZ3VyYXRpb24gKHRoaXMgZG9lcyBuZWVkIHRvIGJlIHN0YXRlZCBpbiB0 aGUgc3BlYyBmb3IgY2xhcml0eSkuJm5ic3A7IFRoaXMgbWFrZXMgKGEpIGRpZmZpY3VsdCB0byBi ZSBoYW5kbGVkIGJ5IERPVFMgR1cgd2hpY2ggdGhlbiByYWlzZXMgdGhlIHF1ZXN0aW9uIOKAkyBk byB3ZSByZWFsbHkgbmVlZCBhbGlhcy1uYW1lPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZGVmaW5pdGlvbiBh bmQgYXNzb2NpYXRpb24gb2YgQUNMcy9GaWx0ZXJzIG9mIHRoZSBkYXRhIGNoYW5uZWwgaXMgbW9y ZSBkaWZmaWN1bHQg4oCTIHRoZSBTZXJ2ZXIgbXVzdCBpbnN0YWxsIC8gYXBwbHkgdGhlIGFwcHJv cHJpYXRlIEFDTHMgb24gYQ0KIHBlciAoT3JpZ2luYWwpIENsaWVudCBiYXNpcyB3aGVuIG1pdGln YXRpb24gaXMgaW52b2tlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNsaWVudCAx 4oCZcyBjb25jZXB0IG9mIGEgV2hpdGVsaXN0IElQIGNvdWxkIGJlIENsaWVudCAy4oCZcyBjb25j ZXB0IG9mIGEgQmxhY2tsaXN0IElQLiZuYnNwOyBUaGUgU2VydmVyIG5lZWRzIHRvIGtub3cgd2hp Y2ggY2xpZW50IGlzIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24NCiBhbmQgaW5zdGFsbCB0aGUg Y29ycmVjdCBBQ0xzIOKAkyBpZiB0aGVyZSB3YXMgbm8g4oCdYWRkaXRpb25hbC1jbGllbnQtaW5m b+KAnSwgdGhlIFNlcnZlciBvbmx5IGtub3dzIHRoYXQgaGUgaGFzIHRvIGluc3RhbGwgQUxMIG9m IHRoZSBBQ0xzIChpLmUuIGJvdGggdGhlIEJsYWNrIGFuZCBXaGl0ZSBsaXN0IG9mIHRoZSBzYW1l IElQIGFzIGRlZmluZWQgYnkgQ2xpZW50IDEgYW5kIENsaWVudCAyKSBhcyBkZWZpbmVkIGJ5IGhp cyBjbGllbnQgKERPVFMgR1cpDQogd2hlbiBoaXMgY2xpZW50IHJlcXVlc3RzIGEgbWl0aWdhdGlv bi4mbmJzcDsgSGVyZSwgSSB0aGluayB0aGF0IGlmIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgY2xp ZW50IGZvciB0aGUgRE9UUyBHVywg4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSBpcyByZXF1 aXJlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Kb248L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gRG90cyBbbWFpbHRvOg0KPC9z cGFuPjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm Ij5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPktvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk8YnI+DQo8Yj5TZW50Ojwv Yj4gMDcgT2N0b2JlciAyMDE3IDA0OjI4PGJyPg0KPGI+VG86PC9iPiBKb24gU2hhbGxvdzsgPC9z cGFuPjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZiI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWYiPjsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWYiPmRvdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj47IFJvbGFuZCBE b2JiaW5zPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFs bGVuZ2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkluIGNhc2Ugb2YgY2xpZW50 LXNpZGUgRE9UUyBnYXRld2F5LCB3aHkgZG9lcyB0aGUgRE9UUyBzZXJ2ZXIgbmVlZCB0byBrbm93 IHdoaWNoIOKAnERPVFMgY2xpZW504oCdIGhhcyBjb252ZXllZCB0aGUgbWl0aWdhdGlvbiByZXF1 ZXN0ID88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZvciBleGFtcGxlLCB0aGUgRE9UUyBjbGllbnQgY291bGQgYmUgYSBERG9TIGRl dGVjdG9yIG9yIGFuIEFwcGxpY2F0aW9uIHNlcnZlciwgYW5kIHRoZSBjbGllbnQtc2lkZSBnYXRl d2F5IHdpbGwgaGF2ZSB0byByZXNvbHZlIHRoZSBjb25mbGljdGluZyBtaXRpZ2F0aW9uIHJlcXVl c3RzIGZyb20gdGhlDQogRE9UUyBjbGllbnRzLCBhZ2dyZWdhdGUgdGhlIG1pdGlnYXRpb24gcmVx dWVzdHMgZnJvbSB0aGUgRE9UUyBjbGllbnQgYW5kIHNlbmQgdGhlIHVwZGF0ZWQgbWl0aWdhdGlv biByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LVRpcnU8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSm9uIFNoYWxs b3cgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5tYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDYs IDIwMTcgNzo0MiBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAm bHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUu Y29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjsNCjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5kb3RzQGlldGYu b3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjsgUm9sYW5kIERvYmJpbnMgJmx0Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnJk b2JiaW5zQGFyYm9yLm5ldDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBUaXJ1LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Vbmxlc3MgSSBh bSBtaXNzaW5nIHNvbWV0aGluZywgaG93IGRvZXMgdGhlIENsaWVudCBzaWRlIG9mIERPVFMgR1cg Y29udmV5IHRvIHRoZSB1cHN0cmVhbSBzZXJ2ZXIgYSB1bmlxdWUg4oCcY2xpZW50LWlk4oCdIHdo aWNoIGlzIGRpZmZlcmVudCB0byB0aGUgaW1wbGllZA0KIGNsaWVudCBpZCBhcyBkZXJpdmVkIGZy b20gdGhlIFBLSSBjZXJ0aWZpY2F0ZSB0aGF0IHRoZSBET1RTIEdX4oCZQ2xpZW50IHVzZXMvcHJl c2VudHMgd2hlbiBjb21tdW5pY2F0aW5nIHRvIHRoZSBzZXJ2ZXI/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UbyBtZSwgdGhlcmUgbmVlZHMgdG8gYmUgYW4gb3B0aW9uIHN1Y2ggYXMg 4oCcb3JpZ2luYWwtY2xpZW50LWlk4oCdIG9yIOKAnGNsaWVudC1pZOKAnSAod2hpY2ggaXMgY29u ZnVzaW5nIHdoZW4gYWxzbyByZWZlcnJpbmcgdG8gdGhlIGNsaWVudCBpZGVudGl0eSBhcw0KIGRl cml2ZWQgZnJvbSB0aGUgKERPVFMgR1cpIENsaWVudOKAmXMgUEtJIGNlcnRpZmljYXRlKSBhcyBh IHBhcnQgb2YgdGhlIHByb3RvY29sLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgdGhlIERPVFMg R1cgY2FuIGdlbmVyYXRlIGl0cyBvd24gdW5pcXVlIGNsaWVudC1pZCB0byBzdG9wIG11bHRpcGxl IGVudHJpZXMgYmVpbmcgbmVlZGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgaXMgbm90IGEg Z29vZCB0aGluZyB0byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1hdGlvbiB3aGVuIHBh c3NpbmcgdGhyb3VnaCBhIERPVFMgR1csIHNvIG15IFJFUVVJUkVEIGRvZXMgbm90IG1ha2Ugc2Vu c2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5QUyDigJMgSSBhbSBoYXZpbmcgdG8gZGVhbCB3aXRoIG90aGVyIHN0dWZm IGF0IHByZXNlbnQg4oCTIEkgd2lsbCBnZXQgYmFjayBsYXRlciBvbiB0aGUgb3RoZXIgaXNzdWVz IHVuZGVyIGRpc2N1c3Npb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OyxzYW5zLXNlcmlmIj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSBbbWFpbHRvOg0KPC9zcGFu PjxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss c2Fucy1zZXJpZiI+VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbTwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwNiBPY3RvYmVyIDIwMTcgMTQ6 NTg8YnI+DQo8Yj5Ubzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj47IEpvbiBTaGFsbG93OyAnRG9iYmlucywgUm9s YW5kJzsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWYiPmRvdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+SSBkb27igJl0IHNlZSBhIG5lZWQgZm9yIGNsaWVudC1zaWRl IERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRv IHRoZSBET1RTIHNlcnZlci4g4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gbG9va3MgcmVxdWly ZWQgb25seSBmb3IgdGhlIHNlcnZlci1zaWRlIERPVFMNCiBnYXRld2F5cy4gSW4gY2FzZSBvZiBz ZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IGNhbiBjb252ZXkgdGhlIGNsaWVudC1pZCBnZW5l cmF0ZWQgZnJvbSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2Vy dmVyLiBUaGUgRE9UUyBnYXRld2F5IGNhbiBnZW5lcmF0ZSBhIHVuaXF1ZSBjbGllbnQtaWQgYW5k IGRvZXMgbm90IGhhdmUgdG8gc2VuZCBhbiBhcnJheSBvZiBjbGllbnQtaWRzIHRvIHRoZSBET1RT IHNlcnZlciB0bw0KIHJlc29sdmUgY2xhc2hlcy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4t VGlydTwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNw YW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5Eb3RzIG1h aWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86 RG90c0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRlIiPkRvdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzIj48c3BhbiBsYW5nPSJGUiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB1788BAC514615AF5F13D161DEA750DM5PR16MB1788namp_-- From nobody Tue Oct 10 07:41:15 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D85134525 for ; Tue, 10 Oct 2017 07:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uuQxSZR8mP7 for ; Tue, 10 Oct 2017 07:41:11 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 823AC134231 for ; Tue, 10 Oct 2017 07:41:10 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e1viV-0003JU-AJ; Tue, 10 Oct 2017 15:41:07 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "kaname nishizuka" , , , "Roland Dobbins" References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> In-Reply-To: Date: Tue, 10 Oct 2017 15:41:09 +0100 Message-ID: <0df701d341d5$cfd88770$6f899650$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0DF8_01D341DE.31A1AA60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIAJQ6kjUASRe9X8Bri7ZGgMYlBpaAoe6cxMBVc+iCQKRB52aAQ1mQBsCgZLhx6JGRvTQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 14:41:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0DF8_01D341DE.31A1AA60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 I agree in part, but we need to look at the end (c1) to end (s3) = potential issues. What you are proposing works fine for (s2) to (s3). =20 (c1) requests mitigation with an alias-name =E2=80=9Calias-1=E2=80=9D. = If (s1) does not pass anything extra to (c2) for onward transmission, = (s2) sees a single client (c2) requesting mitigation with alias-name = =E2=80=9Calias-1=E2=80=9D. Fine, that works. If there was another DOTS client in the same location as (c1)(i.e. = c1diff), both using (s1) who also decided to use alias-name = =E2=80=9Calias-1=E2=80=9D who then requests mitigation, (s2) has no idea = that there are different =E2=80=9Calias-1=E2=80=9D definitions if (c2) = does not send also an extra differentiator.=20 =20 So, any DOTS GW in the chain should be passing on a = =E2=80=9Cunique-extra=E2=80=9D piece of information. =20 Regards =20 Jon=20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 15:15 To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Agree with your response, consider a deployment which has the following = DOTS agents. =20 DOTS clients (c1) =C3=9F----------------=C3=A0 (s1) client-side DOTS = gateway (c2) =C3=9F------------=C3=A0 (s2) server-side DOTS gateway (c3) = =C3=9F----------=C3=A0 (s3) DOTS server =20 My point is, (c2) need not convey the =E2=80=9Cc1 identity=E2=80=9D to = (s2) but (s2) needs to convey the =E2=80=9Cc2 identity=E2=80=9D to (c3) = and (c3) in-turn propagates the =E2=80=9Cc2 identity=E2=80=9D to (s3). =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 6:15 PM To: Konda, Tirumaleswar Reddy ; = kaname nishizuka ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Agreed that only a DOTS GW server facing needs to send information to = the upstream DOTS Server =E2=80=93 which could also be a DOTS GW. +-------------+ | | D | | +----+ | | O | | +----+ | c1 |----------| s1 | T | c2 |---------| s2 | +----+ | | S | | +----+ | | G | | +-------------+ https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-2.2.3= =20 However, the DOTS GW client facing (s1) is the one with knowledge of the = individual clients that are currently using the DOTS server running on = the DOTS GW. This information has to somehow be passed over to the DOTS = GW server facing (c2), but separate DOTS stacks are being run for (s1) = and (c2) as per architecture spec 2.2.3. I was referring to what (s1) = may need to pass on to (c2) in my email response to Kaname, not what is = sent by (c1). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 13:16 To: Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 I thought we agreed that based on the current DOTS requirements only the = server-side DOTS GW needs to convey the DOTS client (or client-side DOTS = WG) identity to the DOTS server.=20 =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 2:53 PM To: 'kaname nishizuka' ; Konda, Tirumaleswar Reddy = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Kaname, =20 I do not think that information necessarily needs to be the original = client identity. The GW Client side will have its own identity which = the DOTS Server can use to differentiate between DOTS (GW) Clients. =20 So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash collisions. Or = it could be a simple list such as C1, C2 =E2=80=A6Cn. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 10 October 2017 04:19 To: Konda, Tirumaleswar Reddy; Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi, > I agree the below problems are applicable for server-side DOTS = gateway, it must convey the =E2=80=9Cclient identity=E2=80=9D to the = DOTS server.=20 I agree with this server-side DOTS gateway case. At the same time, I agree with below: > I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW,=20 Then, should DOTS GW send =E2=80=9Cclient identity=E2=80=9D (i.e. = certificates of DOTS clients) itself or hashed(=E2=80=9Cclient = identity=E2=80=9D) to DOTS server? If later, how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient identity=E2=80=9D). regards, Kaname On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote: Hi Jon, =20 I agree the below problems are applicable for server-side DOTS gateway, = it must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. = But for the client-side DOTS gateway, it should resolve conflicting = rules b/w DOTS clients (e.g. one client installing black-list ACL for an = IP address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:07 PM To: Konda, Tirumaleswar Reddy = = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds = in =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0DF8_01D341DE.31A1AA60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I agree in part, but we need to look at the end (c1) to end (s3) = potential issues.=C2=A0 What you are proposing works fine for (s2) to = (s3).

 

(c1) requests mitigation with an alias-name = =E2=80=9Calias-1=E2=80=9D.=C2=A0 If (s1) does not pass anything extra to = (c2) for onward transmission, (s2) sees a single client (c2) requesting = mitigation with alias-name =E2=80=9Calias-1=E2=80=9D.=C2=A0 Fine, that = works.

If there was another DOTS client in the same location as (c1)(i.e. = c1diff), both using (s1) who also decided to use alias-name = =E2=80=9Calias-1=E2=80=9D who then requests mitigation, (s2) has no idea = that there are different =E2=80=9Calias-1=E2=80=9D definitions if (c2) = does not send also an extra differentiator.

 

So, any DOTS GW in the chain should be passing on a = =E2=80=9Cunique-extra=E2=80=9D piece of = information.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy
Sent: 10 October 2017 15:15
To: = Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS = Gateways Challenges

 

Agree with your response, consider a deployment which has the = following DOTS agents.

 

DOTS clients (c1) =C3=9F<= /span>----------------=C3=A0<= /span> (s1) client-side DOTS gateway (c2) =C3=9F<= /span>------------=C3=A0<= /span> (s2) server-side DOTS gateway (c3) =C3=9F<= /span>----------=C3=A0<= /span> (s3) DOTS server

 

My point is, (c2) need not convey the =E2=80=9Cc1 = identity=E2=80=9D to (s2) but (s2) needs to convey the =E2=80=9Cc2 = identity=E2=80=9D to (c3) and (c3) in-turn propagates the =E2=80=9Cc2 = identity=E2=80=9D to (s3).

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 6:15 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Agreed that only a DOTS GW server facing needs to send information to = the upstream DOTS Server =E2=80=93 which could also be a DOTS = GW.

  =             &= nbsp;          +-------= ------+

          = ;            =    |    | D |    = |

         = +----+          = |    | O |    = |         = +----+

         | c1 = |----------| s1 | T | c2 |---------| s2 |

         = +----+     =      |    | S = |    |         = +----+

          = ;            =    |    | G |    = |

          = ;            =    +-------------+

https://tools.ietf.org/html/draft-ietf-dots-architecture-04#sec= tion-2.2.3

 

However, the DOTS GW client facing (s1) is the one with knowledge of = the individual clients that are currently using  the DOTS server = running on the DOTS GW.  This information has to somehow be passed = over to the DOTS GW server facing (c2), but separate DOTS stacks are = being run for (s1) and (c2) as per architecture spec 2.2.3.  I was = referring to what (s1) may need to pass on to (c2) in my email response = to Kaname, not what is sent by (c1).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 13:16
To: Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

I thought we agreed that based on the current DOTS requirements = only the server-side DOTS GW needs to convey the DOTS client (or = client-side DOTS WG) identity to the DOTS server. =

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 2:53 PM
To: = 'kaname nishizuka' <kaname@nttv6.jp>; Konda, = Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Kaname,

 

I do not think that information necessarily needs to be the original = client identity.  The GW Client side will have its own identity = which the DOTS Server can use to differentiate between DOTS (GW) = Clients.

 

So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash = collisions.  Or it could be a simple list such as C1, C2 = =E2=80=A6Cn.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of kaname nishizuka
Sent: 10 October 2017 = 04:19
To: Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi,

> I agree the below = problems are applicable for server-side DOTS gateway, it must convey the = =E2=80=9Cclient identity=E2=80=9D to the DOTS server.
I agree with = this server-side DOTS gateway case.
At the same time, I agree with = below:
> I agree that is not a good thing to = =E2=80=9Cleak=E2=80=9D out internal information when passing through a = DOTS GW,

Then, should DOTS GW send =E2=80=9Cclient = identity=E2=80=9D (i.e. certificates of DOTS clients) itself or = hashed(=E2=80=9Cclient identity=E2=80=9D) to DOTS server?
If later, = how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient = identity=E2=80=9D).

regards,
Kaname

On 2017/10/09 22:34, Konda, Tirumaleswar Reddy = wrote:

Hi = Jon,

 

I agree = the below problems are applicable for server-side DOTS gateway, it must = convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. But for = the client-side DOTS gateway, it should resolve conflicting rules b/w = DOTS clients (e.g. one client installing black-list ACL for an IP = address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, October 7, 2017 2:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_= Konda@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
S= ubject: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client.  =

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)     &nb= sp; The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)      = The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)     &nb= sp; The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely  associated with Client = Identity derived from the DOTS GW Client = certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).  This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.  The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.  Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= = Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:28
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, October 6, 2017 7:42 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= = Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 06 October 2017 14:58
To: = mohamed.boucadair@orange.com= ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: = [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 

-Tiru

 

________________=
_______________________________
Dots mailing =
list
Dots@ietf.org
https://www.ietf.org/=
mailman/listinfo/dots

 

------=_NextPart_000_0DF8_01D341DE.31A1AA60-- From nobody Tue Oct 10 07:53:32 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11814134DF7 for ; Tue, 10 Oct 2017 07:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=mcafee.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 wSHcCCmzJasL for ; Tue, 10 Oct 2017 07:53:25 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 34FBA134E11 for ; Tue, 10 Oct 2017 07:52:59 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507647160; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=p uHmzJ7X93xp17/+FiJW6MTIKi8Biv+eUQhOmRP/7l I=; b=dp42cX4LbW8hntufBWt8vimm5at2qsfrsg30531B2bW8 KzECZiyTCyCm0eCNsJLLkoEP7eb5YOgFaWIf3Y4aFhBYixG5s/ HhNW9kOb5Igy/gkkerdQ9XMFTTGsqXN0btGuuhNjN4uXp+sFmt K6sDBLwTPeOjqMt0IeWsbIfgrFo= Received: from DNVEXAPP1N04.corpzone.internalzone.com (dnvexapp1n04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c29_9042_40ab0a8a_61de_4192_979a_e9eefd6d61ff; Tue, 10 Oct 2017 09:52:39 -0500 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 08:52:15 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Oct 2017 08:52:15 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 08:52:14 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 14:52:13 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 14:52:13 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , kaname nishizuka , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAACzkMAABuu0fgAB0EBwAADL1rgAAF4fWwAAEncgAAAJP24AADfJaAAAAklGA= Date: Tue, 10 Oct 2017 14:52:13 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> <0df701d341d5$cfd88770$6f899650$@jpshallow.com> In-Reply-To: <0df701d341d5$cfd88770$6f899650$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.17.191] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:+ZF9bRFhvDXHIM02v8cat0pwWwpN66mxUcuOyKlz/Nru0NR4pXwUuNPTLcnhrjjxO9GHsymn32vh/I5rbRYoOBgQPWl7Gda8uqmPedkKdPkSYxSt8X2a7QOX51bVBL/ksbAft7r7G71pk79BT1JJdgYObmlec1uZlWV9J7Yl3aHfZZfTmA057Ji/eLkLBdPeUiY/9r14d/JShr+QXYkWgpMQ5X1nXsTvkO8dL27HWPkrl5tZ1PDtjma7vT/LGdTAoWJa4H2K8FJVE3yfQjI0bD/cU3EGfsd3197VRpSwmGfuQde0Cs5LfgP+rvjWV5ZKJFld0zj4sc8CkLn2+5OL0w==; 5:UNZU6/2ggDfM0rVmsiwU4MkcHv4hIjczLIQdP7QUQYd0LUyIozb6OJ0HaTe31v2ktPkisSmqKpTNcsYYGa97MadDRCa8ED/spzN0LukUOseExgBufC9RoWhzXB5EbuNlW9siMugITaL6IGiGUzAqFQ==; 24:9iNwfq9amH9kSPoFKZLbJkR6ce5lvB9v3HvfmKbNdG/N5rnkVXmBkZCYY5Cuglu9Jlj4nGIuqYWJ45IrW8zP+quqtUWvjao228EpgkyALhU=; 7:CML3s8ld/PjPnw/nHOvux/tcIo6jGRSiTFF+VhD3v3FjB0DYbOPoC0/VyW2ReDrxl6W9dAyAujJb6b8WjHcdhJ7umPVcIjl40ZPlGQbmPCavKtLedFG4uEM9HNWHwpRzPc7tVg0LLiS6URHXe8894gMmc/phNIElTyd+wCFKulkrzZkX35wfNhrEcsL/3G/mxrK8d1jhdoBz5hdJRybEK7t22wx37MySl7nc+R+PCo0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9ddd6f10-9d73-490d-4b90-08d50fee7e1f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(32952001)(51444003)(199003)(377454003)(189002)(24454002)(66066001)(25786009)(97736004)(80792005)(2501003)(54356999)(101416001)(50986999)(478600001)(72206003)(76176999)(966005)(2900100001)(3660700001)(3280700002)(8936002)(8676002)(81166006)(105586002)(81156014)(6506006)(77096006)(106356001)(229853002)(74316002)(189998001)(33656002)(790700001)(3846002)(102836003)(6116002)(7736002)(6436002)(236005)(93886005)(53546010)(68736007)(2906002)(5660300001)(7696004)(86362001)(2201001)(55016002)(99286003)(53946003)(9686003)(6306002)(54896002)(6246003)(53936002)(2950100002)(316002)(14454004)(606006)(110136005)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17883980E80C0FB5A4B69481EA750DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 14:52:13.4468 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6117> : streams <1766659> : uri <2514304> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 14:53:29 -0000 --_000_DM5PR16MB17883980E80C0FB5A4B69481EA750DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNvbmZsaWN0aW5nIGFsaWFzLW5hbWVzIGZyb20gRE9UUyBjbGllbnQgKGMxKSBhbmQgYW5v dGhlciBjbGllbnQgKGxldOKAmSBjYWxsIChjMTEpKSBiZWhpbmQgKHMxKSBzaG91bGQgYmUgcmVz b2x2ZWQgYnkgczEgaXRzZWxmLCBpdCBpcyBhbHNvIHRoZSByZXNwb25zaWJpbGl0eSBvZiAoczEp IHRvIHJlc29sdmUgY29uZmxpY3RpbmcgbWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIChjMSkgYW5k IChjMTEpLCBhZ2dyZWdhdGUgdGhlIG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBj bGllbnRzIChjMSBhbmQgYzExKSBhbmQgc2VuZCB0aGUgdXBkYXRlZCBtaXRpZ2F0aW9uIHJlcXVl c3QgKGMyKS4NCg0KLVRpcnUNCg0KRnJvbTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0 ZkBqcHNoYWxsb3cuY29tXQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMCwgMjAxNyA4OjExIFBN DQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFA TWNBZmVlLmNvbT47IGthbmFtZSBuaXNoaXp1a2EgPGthbmFtZUBudHR2Ni5qcD47IG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb207IGRvdHNAaWV0Zi5vcmc7IFJvbGFuZCBEb2JiaW5zIDxyZG9i Ymluc0BhcmJvci5uZXQ+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxl bmdlcw0KDQpIaSBUaXJ1LA0KDQpJIGFncmVlIGluIHBhcnQsIGJ1dCB3ZSBuZWVkIHRvIGxvb2sg YXQgdGhlIGVuZCAoYzEpIHRvIGVuZCAoczMpIHBvdGVudGlhbCBpc3N1ZXMuICBXaGF0IHlvdSBh cmUgcHJvcG9zaW5nIHdvcmtzIGZpbmUgZm9yIChzMikgdG8gKHMzKS4NCg0KKGMxKSByZXF1ZXN0 cyBtaXRpZ2F0aW9uIHdpdGggYW4gYWxpYXMtbmFtZSDigJxhbGlhcy0x4oCdLiAgSWYgKHMxKSBk b2VzIG5vdCBwYXNzIGFueXRoaW5nIGV4dHJhIHRvIChjMikgZm9yIG9ud2FyZCB0cmFuc21pc3Np b24sIChzMikgc2VlcyBhIHNpbmdsZSBjbGllbnQgKGMyKSByZXF1ZXN0aW5nIG1pdGlnYXRpb24g d2l0aCBhbGlhcy1uYW1lIOKAnGFsaWFzLTHigJ0uICBGaW5lLCB0aGF0IHdvcmtzLg0KSWYgdGhl cmUgd2FzIGFub3RoZXIgRE9UUyBjbGllbnQgaW4gdGhlIHNhbWUgbG9jYXRpb24gYXMgKGMxKShp LmUuIGMxZGlmZiksIGJvdGggdXNpbmcgKHMxKSB3aG8gYWxzbyBkZWNpZGVkIHRvIHVzZSBhbGlh cy1uYW1lIOKAnGFsaWFzLTHigJ0gd2hvIHRoZW4gcmVxdWVzdHMgbWl0aWdhdGlvbiwgKHMyKSBo YXMgbm8gaWRlYSB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQg4oCcYWxpYXMtMeKAnSBkZWZpbml0 aW9ucyBpZiAoYzIpIGRvZXMgbm90IHNlbmQgYWxzbyBhbiBleHRyYSBkaWZmZXJlbnRpYXRvci4N Cg0KU28sIGFueSBET1RTIEdXIGluIHRoZSBjaGFpbiBzaG91bGQgYmUgcGFzc2luZyBvbiBhIOKA nHVuaXF1ZS1leHRyYeKAnSBwaWVjZSBvZiBpbmZvcm1hdGlvbi4NCg0KUmVnYXJkcw0KDQpKb24N Cg0KRnJvbTogRG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMt Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5 DQpTZW50OiAxMCBPY3RvYmVyIDIwMTcgMTU6MTUNClRvOiBKb24gU2hhbGxvdzsga2FuYW1lIG5p c2hpenVrYTsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBS b2xhbmQgRG9iYmlucw0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5n ZXMNCg0KQWdyZWUgd2l0aCB5b3VyIHJlc3BvbnNlLCBjb25zaWRlciBhIGRlcGxveW1lbnQgd2hp Y2ggaGFzIHRoZSBmb2xsb3dpbmcgRE9UUyBhZ2VudHMuDQoNCkRPVFMgY2xpZW50cyAoYzEpIDwt LS0tLS0tLS0tLS0tLS0tLS0tLT4gKHMxKSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgKGMyKSA8 LS0tLS0tLS0tLS0tLS0tLT4gKHMyKSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgKGMzKSA8LS0t LS0tLS0tLS0tLS0+IChzMykgRE9UUyBzZXJ2ZXINCg0KTXkgcG9pbnQgaXMsIChjMikgbmVlZCBu b3QgY29udmV5IHRoZSDigJxjMSBpZGVudGl0eeKAnSB0byAoczIpIGJ1dCAoczIpIG5lZWRzIHRv IGNvbnZleSB0aGUg4oCcYzIgaWRlbnRpdHnigJ0gdG8gKGMzKSBhbmQgKGMzKSBpbi10dXJuIHBy b3BhZ2F0ZXMgdGhlIOKAnGMyIGlkZW50aXR54oCdIHRvIChzMykuDQoNCi1UaXJ1DQoNCkZyb206 IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NClNlbnQ6IFR1 ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgNjoxNSBQTQ0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+Pjsga2FuYW1lIG5pc2hpenVrYSA8a2FuYW1lQG50 dHY2LmpwPG1haWx0bzprYW5hbWVAbnR0djYuanA+PjsgbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8 bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0 PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTIEdh dGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KQWdyZWVkIHRoYXQgb25seSBhIERPVFMg R1cgc2VydmVyIGZhY2luZyBuZWVkcyB0byBzZW5kIGluZm9ybWF0aW9uIHRvIHRoZSB1cHN0cmVh bSBET1RTIFNlcnZlciDigJMgd2hpY2ggY291bGQgYWxzbyBiZSBhIERPVFMgR1cuDQogICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICB8IEQgfCAgICB8DQogICAgICAgICArLS0tLSsgICAgICAgICAgfCAgICB8IE8gfCAg ICB8ICAgICAgICAgKy0tLS0rDQogICAgICAgICB8IGMxIHwtLS0tLS0tLS0tfCBzMSB8IFQgfCBj MiB8LS0tLS0tLS0tfCBzMiB8DQogICAgICAgICArLS0tLSsgICAgICAgICAgfCAgICB8IFMgfCAg ICB8ICAgICAgICAgKy0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB8IEcgfCAg ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLWFyY2hpdGVjdHVyZS0wNCNzZWN0aW9u LTIuMi4zDQoNCkhvd2V2ZXIsIHRoZSBET1RTIEdXIGNsaWVudCBmYWNpbmcgKHMxKSBpcyB0aGUg b25lIHdpdGgga25vd2xlZGdlIG9mIHRoZSBpbmRpdmlkdWFsIGNsaWVudHMgdGhhdCBhcmUgY3Vy cmVudGx5IHVzaW5nICB0aGUgRE9UUyBzZXJ2ZXIgcnVubmluZyBvbiB0aGUgRE9UUyBHVy4gIFRo aXMgaW5mb3JtYXRpb24gaGFzIHRvIHNvbWVob3cgYmUgcGFzc2VkIG92ZXIgdG8gdGhlIERPVFMg R1cgc2VydmVyIGZhY2luZyAoYzIpLCBidXQgc2VwYXJhdGUgRE9UUyBzdGFja3MgYXJlIGJlaW5n IHJ1biBmb3IgKHMxKSBhbmQgKGMyKSBhcyBwZXIgYXJjaGl0ZWN0dXJlIHNwZWMgMi4yLjMuICBJ IHdhcyByZWZlcnJpbmcgdG8gd2hhdCAoczEpIG1heSBuZWVkIHRvIHBhc3Mgb24gdG8gKGMyKSBp biBteSBlbWFpbCByZXNwb25zZSB0byBLYW5hbWUsIG5vdCB3aGF0IGlzIHNlbnQgYnkgKGMxKS4N Cg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBLb25kYSwg VGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAxMCBPY3RvYmVyIDIwMTcgMTM6MTYNClRvOiBKb24g U2hhbGxvdzsgJ2thbmFtZSBuaXNoaXp1a2EnOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWls dG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zDQpTdWJqZWN0OiBSZTogW0RvdHNdIERP VFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpJIHRob3VnaHQgd2UgYWdyZWVkIHRoYXQgYmFzZWQg b24gdGhlIGN1cnJlbnQgRE9UUyByZXF1aXJlbWVudHMgb25seSB0aGUgc2VydmVyLXNpZGUgRE9U UyBHVyBuZWVkcyB0byBjb252ZXkgdGhlIERPVFMgY2xpZW50IChvciBjbGllbnQtc2lkZSBET1RT IFdHKSBpZGVudGl0eSB0byB0aGUgRE9UUyBzZXJ2ZXIuDQoNCi1UaXJ1DQoNCkZyb206IEpvbiBT aGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NClNlbnQ6IFR1ZXNkYXks IE9jdG9iZXIgMTAsIDIwMTcgMjo1MyBQTQ0KVG86ICdrYW5hbWUgbmlzaGl6dWthJyA8a2FuYW1l QG50dHY2LmpwPG1haWx0bzprYW5hbWVAbnR0djYuanA+PjsgS29uZGEsIFRpcnVtYWxlc3dhciBS ZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGlydW1hbGVz d2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWls dG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFp bHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgR2F0ZXdh eXMgQ2hhbGxlbmdlcw0KDQpIaSBLYW5hbWUsDQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgaW5mb3Jt YXRpb24gbmVjZXNzYXJpbHkgbmVlZHMgdG8gYmUgdGhlIG9yaWdpbmFsIGNsaWVudCBpZGVudGl0 eS4gIFRoZSBHVyBDbGllbnQgc2lkZSB3aWxsIGhhdmUgaXRzIG93biBpZGVudGl0eSB3aGljaCB0 aGUgRE9UUyBTZXJ2ZXIgY2FuIHVzZSB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gRE9UUyAoR1cp IENsaWVudHMuDQoNClNvLCB5ZXMsIGEgaGFzaGVkIHNldCBvZiBuYW1lcyBjYW4gYmUgdXNlZCDi gJMgaXQgaXMgdXAgdG8gdGhlIERPVFMgR1cgQ2xpZW50IHNpZGUgdG8gbWFrZSBzdXJlIHRoYXQg dGhlcmUgYXJlIG5vIGhhc2ggY29sbGlzaW9ucy4gIE9yIGl0IGNvdWxkIGJlIGEgc2ltcGxlIGxp c3Qgc3VjaCBhcyBDMSwgQzIg4oCmQ24uDQoNClJlZ2FyZHMNCg0KSm9uDQoNCkZyb206IERvdHMg W21haWx0bzogZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2Yga2FuYW1lIG5pc2hpenVrYQ0KU2VudDogMTAgT2N0b2JlciAyMDE3 IDA0OjE5DQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsgSm9uIFNoYWxsb3c7IG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMN ClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpLA0KDQo+ IEkgYWdyZWUgdGhlIGJlbG93IHByb2JsZW1zIGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lk ZSBET1RTIGdhdGV3YXksIGl0IG11c3QgY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0g dG8gdGhlIERPVFMgc2VydmVyLg0KSSBhZ3JlZSB3aXRoIHRoaXMgc2VydmVyLXNpZGUgRE9UUyBn YXRld2F5IGNhc2UuDQpBdCB0aGUgc2FtZSB0aW1lLCBJIGFncmVlIHdpdGggYmVsb3c6DQo+IEkg YWdyZWUgdGhhdCBpcyBub3QgYSBnb29kIHRoaW5nIHRvIOKAnGxlYWvigJ0gb3V0IGludGVybmFs IGluZm9ybWF0aW9uIHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHVywNCg0KVGhlbiwgc2hv dWxkIERPVFMgR1cgc2VuZCDigJxjbGllbnQgaWRlbnRpdHnigJ0gKGkuZS4gY2VydGlmaWNhdGVz IG9mIERPVFMgY2xpZW50cykgaXRzZWxmIG9yIGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHnigJ0p IHRvIERPVFMgc2VydmVyPw0KSWYgbGF0ZXIsIGhvdyBjYW4gRE9UUyBzZXJ2ZXIgcmVhY3QgdG8g dGhlIGFtYmlndW91cyBpbmZvcm1hdGlvbiBvZiB0aGUgaGFzaGVkKOKAnGNsaWVudCBpZGVudGl0 eeKAnSkuDQoNCnJlZ2FyZHMsDQpLYW5hbWUNCk9uIDIwMTcvMTAvMDkgMjI6MzQsIEtvbmRhLCBU aXJ1bWFsZXN3YXIgUmVkZHkgd3JvdGU6DQpIaSBKb24sDQoNCkkgYWdyZWUgdGhlIGJlbG93IHBy b2JsZW1zIGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IG11 c3QgY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiBC dXQgZm9yIHRoZSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksIGl0IHNob3VsZCByZXNvbHZlIGNv bmZsaWN0aW5nIHJ1bGVzIGIvdyBET1RTIGNsaWVudHMgKGUuZy4gb25lIGNsaWVudCBpbnN0YWxs aW5nIGJsYWNrLWxpc3QgQUNMIGZvciBhbiBJUCBhZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xpZW50 IGluc3RhbGxzIHdoaXRlLWxpc3QgQUNMIGZvciB0aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1lIGFs aWFzLW5hbWVzIGZvciBkaWZmZXJlbnQgbWl0aWdhdGlvbiBzY29wZXMpLiBJIGRvbuKAmXQgc2Vl IHRoZSBuZWVkIGZvciBhIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKA nGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IG9yIERP VFMgc2VydmVyLg0KDQotVGlydQ0KDQpGcm9tOiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1p ZXRmQGpwc2hhbGxvdy5jb21dDQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3IDI6MDcg UE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBNY0FmZWUuY29tPjxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERv YmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD48bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4NClN1 YmplY3Q6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUsDQoN ClRoaXMgZGlzY3Vzc2lvbiBnb2VzIGJleW9uZCBqdXN0IHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3Qu ICBXZSBuZWVkIHRvIGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3aXRoIGJvdGggYWxpYXMtbmFtZSBh bmQgYWNsLW5hbWUgKGRhdGEgY2hhbm5lbCkNCg0KVGhlIHNpbXBsZSBjYXNlIG9mIGEgbWl0aWdh dGlvbiByZXF1ZXN0IHdpdGggbm8gYWxpYXMtbmFtZSBkb2VzIG5vdCByZXF1aXJlIGFueSBrbm93 bGVkZ2Ugb2YgdGhlIG9yaWdpbmFsIGNsaWVudC4NCg0KSG93ZXZlciwgaWYgdGhlIG1pdGlnYXRp b24gcmVxdWVzdCB1c2VzIGFsaWFzLW5hbWUsIHRoZW4gdGhlcmUgYXJlIDMgd2F5cyBvZiBoYW5k bGluZyB0aGlzDQoNCmEpICAgICAgIFRoZSBET1RTIEdXIHJlcGxhY2VzIHRoZSBhbGlhcy1uYW1l IHdpdGggaXRzIGFjdHVhbCBkZWZpbml0aW9uICh0YXJnZXQtaXBzIGV0Yy4gbWVyZ2VkIGFzIGFw cHJvcHJpYXRlKSwgc28gYWxpYXMtbmFtZSBpcyBub3QgZm9yd2FyZGVkIG9uIHRvIFNlcnZlciDi gJMganVzdCB0aGUgZXhwYW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGZvcndhcmRlZA0KDQpi KSAgICAgIFRoZSBET1RTIEdXIHVwZGF0ZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBhIHVuaXF1ZSBh bGlhcy1uYW1lIHRoYXQgaXMgZm9yd2FyZGVkIChhbmQgaGFzIHRvIGRvIHRoZSBzYW1lIHRoaW5n IHdoZW4gdGhlIGFsaWFzLW5hbWUgaXMgY29uZmlndXJlZCBvbiB0aGUgZGF0YSBjaGFubmVsKSDi gJMgdG8gaGFuZGxlIDIgb3IgbW9yZSBjbGllbnRzIGRlZmluaW5nIHRoZSBzYW1lIGFsaWFzLW5h bWUgd2hpY2ggaGF2ZSBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNzDQoNCmMpICAgICAgIFRoZSBE T1RTIEdXIHJlY29nbmlzZXMgdGhhdCBhbGlhcy1uYW1lIGlzIG5vdCB1bmlxdWUgYW5kIGFkZHMg aW4g4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSAoSSB0aGluayBJIHByZWZlciB0aGlzIOKA nC1pbmZv4oCdIG5hbWUgdG8gY2xpZW50LWlkIG9yIG9yaWdpbmFsLWNsaWVudC1pZCBhcyDigJwt aWTigJ0gaXMgdG9vIGNsb3NlbHkgIGFzc29jaWF0ZWQgd2l0aCBDbGllbnQgSWRlbnRpdHkgZGVy aXZlZCBmcm9tIHRoZSBET1RTIEdXIENsaWVudCBjZXJ0aWZpY2F0ZSkNCldlIGhhdmUgYWdyZWVk IHRoYXQgd2hlbiBhIGNsaWVudCByZXF1ZXN0cyBtaXRpZ2F0aW9uIHN0YXR1cywgdGhlIOKAnGFs aWFzLW5hbWXigJ0gc2hvdWxkIGJlIHJldHVybmVkIGFzIOKAnGFsaWFzLW5hbWXigJ0gYW5kIG5v dCB0aGUgc3Vic3RpdHV0ZWQgYWxpYXMtbmFtZSBjb25maWd1cmF0aW9uICh0aGlzIGRvZXMgbmVl ZCB0byBiZSBzdGF0ZWQgaW4gdGhlIHNwZWMgZm9yIGNsYXJpdHkpLiAgVGhpcyBtYWtlcyAoYSkg ZGlmZmljdWx0IHRvIGJlIGhhbmRsZWQgYnkgRE9UUyBHVyB3aGljaCB0aGVuIHJhaXNlcyB0aGUg cXVlc3Rpb24g4oCTIGRvIHdlIHJlYWxseSBuZWVkIGFsaWFzLW5hbWU/DQoNClRoZSBkZWZpbml0 aW9uIGFuZCBhc3NvY2lhdGlvbiBvZiBBQ0xzL0ZpbHRlcnMgb2YgdGhlIGRhdGEgY2hhbm5lbCBp cyBtb3JlIGRpZmZpY3VsdCDigJMgdGhlIFNlcnZlciBtdXN0IGluc3RhbGwgLyBhcHBseSB0aGUg YXBwcm9wcmlhdGUgQUNMcyBvbiBhIHBlciAoT3JpZ2luYWwpIENsaWVudCBiYXNpcyB3aGVuIG1p dGlnYXRpb24gaXMgaW52b2tlZC4NCkNsaWVudCAx4oCZcyBjb25jZXB0IG9mIGEgV2hpdGVsaXN0 IElQIGNvdWxkIGJlIENsaWVudCAy4oCZcyBjb25jZXB0IG9mIGEgQmxhY2tsaXN0IElQLiAgVGhl IFNlcnZlciBuZWVkcyB0byBrbm93IHdoaWNoIGNsaWVudCBpcyByZXF1ZXN0aW5nIHRoZSBtaXRp Z2F0aW9uIGFuZCBpbnN0YWxsIHRoZSBjb3JyZWN0IEFDTHMg4oCTIGlmIHRoZXJlIHdhcyBubyDi gJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdLCB0aGUgU2VydmVyIG9ubHkga25vd3MgdGhhdCBo ZSBoYXMgdG8gaW5zdGFsbCBBTEwgb2YgdGhlIEFDTHMgKGkuZS4gYm90aCB0aGUgQmxhY2sgYW5k IFdoaXRlIGxpc3Qgb2YgdGhlIHNhbWUgSVAgYXMgZGVmaW5lZCBieSBDbGllbnQgMSBhbmQgQ2xp ZW50IDIpIGFzIGRlZmluZWQgYnkgaGlzIGNsaWVudCAoRE9UUyBHVykgd2hlbiBoaXMgY2xpZW50 IHJlcXVlc3RzIGEgbWl0aWdhdGlvbi4gIEhlcmUsIEkgdGhpbmsgdGhhdCBpZiB0aGVyZSBpcyBt b3JlIHRoYW4gb25lIGNsaWVudCBmb3IgdGhlIERPVFMgR1csIOKAnWFkZGl0aW9uYWwtY2xpZW50 LWluZm/igJ0gaXMgcmVxdWlyZWQuDQoNClJlZ2FyZHMNCg0KSm9uDQoNCkZyb206IERvdHMgW21h aWx0bzogZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYgT2YgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KU2VudDogMDcgT2N0b2Jl ciAyMDE3IDA0OjI4DQpUbzogSm9uIFNoYWxsb3c7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1h aWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMNClN1YmplY3Q6IFJlOiBbRG90c10g RE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkluIGNhc2Ugb2YgY2xpZW50LXNpZGUgRE9UUyBn YXRld2F5LCB3aHkgZG9lcyB0aGUgRE9UUyBzZXJ2ZXIgbmVlZCB0byBrbm93IHdoaWNoIOKAnERP VFMgY2xpZW504oCdIGhhcyBjb252ZXllZCB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0ID8NCkZvciBl eGFtcGxlLCB0aGUgRE9UUyBjbGllbnQgY291bGQgYmUgYSBERG9TIGRldGVjdG9yIG9yIGFuIEFw cGxpY2F0aW9uIHNlcnZlciwgYW5kIHRoZSBjbGllbnQtc2lkZSBnYXRld2F5IHdpbGwgaGF2ZSB0 byByZXNvbHZlIHRoZSBjb25mbGljdGluZyBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERP VFMgY2xpZW50cywgYWdncmVnYXRlIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERP VFMgY2xpZW50IGFuZCBzZW5kIHRoZSB1cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUg RE9UUyBzZXJ2ZXIuDQoNCi1UaXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBz LWlldGZAanBzaGFsbG93LmNvbV0NClNlbnQ6IEZyaWRheSwgT2N0b2JlciA2LCAyMDE3IDc6NDIg UE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPj47 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERv YmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pj4NClN1 YmplY3Q6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUsDQoN ClVubGVzcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBob3cgZG9lcyB0aGUgQ2xpZW50IHNpZGUg b2YgRE9UUyBHVyBjb252ZXkgdG8gdGhlIHVwc3RyZWFtIHNlcnZlciBhIHVuaXF1ZSDigJxjbGll bnQtaWTigJ0gd2hpY2ggaXMgZGlmZmVyZW50IHRvIHRoZSBpbXBsaWVkIGNsaWVudCBpZCBhcyBk ZXJpdmVkIGZyb20gdGhlIFBLSSBjZXJ0aWZpY2F0ZSB0aGF0IHRoZSBET1RTIEdX4oCZQ2xpZW50 IHVzZXMvcHJlc2VudHMgd2hlbiBjb21tdW5pY2F0aW5nIHRvIHRoZSBzZXJ2ZXI/DQpUbyBtZSwg dGhlcmUgbmVlZHMgdG8gYmUgYW4gb3B0aW9uIHN1Y2ggYXMg4oCcb3JpZ2luYWwtY2xpZW50LWlk 4oCdIG9yIOKAnGNsaWVudC1pZOKAnSAod2hpY2ggaXMgY29uZnVzaW5nIHdoZW4gYWxzbyByZWZl cnJpbmcgdG8gdGhlIGNsaWVudCBpZGVudGl0eSBhcyBkZXJpdmVkIGZyb20gdGhlIChET1RTIEdX KSBDbGllbnTigJlzIFBLSSBjZXJ0aWZpY2F0ZSkgYXMgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbC4N Cg0KSSBhZ3JlZSB0aGF0IHRoZSBET1RTIEdXIGNhbiBnZW5lcmF0ZSBpdHMgb3duIHVuaXF1ZSBj bGllbnQtaWQgdG8gc3RvcCBtdWx0aXBsZSBlbnRyaWVzIGJlaW5nIG5lZWRlZC4NCg0KSSBhZ3Jl ZSB0aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5m b3JtYXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLCBzbyBteSBSRVFVSVJFRCBk b2VzIG5vdCBtYWtlIHNlbnNlLg0KDQpSZWdhcmRzDQoNCkpvbg0KUFMg4oCTIEkgYW0gaGF2aW5n IHRvIGRlYWwgd2l0aCBvdGhlciBzdHVmZiBhdCBwcmVzZW50IOKAkyBJIHdpbGwgZ2V0IGJhY2sg bGF0ZXIgb24gdGhlIG90aGVyIGlzc3VlcyB1bmRlciBkaXNjdXNzaW9uDQoNCkZyb206IEtvbmRh LCBUaXJ1bWFsZXN3YXIgUmVkZHkgW21haWx0bzogVGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNh ZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbT5dDQpTZW50 OiAwNiBPY3RvYmVyIDIwMTcgMTQ6NTgNClRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgSm9uIFNoYWxsb3c7ICdEb2Ji aW5zLCBSb2xhbmQnOyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVj dDogUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSSBkb27igJl0IHNlZSBh IG5lZWQgZm9yIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKAnERPVFMg Y2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4g4oCcRE9UUyBjbGllbnQgaWRl bnRpdHnigJ0gbG9va3MgcmVxdWlyZWQgb25seSBmb3IgdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0 ZXdheXMuIEluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5 IHRoZSBjbGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR5 4oCdIHRvIHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1 bmlxdWUgY2xpZW50LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4gYXJyYXkgb2YgY2xp ZW50LWlkcyB0byB0aGUgRE9UUyBzZXJ2ZXIgdG8gcmVzb2x2ZSBjbGFzaGVzLg0KDQotVGlydQ0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRv dHMgbWFpbGluZyBsaXN0DQoNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQoN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQo= --_000_DM5PR16MB17883980E80C0FB5A4B69481EA750DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1 IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7 DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNl cmlmOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFj azt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpi bGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBVSSIsc2Fu cy1zZXJpZjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRl IGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30N CnAuVGV4dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxsZXMNCgl7 bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRl IGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1h bDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVt YWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMzUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUzNg0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+VGhlIGNvbmZsaWN0aW5nIGFsaWFzLW5hbWVzIGZyb20g RE9UUyBjbGllbnQgKGMxKSBhbmQgYW5vdGhlciBjbGllbnQgKGxldOKAmSBjYWxsIChjMTEpKSBi ZWhpbmQgKHMxKSBzaG91bGQgYmUgcmVzb2x2ZWQgYnkgczEgaXRzZWxmLCBpdCBpcyBhbHNvIHRo ZSByZXNwb25zaWJpbGl0eQ0KIG9mIChzMSkgdG8gcmVzb2x2ZSBjb25mbGljdGluZyBtaXRpZ2F0 aW9uIHJlcXVlc3RzIGZyb20gKGMxKSBhbmQgKGMxMSksIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PmFnZ3JlZ2F0ZSB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIHRoZSBET1RTIGNsaWVudHMg KGMxIGFuZCBjMTEpIGFuZCBzZW5kIHRoZSB1cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCAoYzIp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4tVGlydTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1pZXRmQGpw c2hhbGxvdy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAxMCwgMjAx NyA4OjExIFBNPGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDtU aXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tJmd0Ozsga2FuYW1lIG5pc2hpenVrYSAm bHQ7a2FuYW1lQG50dHY2LmpwJmd0OzsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgZG90 c0BpZXRmLm9yZzsgUm9sYW5kIERvYmJpbnMgJmx0O3Jkb2JiaW5zQGFyYm9yLm5ldCZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdy ZWUgaW4gcGFydCwgYnV0IHdlIG5lZWQgdG8gbG9vayBhdCB0aGUgZW5kIChjMSkgdG8gZW5kIChz MykgcG90ZW50aWFsIGlzc3Vlcy4mbmJzcDsgV2hhdCB5b3UgYXJlIHByb3Bvc2luZyB3b3JrcyBm aW5lIGZvciAoczIpIHRvIChzMykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPihjMSkgcmVxdWVzdHMgbWl0aWdhdGlv biB3aXRoIGFuIGFsaWFzLW5hbWUg4oCcYWxpYXMtMeKAnS4mbmJzcDsgSWYgKHMxKSBkb2VzIG5v dCBwYXNzIGFueXRoaW5nIGV4dHJhIHRvIChjMikgZm9yIG9ud2FyZCB0cmFuc21pc3Npb24sIChz Mikgc2VlcyBhIHNpbmdsZQ0KIGNsaWVudCAoYzIpIHJlcXVlc3RpbmcgbWl0aWdhdGlvbiB3aXRo IGFsaWFzLW5hbWUg4oCcYWxpYXMtMeKAnS4mbmJzcDsgRmluZSwgdGhhdCB3b3Jrcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoZXJlIHdhcyBhbm90aGVyIERPVFMgY2xpZW50 IGluIHRoZSBzYW1lIGxvY2F0aW9uIGFzIChjMSkoaS5lLiBjMWRpZmYpLCBib3RoIHVzaW5nIChz MSkgd2hvIGFsc28gZGVjaWRlZCB0byB1c2UgYWxpYXMtbmFtZSDigJxhbGlhcy0x4oCdIHdobyB0 aGVuDQogcmVxdWVzdHMgbWl0aWdhdGlvbiwgKHMyKSBoYXMgbm8gaWRlYSB0aGF0IHRoZXJlIGFy ZSBkaWZmZXJlbnQg4oCcYWxpYXMtMeKAnSBkZWZpbml0aW9ucyBpZiAoYzIpIGRvZXMgbm90IHNl bmQgYWxzbyBhbiBleHRyYSBkaWZmZXJlbnRpYXRvci4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbywgYW55IERP VFMgR1cgaW4gdGhlIGNoYWluIHNob3VsZCBiZSBwYXNzaW5nIG9uIGEg4oCcdW5pcXVlLWV4dHJh 4oCdIHBpZWNlIG9mIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pkpvbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBEb3RzIFttYWlsdG86DQo8YSBo cmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Lb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5PGJyPg0K PGI+U2VudDo8L2I+IDEwIE9jdG9iZXIgMjAxNyAxNToxNTxicj4NCjxiPlRvOjwvYj4gSm9uIFNo YWxsb3c7IGthbmFtZSBuaXNoaXp1a2E7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIj4NCm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVm PSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5z PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2Vz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+QWdyZWUg d2l0aCB5b3VyIHJlc3BvbnNlLCBjb25zaWRlciBhIGRlcGxveW1lbnQgd2hpY2ggaGFzIHRoZSBm b2xsb3dpbmcgRE9UUyBhZ2VudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij5ET1RTIGNsaWVudHMgKGMxKQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjp3aW5kb3d0ZXh0Ij7Dnzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+LS0tLS0tLS0tLS0tLS0tLTwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7 Y29sb3I6d2luZG93dGV4dCI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPg0KIChzMSkgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IChjMikgPC9zcGFuPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s b3I6d2luZG93dGV4dCI+w588L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi Pi0tLS0tLS0tLS0tLTwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOndpbmRvd3RleHQiPsOgPC9zcGFuPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPihzMikgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IChj MykNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5n ZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+w588L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPi0tLS0tLS0tLS08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOndpbmRvd3RleHQiPsOgPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4NCiAoczMpIERPVFMgc2VydmVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5NeSBwb2ludCBpcywgKGMyKSBu ZWVkIG5vdCBjb252ZXkgdGhlIOKAnGMxIGlkZW50aXR54oCdIHRvIChzMikgYnV0IChzMikgbmVl ZHMgdG8gY29udmV5IHRoZSDigJxjMiBpZGVudGl0eeKAnSB0byAoYzMpIGFuZCAoYzMpIGluLXR1 cm4gcHJvcGFnYXRlcyB0aGUg4oCcYzIgaWRlbnRpdHnigJ0NCiB0byAoczMpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3 aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+LVRpcnU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gSm9uIFNoYWxsb3cgWzxhIGhyZWY9 Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tIj5tYWlsdG86c3VwanBzLWlldGZAanBz aGFsbG93LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAxMCwg MjAxNyA2OjE1IFBNPGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZs dDs8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+VGly dW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTwvYT4mZ3Q7OyBrYW5hbWUgbmlzaGl6dWth ICZsdDs8YSBocmVmPSJtYWlsdG86a2FuYW1lQG50dHY2LmpwIj5rYW5hbWVAbnR0djYuanA8L2E+ Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5v cmciPg0KZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWls dG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgVGlydSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWdyZWVkIHRo YXQgb25seSBhIERPVFMgR1cgc2VydmVyIGZhY2luZyBuZWVkcyB0byBzZW5kIGluZm9ybWF0aW9u IHRvIHRoZSB1cHN0cmVhbSBET1RTIFNlcnZlciDigJMgd2hpY2ggY291bGQgYWxzbyBiZSBhIERP VFMgR1cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRCB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0mIzQzOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwgTyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8IGMxIHwtLS0tLS0tLS0tfCBzMSB8IFQgfCBjMiB8LS0tLS0tLS0t fCBzMiB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tJiM0Mzsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZu YnNwOyZuYnNwOyZuYnNwOyB8IFMgfCZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLSYjNDM7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyB8IEcgfCZuYnNwOyZuYnNwOyZuYnNwOyB8PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWRvdHMtYXJjaGl0ZWN0dXJlLTA0I3NlY3Rpb24tMi4yLjMiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtYXJjaGl0ZWN0dXJlLTA0I3NlY3Rpb24tMi4yLjM8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIHRoZSBET1RTIEdXIGNsaWVudCBmYWNpbmcgKHMxKSBp cyB0aGUgb25lIHdpdGgga25vd2xlZGdlIG9mIHRoZSBpbmRpdmlkdWFsIGNsaWVudHMgdGhhdCBh cmUgY3VycmVudGx5IHVzaW5nICZuYnNwO3RoZSBET1RTIHNlcnZlciBydW5uaW5nIG9uDQogdGhl IERPVFMgR1cuJm5ic3A7IFRoaXMgaW5mb3JtYXRpb24gaGFzIHRvIHNvbWVob3cgYmUgcGFzc2Vk IG92ZXIgdG8gdGhlIERPVFMgR1cgc2VydmVyIGZhY2luZyAoYzIpLCBidXQgc2VwYXJhdGUgRE9U UyBzdGFja3MgYXJlIGJlaW5nIHJ1biBmb3IgKHMxKSBhbmQgKGMyKSBhcyBwZXIgYXJjaGl0ZWN0 dXJlIHNwZWMgMi4yLjMuJm5ic3A7IEkgd2FzIHJlZmVycmluZyB0byB3aGF0IChzMSkgbWF5IG5l ZWQgdG8gcGFzcyBvbiB0byAoYzIpIGluIG15IGVtYWlsIHJlc3BvbnNlDQogdG8gS2FuYW1lLCBu b3Qgd2hhdCBpcyBzZW50IGJ5IChjMSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Sm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBEb3RzIFttYWlsdG86DQo8YSBocmVm PSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Lb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5PGJyPg0KPGI+ U2VudDo8L2I+IDEwIE9jdG9iZXIgMjAxNyAxMzoxNjxicj4NCjxiPlRvOjwvYj4gSm9uIFNoYWxs b3c7ICdrYW5hbWUgbmlzaGl6dWthJzsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9 Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnM8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5JIHRob3Vn aHQgd2UgYWdyZWVkIHRoYXQgYmFzZWQgb24gdGhlIGN1cnJlbnQgRE9UUyByZXF1aXJlbWVudHMg b25seSB0aGUgc2VydmVyLXNpZGUgRE9UUyBHVyBuZWVkcyB0byBjb252ZXkgdGhlIERPVFMgY2xp ZW50IChvciBjbGllbnQtc2lkZSBET1RTIFdHKSBpZGVudGl0eQ0KIHRvIHRoZSBET1RTIHNlcnZl ci4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4tVGly dTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBKb24gU2hh bGxvdyBbPGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20iPm1haWx0bzpz dXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5 LCBPY3RvYmVyIDEwLCAyMDE3IDI6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+ICdrYW5hbWUgbmlzaGl6 dWthJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthbmFtZUBudHR2Ni5qcCI+a2FuYW1lQG50dHY2Lmpw PC9hPiZndDs7IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0OzxhIGhyZWY9Im1haWx0bzpU aXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBNY0FmZWUuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1h aWx0bzpkb3RzQGlldGYub3JnIj4NCmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmlucyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+cmRvYmJpbnNAYXJib3IubmV0 PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENo YWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEthbmFtZSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SSBkbyBub3QgdGhpbmsgdGhhdCBpbmZvcm1hdGlvbiBuZWNlc3NhcmlseSBuZWVk cyB0byBiZSB0aGUgb3JpZ2luYWwgY2xpZW50IGlkZW50aXR5LiZuYnNwOyBUaGUgR1cgQ2xpZW50 IHNpZGUgd2lsbCBoYXZlIGl0cyBvd24gaWRlbnRpdHkgd2hpY2ggdGhlIERPVFMNCiBTZXJ2ZXIg Y2FuIHVzZSB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gRE9UUyAoR1cpIENsaWVudHMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlNvLCB5ZXMsIGEgaGFzaGVkIHNldCBvZiBuYW1lcyBjYW4gYmUgdXNlZCDigJMgaXQg aXMgdXAgdG8gdGhlIERPVFMgR1cgQ2xpZW50IHNpZGUgdG8gbWFrZSBzdXJlIHRoYXQgdGhlcmUg YXJlIG5vIGhhc2ggY29sbGlzaW9ucy4mbmJzcDsgT3IgaXQgY291bGQgYmUNCiBhIHNpbXBsZSBs aXN0IHN1Y2ggYXMgQzEsIEMyIOKApkNuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gRG90cyBbbWFpbHRvOg0KPGEgaHJl Zj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+ZG90cy1ib3VuY2VzQGlldGYub3JnPC9h Pl0gPGI+T24gQmVoYWxmIE9mDQo8L2I+a2FuYW1lIG5pc2hpenVrYTxicj4NCjxiPlNlbnQ6PC9i PiAxMCBPY3RvYmVyIDIwMTcgMDQ6MTk8YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHk7IEpvbiBTaGFsbG93OyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0i bWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmluczxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF Ti1HQiI+SGksPGJyPg0KPGJyPg0KJmd0OyBJIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUg YXBwbGljYWJsZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0 aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4NCjxicj4NCkkgYWdy ZWUgd2l0aCB0aGlzIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBjYXNlLjxicj4NCkF0IHRoZSBz YW1lIHRpbWUsIEkgYWdyZWUgd2l0aCBiZWxvdzo8YnI+DQomZ3Q7IEkgYWdyZWUgdGhhdCBpcyBu b3QgYSBnb29kIHRoaW5nIHRvIOKAnGxlYWvigJ0gb3V0IGludGVybmFsIGluZm9ybWF0aW9uIHdo ZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHVywNCjxicj4NCjxicj4NClRoZW4sIHNob3VsZCBE T1RTIEdXIHNlbmQg4oCcY2xpZW50IGlkZW50aXR54oCdIChpLmUuIGNlcnRpZmljYXRlcyBvZiBE T1RTIGNsaWVudHMpIGl0c2VsZiBvciBoYXNoZWQo4oCcY2xpZW50IGlkZW50aXR54oCdKSB0byBE T1RTIHNlcnZlcj88YnI+DQpJZiBsYXRlciwgaG93IGNhbiBET1RTIHNlcnZlciByZWFjdCB0byB0 aGUgYW1iaWd1b3VzIGluZm9ybWF0aW9uIG9mIHRoZSBoYXNoZWQo4oCcY2xpZW50IGlkZW50aXR5 4oCdKS48YnI+DQo8YnI+DQpyZWdhcmRzLDxicj4NCkthbmFtZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gMjAx Ny8xMC8wOSAyMjozNCwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+SGkgSm9uLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5JIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJsZSBmb3Igc2VydmVy LXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR5 4oCdIHRvIHRoZSBET1RTIHNlcnZlci4gQnV0IGZvciB0aGUgY2xpZW50LXNpZGUgRE9UUyBnYXRl d2F5LA0KIGl0IHNob3VsZCByZXNvbHZlIGNvbmZsaWN0aW5nIHJ1bGVzIGIvdyBET1RTIGNsaWVu dHMgKGUuZy4gb25lIGNsaWVudCBpbnN0YWxsaW5nIGJsYWNrLWxpc3QgQUNMIGZvciBhbiBJUCBh ZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xpZW50IGluc3RhbGxzIHdoaXRlLWxpc3QgQUNMIGZvciB0 aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1lIGFsaWFzLW5hbWVzIGZvciBkaWZmZXJlbnQgbWl0aWdh dGlvbiBzY29wZXMpLiBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkDQogZm9yIGEgY2xpZW50LXNpZGUg RE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBz ZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgb3IgRE9UUyBzZXJ2ZXIuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPi1UaXJ1PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBK b24gU2hhbGxvdyBbPGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20iPm1h aWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBT YXR1cmRheSwgT2N0b2JlciA3LCAyMDE3IDI6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBU aXJ1bWFsZXN3YXIgUmVkZHkgPGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRh QE1jQWZlZS5jb20iPg0KJmx0O1RpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7 PC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYu b3JnIj5kb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnMNCjxhIGhyZWY9Im1haWx0bzpy ZG9iYmluc0BhcmJvci5uZXQiPiZsdDtyZG9iYmluc0BhcmJvci5uZXQmZ3Q7PC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGRpc2N1c3Npb24gZ29l cyBiZXlvbmQganVzdCB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0LiZuYnNwOyBXZSBuZWVkIHRvIGNv bnNpZGVyIHdoYXQgaGFwcGVucyB3aXRoIGJvdGggYWxpYXMtbmFtZSBhbmQgYWNsLW5hbWUgKGRh dGEgY2hhbm5lbCk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBzaW1wbGUgY2FzZSBvZiBhIG1pdGlnYXRpb24gcmVxdWVz dCB3aXRoIG5vIGFsaWFzLW5hbWUgZG9lcyBub3QgcmVxdWlyZSBhbnkga25vd2xlZGdlIG9mIHRo ZSBvcmlnaW5hbCBjbGllbnQuJm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIGlmIHRoZSBtaXRpZ2F0 aW9uIHJlcXVlc3QgdXNlcyBhbGlhcy1uYW1lLCB0aGVuIHRoZXJlIGFyZSAzIHdheXMgb2YgaGFu ZGxpbmcgdGhpczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4i PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YSk8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgRE9UUyBHVyByZXBsYWNlcyB0aGUgYWxp YXMtbmFtZSB3aXRoIGl0cyBhY3R1YWwgZGVmaW5pdGlvbiAodGFyZ2V0LWlwcyBldGMuIG1lcmdl ZCBhcyBhcHByb3ByaWF0ZSksIHNvIGFsaWFzLW5hbWUgaXMgbm90IGZvcndhcmRlZCBvbiB0byBT ZXJ2ZXIg4oCTIGp1c3QgdGhlDQogZXhwYW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGZvcndh cmRlZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Yik8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGUgRE9UUyBHVyB1cGRhdGVzIHRoZSBhbGlhcy1uYW1lIHdpdGgg YSB1bmlxdWUgYWxpYXMtbmFtZSB0aGF0IGlzIGZvcndhcmRlZCAoYW5kIGhhcyB0byBkbyB0aGUg c2FtZSB0aGluZyB3aGVuIHRoZSBhbGlhcy1uYW1lIGlzIGNvbmZpZ3VyZWQgb24gdGhlIGRhdGEg Y2hhbm5lbCkNCiDigJMgdG8gaGFuZGxlIDIgb3IgbW9yZSBjbGllbnRzIGRlZmluaW5nIHRoZSBz YW1lIGFsaWFzLW5hbWUgd2hpY2ggaGF2ZSBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNzPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5jKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoZSBET1RTIEdXIHJlY29nbmlzZXMgdGhhdCBhbGlhcy1uYW1lIGlzIG5v dCB1bmlxdWUgYW5kIGFkZHMgaW4g4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSAoSSB0aGlu ayBJIHByZWZlciB0aGlzIOKAnC1pbmZv4oCdIG5hbWUgdG8gY2xpZW50LWlkIG9yIG9yaWdpbmFs LWNsaWVudC1pZA0KIGFzIOKAnC1pZOKAnSBpcyB0b28gY2xvc2VseSAmbmJzcDthc3NvY2lhdGVk IHdpdGggQ2xpZW50IElkZW50aXR5IGRlcml2ZWQgZnJvbSB0aGUgRE9UUyBHVyBDbGllbnQgY2Vy dGlmaWNhdGUpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPldlIGhhdmUgYWdyZWVkIHRoYXQgd2hlbiBhIGNsaWVudCByZXF1ZXN0cyBtaXRp Z2F0aW9uIHN0YXR1cywgdGhlIOKAnGFsaWFzLW5hbWXigJ0gc2hvdWxkIGJlIHJldHVybmVkIGFz IOKAnGFsaWFzLW5hbWXigJ0gYW5kIG5vdCB0aGUgc3Vic3RpdHV0ZWQgYWxpYXMtbmFtZQ0KIGNv bmZpZ3VyYXRpb24gKHRoaXMgZG9lcyBuZWVkIHRvIGJlIHN0YXRlZCBpbiB0aGUgc3BlYyBmb3Ig Y2xhcml0eSkuJm5ic3A7IFRoaXMgbWFrZXMgKGEpIGRpZmZpY3VsdCB0byBiZSBoYW5kbGVkIGJ5 IERPVFMgR1cgd2hpY2ggdGhlbiByYWlzZXMgdGhlIHF1ZXN0aW9uIOKAkyBkbyB3ZSByZWFsbHkg bmVlZCBhbGlhcy1uYW1lPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGRlZmluaXRpb24gYW5kIGFzc29jaWF0aW9uIG9m IEFDTHMvRmlsdGVycyBvZiB0aGUgZGF0YSBjaGFubmVsIGlzIG1vcmUgZGlmZmljdWx0IOKAkyB0 aGUgU2VydmVyIG11c3QgaW5zdGFsbCAvIGFwcGx5IHRoZSBhcHByb3ByaWF0ZSBBQ0xzIG9uIGEN CiBwZXIgKE9yaWdpbmFsKSBDbGllbnQgYmFzaXMgd2hlbiBtaXRpZ2F0aW9uIGlzIGludm9rZWQu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkNsaWVudCAx4oCZcyBjb25jZXB0IG9mIGEgV2hpdGVsaXN0IElQIGNvdWxkIGJlIENsaWVudCAy 4oCZcyBjb25jZXB0IG9mIGEgQmxhY2tsaXN0IElQLiZuYnNwOyBUaGUgU2VydmVyIG5lZWRzIHRv IGtub3cgd2hpY2ggY2xpZW50IGlzIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24NCiBhbmQgaW5z dGFsbCB0aGUgY29ycmVjdCBBQ0xzIOKAkyBpZiB0aGVyZSB3YXMgbm8g4oCdYWRkaXRpb25hbC1j bGllbnQtaW5mb+KAnSwgdGhlIFNlcnZlciBvbmx5IGtub3dzIHRoYXQgaGUgaGFzIHRvIGluc3Rh bGwgQUxMIG9mIHRoZSBBQ0xzIChpLmUuIGJvdGggdGhlIEJsYWNrIGFuZCBXaGl0ZSBsaXN0IG9m IHRoZSBzYW1lIElQIGFzIGRlZmluZWQgYnkgQ2xpZW50IDEgYW5kIENsaWVudCAyKSBhcyBkZWZp bmVkIGJ5IGhpcyBjbGllbnQgKERPVFMgR1cpDQogd2hlbiBoaXMgY2xpZW50IHJlcXVlc3RzIGEg bWl0aWdhdGlvbi4mbmJzcDsgSGVyZSwgSSB0aGluayB0aGF0IGlmIHRoZXJlIGlzIG1vcmUgdGhh biBvbmUgY2xpZW50IGZvciB0aGUgRE9UUyBHVywg4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KA nSBpcyByZXF1aXJlZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpvbjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYi PiBEb3RzIFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5k b3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Lb25kYSwgVGly dW1hbGVzd2FyIFJlZGR5PGJyPg0KPGI+U2VudDo8L2I+IDA3IE9jdG9iZXIgMjAxNyAwNDoyODxi cj4NCjxiPlRvOjwvYj4gSm9uIFNoYWxsb3c7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsNCjxhIGhy ZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJp bnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5n ZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+SW4gY2FzZSBvZiBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksIHdo eSBkb2VzIHRoZSBET1RTIHNlcnZlciBuZWVkIHRvIGtub3cgd2hpY2gg4oCcRE9UUyBjbGllbnTi gJ0gaGFzIGNvbnZleWVkIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgPzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Rm9yIGV4YW1wbGUsIHRoZSBET1RTIGNsaWVudCBj b3VsZCBiZSBhIEREb1MgZGV0ZWN0b3Igb3IgYW4gQXBwbGljYXRpb24gc2VydmVyLCBhbmQgdGhl IGNsaWVudC1zaWRlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHJlc29sdmUgdGhlIGNvbmZsaWN0aW5n IG1pdGlnYXRpb24gcmVxdWVzdHMNCiBmcm9tIHRoZSBET1RTIGNsaWVudHMsIGFnZ3JlZ2F0ZSB0 aGUgbWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIHRoZSBET1RTIGNsaWVudCBhbmQgc2VuZCB0aGUg dXBkYXRlZCBtaXRpZ2F0aW9uIHJlcXVlc3QgdG8gdGhlIERPVFMgc2VydmVyLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tVGlydTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gSm9uIFNoYWxsb3cgWzxhIGhyZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cu Y29tIj5tYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDYsIDIwMTcgNzo0MiBQTTxicj4NCjxiPlRvOjwvYj4gS29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJl ZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208 L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5t b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0 Zi5vcmciPg0KZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJt YWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Vbmxlc3MgSSBhbSBtaXNz aW5nIHNvbWV0aGluZywgaG93IGRvZXMgdGhlIENsaWVudCBzaWRlIG9mIERPVFMgR1cgY29udmV5 IHRvIHRoZSB1cHN0cmVhbSBzZXJ2ZXIgYSB1bmlxdWUg4oCcY2xpZW50LWlk4oCdIHdoaWNoIGlz IGRpZmZlcmVudCB0byB0aGUgaW1wbGllZA0KIGNsaWVudCBpZCBhcyBkZXJpdmVkIGZyb20gdGhl IFBLSSBjZXJ0aWZpY2F0ZSB0aGF0IHRoZSBET1RTIEdX4oCZQ2xpZW50IHVzZXMvcHJlc2VudHMg d2hlbiBjb21tdW5pY2F0aW5nIHRvIHRoZSBzZXJ2ZXI/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvIG1lLCB0aGVyZSBuZWVkcyB0byBi ZSBhbiBvcHRpb24gc3VjaCBhcyDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0gb3Ig4oCcY2xpZW50 LWlk4oCdICh3aGljaCBpcyBjb25mdXNpbmcgd2hlbiBhbHNvIHJlZmVycmluZyB0byB0aGUgY2xp ZW50IGlkZW50aXR5IGFzDQogZGVyaXZlZCBmcm9tIHRoZSAoRE9UUyBHVykgQ2xpZW504oCZcyBQ S0kgY2VydGlmaWNhdGUpIGFzIGEgcGFydCBvZiB0aGUgcHJvdG9jb2wuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVl IHRoYXQgdGhlIERPVFMgR1cgY2FuIGdlbmVyYXRlIGl0cyBvd24gdW5pcXVlIGNsaWVudC1pZCB0 byBzdG9wIG11bHRpcGxlIGVudHJpZXMgYmVpbmcgbmVlZGVkLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0 IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5mb3JtYXRp b24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLCBzbyBteSBSRVFVSVJFRCBkb2VzIG5v dCBtYWtlIHNlbnNlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9uPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBTIOKAkyBJIGFtIGhhdmlu ZyB0byBkZWFsIHdpdGggb3RoZXIgc3R1ZmYgYXQgcHJlc2VudCDigJMgSSB3aWxsIGdldCBiYWNr IGxhdGVyIG9uIHRoZSBvdGhlciBpc3N1ZXMgdW5kZXIgZGlzY3Vzc2lvbjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWYiPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86 VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbSI+VGlydW1hbGVzd2FyUmVkZHlfS29u ZGFAbWNhZmVlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDYgT2N0b2JlciAyMDE3IDE0 OjU4PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IEpvbiBTaGFsbG93OyAn RG9iYmlucywgUm9sYW5kJzsNCjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGll dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMg Q2hhbGxlbmdlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGRvbuKAmXQgc2VlIGEgbmVlZCBmb3IgY2xpZW50 LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHni gJ0gdG8gdGhlIERPVFMgc2VydmVyLiDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSBsb29rcyBy ZXF1aXJlZCBvbmx5IGZvciB0aGUgc2VydmVyLXNpZGUNCiBET1RTIGdhdGV3YXlzLiBJbiBjYXNl IG9mIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgY2FuIGNvbnZleSB0aGUgY2xpZW50LWlk IGdlbmVyYXRlZCBmcm9tIHRoZSDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9U UyBzZXJ2ZXIuIFRoZSBET1RTIGdhdGV3YXkgY2FuIGdlbmVyYXRlIGEgdW5pcXVlIGNsaWVudC1p ZCBhbmQgZG9lcyBub3QgaGF2ZSB0byBzZW5kIGFuIGFycmF5IG9mIGNsaWVudC1pZHMgdG8gdGhl IERPVFMgc2VydmVyDQogdG8gcmVzb2x2ZSBjbGFzaGVzLiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+LVRpcnU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1HQiI+RG90cyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPjxhIGhyZWY9Im1haWx0bzpEb3RzQGlldGYu b3JnIj5Eb3RzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1HQiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kb3RzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8L2E+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB17883980E80C0FB5A4B69481EA750DM5PR16MB1788namp_-- From nobody Tue Oct 10 07:58:11 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FAB134E1C for ; Tue, 10 Oct 2017 07:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLk1EKjbzCN4 for ; Tue, 10 Oct 2017 07:58:05 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 33712134E1D for ; Tue, 10 Oct 2017 07:56:58 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e1vxn-0003KG-Qj; Tue, 10 Oct 2017 15:56:55 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "kaname nishizuka" , , , "Roland Dobbins" References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0da501d341c7$6460d000$2d227000$@jpshallow.com> In-Reply-To: Date: Tue, 10 Oct 2017 15:56:57 +0100 Message-ID: <0e1601d341d8$0531af80$0f950e80$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E17_01D341E0.66FAD270" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIAJQ6kjUASRe9X8Bri7ZGgMYlBpaAoe6cxMBQFNvqgFkSg1OAZuM5lSiX/fYkA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 14:58:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E17_01D341E0.66FAD270 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 See inline. =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy Sent: 10 October 2017 15:34 To: Jon Shallow; dots@ietf.org; kaname nishizuka; Roland Dobbins; = mohamed.boucadair@orange.com Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi Jon, =20 Please see inline =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 6:28 PM To: Konda, Tirumaleswar Reddy ; = dots@ietf.org; kaname nishizuka ; Roland Dobbins = ; mohamed.boucadair@orange.com Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 I am having trouble parsing this =E2=80=93 it is definition of terms = =E2=80=93 server and client when referring to DOTS Client, DOTS Server = and DOTS Gateway. I think there is a typo. [I many times have got = muddled in my thinking when referring to, say, DOTS GW client side = =E2=80=93 which actually is a DOTS server in its own rights.] =20 [TR] The DOTS client certificate may not fit within the path MTU. The = alternative approach is, the server-side DOTS GW computes SHA-256 of the = Subject Public Key Info (SPKI) of the client certificate and send the = hashed output to the DOTS server in the new client-id parameter (see = https://tools.ietf.org/html/rfc7469#section-2.4). SHA-256 is resistant = to collisions. Further, server-side DOTS gateway and DOTS server are in = the same domain operating the EST server, DOTS client will be using the = certificate provisioned by the EST server to authenticate itself to the = server-side DOTS gateway and I don=E2=80=99t see any ambiguous = information in the hashed client identity generated and conveyed by the = server-side DOTS gateway to the DOTS server. To me, server-side DOTS gateway definition is the upstream DOTS server = facing part of the DOTS Gateway =E2=80=93 c2 in =20 +-------------+ | | D | | +----+ | | O | | +----+ | c1 |----------| s1 | T | c2 |---------| s2 | +----+ | | S | | +----+ | | G | | +-------------+ https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-2.2.3= =20 Issue 1 =3D=3D=3D=3D=3D=3D=3D=3D So how does =E2=80=9CDOTS client will be using the certificate = provisioned by the EST server to authenticate itself to the server-side = DOTS gateway=E2=80=9D work? - ((c1) to (c2) is illegal!) =20 [TR] c1 authenticates to s1 using the certificate it received from the = EST server in the same domain as s1, c2 and s2. [Jon], So your text should really have read =E2=80=9CDOTS client will be = using the certificate provisioned by the EST server to authenticate = itself to the client-side DOTS gateway=E2=80=9D. =20 Issue 2 =3D=3D=3D=3D=3D =E2=80=9Cserver-side DOTS gateway and DOTS server are in the same domain = operating the EST server, DOTS client will be using the certificate = provisioned by the EST server=E2=80=9D =20 Whilst (c2) and (s2) will be in the same domain for mutual = authentication, the same is not necessarily true for (c1) and (s2). =20 =20 However the use of SPKI will work if all the (c1) type clients talking = to (s1) are using PKI. =20 =20 [TR] The assumption is DOTS agents in different domains must use PKI for = mutual authentication. [Jon] To me a DOTS GW is the break point between 2 different domains. =20 =E2=80=9CSEC-001=E2=80=9D in requirements spec states SEC-001 Peer Mutual Authentication: DOTS agents MUST authenticate each other before a DOTS signal or data channel is considered valid. The method of authentication is not specified, but should follow current industry best practices with respect to any cryptographic mechanisms to authenticate the remote peer. =E2=80=9C3.1.2 Establishing the DOTS Session=E2=80=9D in the = architecture spec states For example, a DOTS client may be directly configured to use a specific DOTS server IP address and port, and directly provided with any data necessary to satisfy the Peer Mutual Authentication requirement in [I-D.ietf-dots-requirements], such as symmetric or asymmetric keys, usernames and passwords, etc. All configuration and authentication information in this scenario is provided out-of-band by the domain operating the DOTS server. [Jon] This does not say it has to be PKI. =20 =20 =20 If there is another trust mechanism for (c1)<->((s1), then it is going = to have to be a hash on something different. =20 [TR] Yes, we can propose SPKI as one mechanisms (since s1, c2 and s3 are = in the same domain, they all will be aware of the alternate trust = mechanism). [Jon] Not so easy if the DOTS domains use different mutual = authentication. =20 -Tiru =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 12:53 To: kaname nishizuka; Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi Kaname, =20 Please see inline =20 From: Dots [ = mailto:dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: Tuesday, October 10, 2017 8:49 AM To: Konda, Tirumaleswar Reddy < = = TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow < = supjps-ietf@jpshallow.com>; = mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins < = rdobbins@arbor.net> Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi, > I agree the below problems are applicable for server-side DOTS = gateway, it must convey the =E2=80=9Cclient identity=E2=80=9D to the = DOTS server.=20 I agree with this server-side DOTS gateway case. At the same time, I agree with below: > I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW,=20 Then, should DOTS GW send =E2=80=9Cclient identity=E2=80=9D (i.e. = certificates of DOTS clients) itself or hashed(=E2=80=9Cclient = identity=E2=80=9D) to DOTS server? If later, how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient identity=E2=80=9D). [TR] The DOTS client certificate may not fit within the path MTU. The = alternative approach is, the server-side DOTS GW computes SHA-256 of the = Subject Public Key Info (SPKI) of the client certificate and send the = hashed output to the DOTS server in the new client-id parameter (see = https://tools.ietf.org/html/rfc7469#section-2.4). SHA-256 is resistant = to collisions. Further, server-side DOTS gateway and DOTS server are in = the same domain operating the EST server, DOTS client will be using the = certificate provisioned by the EST server to authenticate itself to the = server-side DOTS gateway and I don=E2=80=99t see any ambiguous = information in the hashed client identity generated and conveyed by the = server-side DOTS gateway to the DOTS server. -Tiru regards, Kaname On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote: Hi Jon, =20 I agree the below problems are applicable for server-side DOTS gateway, = it must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. = But for the client-side DOTS gateway, it should resolve conflicting = rules b/w DOTS clients (e.g. one client installing black-list ACL for an = IP address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server. =20 -Tiru =20 From: Jon Shallow [ = mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:07 PM To: Konda, Tirumaleswar Reddy = = ; = mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; = Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [ = mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy < = = TirumaleswarReddy_Konda@McAfee.com>; = mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins < = rdobbins@arbor.net> Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; = Jon Shallow; 'Dobbins, Roland'; dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru =20 _______________________________________________ Dots mailing list Dots@ietf.org = https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0E17_01D341E0.66FAD270 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline.

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 15:34
To: Jon Shallow; dots@ietf.org; kaname nishizuka; Roland = Dobbins; mohamed.boucadair@orange.com
Subject: Re: [Dots] DOTS = Gateways Challenges

 

Hi Jon,

 

Please see inline

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 6:28 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org; kaname nishizuka <kaname@nttv6.jp>; Roland Dobbins = <rdobbins@arbor.net>; mohamed.boucadair@orange.com=
Subject: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

I am having trouble parsing this =E2=80=93 it is definition of terms = =E2=80=93 server and client when referring to DOTS Client, DOTS Server = and DOTS Gateway.  I think there is a typo.  [I many times = have got muddled in my thinking when referring to, say, DOTS GW client = side =E2=80=93 which actually is a DOTS server in its own = rights.]

 

[TR] The DOTS client certificate may not fit = within the path MTU. The alternative approach is, the server-side DOTS = GW computes SHA-256 of the Subject Public Key Info (SPKI) of the client = certificate and send the hashed output to the DOTS server in the new = client-id parameter (see https://tools.ie= tf.org/html/rfc7469#section-2.4). SHA-256 is resistant to = collisions. Further, server-side DOTS gateway and DOTS server are in the = same domain operating the EST server, DOTS client will be using the = certificate provisioned by the EST server to authenticate itself to the = server-side DOTS gateway and I don=E2=80=99t see any ambiguous = information in the hashed client identity generated and conveyed by the = server-side DOTS gateway to the DOTS server.

To me, server-side DOTS gateway definition is the = upstream DOTS server facing part of the DOTS Gateway =E2=80=93 c2 = in

 

      =             &= nbsp;      +-------------+

          = ;            =    |    | D |    = |

         = +----+          = |    | O |    = |         = +----+

         | c1 = |----------| s1 | T | c2 |---------| s2 |

         = +----+     =      |    | S = |    |         = +----+

          = ;            =    |    | G |    = |

          = ;            =    +-------------+

https://tools.ietf.org/html/draft-ietf-dots-architecture-04#sec= tion-2.2.3

 

Issue 1

=3D=3D=3D=3D=3D=3D=3D=3D

So how does =E2=80=9CDOTS client will be using the certificate = provisioned by the EST server to authenticate itself to the server-side = DOTS gateway=E2=80=9D work?

- ((c1) = to (c2) is illegal!)

 

[TR] c1 authenticates to s1 using the certificate it received from = the EST server in the same domain as s1, c2 and = s2.

[Jon], So your text should really have read =E2=80=9CDOTS = client will be using the certificate provisioned by the EST server to = authenticate itself to the client-side DOTS = gateway=E2=80=9D.

 

Issue = 2

=3D=3D=3D=3D=3D

=E2=80=9Cserver-side DOTS gateway and DOTS = server are in the same domain operating the EST server, DOTS client will = be using the certificate provisioned by the EST = server=E2=80=9D

 

Whilst = (c2) and (s2) will be in the same domain for mutual authentication, the = same is not necessarily true for (c1) and (s2).

 

 

However the use of SPKI will = work if all the (c1) type clients talking to (s1) are using PKI.  =

 

[TR] The assumption is DOTS agents in different domains must use = PKI for mutual authentication.

[Jon] To me a DOTS GW is the break point between 2 different = domains.=C2=A0

=E2=80=9CSEC-001=E2=80=9D in requirements spec = states

=C2=A0=C2=A0 SEC-001=C2=A0 Peer Mutual Authentication: DOTS agents = MUST authenticate

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 each other before a DOTS signal or = data channel is considered

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 valid.=C2=A0 The method of = authentication is not specified, but should

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 follow current industry best practices = with respect to any

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cryptographic mechanisms to = authenticate the remote peer.

=E2=80=9C3.1.2 Establishing the DOTS Session=E2=80=9D in the = architecture spec states

For example, a DOTS client may be directly = configured

=C2=A0=C2=A0 to use a specific DOTS server IP address and port, and = directly

=C2=A0=C2=A0 provided with any data necessary to satisfy the Peer = Mutual

=C2=A0=C2=A0 Authentication requirement in = [I-D.ietf-dots-requirements], such as

=C2=A0=C2=A0 symmetric or asymmetric keys, usernames and passwords, = etc.=C2=A0 All

=C2=A0=C2=A0 configuration and authentication information in this = scenario is

=C2=A0=C2=A0 provided out-of-band by the domain operating the DOTS = server.

[Jon] This does not say it has to be PKI.=C2=A0 =

=C2=A0

 

If there is another trust = mechanism for (c1)<->((s1), then it is going to have to be a hash = on something different.

 

[TR] Yes, we can propose SPKI as one mechanisms (since s1, c2 and = s3 are in the same domain, they all will be aware of the alternate trust = mechanism).

[Jon] Not so easy if the DOTS domains use different mutual = authentication.

 

-Tiru

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 12:53
To: kaname nishizuka; Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi Kaname,

 

Please see inline

 

From: Dots [mailto:dots= -bounces@ietf.org] On Behalf Of kaname nishizuka
Sent: Tuesday, = October 10, 2017 8:49 AM
To: Konda, Tirumaleswar Reddy = <Tirumaleswa= rReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf= @jpshallow.com>; mohamed.bou= cadair@orange.com; dots@ietf.o= rg; Roland Dobbins <rdobbins@ar= bor.net>
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi,

> I = agree the below problems are applicable for server-side DOTS gateway, it = must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. =
I agree with this server-side DOTS gateway case.
At the same = time, I agree with below:
> I agree that is not a good thing to = =E2=80=9Cleak=E2=80=9D out internal information when passing through a = DOTS GW,

Then, should DOTS GW send =E2=80=9Cclient = identity=E2=80=9D (i.e. certificates of DOTS clients) itself or = hashed(=E2=80=9Cclient identity=E2=80=9D) to DOTS server?
If later, = how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient identity=E2=80=9D).

[TR] The DOTS client certificate may not fit = within the path MTU. The alternative approach is, the server-side DOTS = GW computes SHA-256 of the Subject Public Key Info (SPKI) of the client = certificate and send the hashed output to the DOTS server in the new = client-id parameter (see https://tools.ie= tf.org/html/rfc7469#section-2.4). SHA-256 is resistant to = collisions. Further, server-side DOTS gateway and DOTS server are in the = same domain operating the EST server, DOTS client will be using the = certificate provisioned by the EST server to authenticate itself to the = server-side DOTS gateway and I don=E2=80=99t see any ambiguous = information in the hashed client identity generated and conveyed by the = server-side DOTS gateway to the DOTS server.

-Tiru

regards,
Kaname

On 2017/10/09 22:34, Konda, = Tirumaleswar Reddy wrote:

Hi = Jon,

 

I agree = the below problems are applicable for server-side DOTS gateway, it must = convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. But for = the client-side DOTS gateway, it should resolve conflicting rules b/w = DOTS clients (e.g. one client installing black-list ACL for an IP = address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supj= ps-ietf@jpshallow.com] =
Sent: Saturday, October 7, 2017 2:07 PM
To: Konda, = Tirumaleswar Reddy <Tirumal= eswarReddy_Konda@McAfee.com>; = mohamed.bou= cadair@orange.com; = dots@ietf.o= rg; Roland = Dobbins <rdobbin= s@arbor.net>
Subj= ect: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. 

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)     The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)    The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)     The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely  associated with Client = Identity derived from the DOTS GW Client certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).  This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.  The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.  Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces= @ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:28
To: Jon Shallow; mohamed.bouc= adair@orange.com; = dots@ietf.or= g; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supj= ps-ietf@jpshallow.com] =
Sent: Friday, October 6, 2017 7:42 PM
To: Konda, = Tirumaleswar Reddy <Tirumaleswa= rReddy_Konda@McAfee.com>; = mohamed.bou= cadair@orange.com; = dots@ietf.o= rg; Roland = Dobbins <rdobbins@ar= bor.net>
= Subject: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= Konda, = Tirumaleswar Reddy [mailto: Tirumaleswar= Reddy_Konda@mcafee.com] =
Sent: 06 October 2017 14:58
To: mohamed.bouc= adair@orange.com; Jon = Shallow; 'Dobbins, Roland'; dots@ietf.or= g
Subje= ct: RE: [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 

-Tiru

 

_______________________________________________
Dots mailing =
list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

 

------=_NextPart_000_0E17_01D341E0.66FAD270-- From nobody Tue Oct 10 08:14:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228DF134533 for ; Tue, 10 Oct 2017 08:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=mcafee.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 jjlUGQtLhopo for ; Tue, 10 Oct 2017 08:14:42 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 3E597134FF2 for ; Tue, 10 Oct 2017 08:09:38 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507648177; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=D cFgpY9+EV+aalitDhyYMxJCfCK5MVDXrQlEl6Qe3G 4=; b=gG0XQU8metqxzR8Q1GjN4g7mL8DTV7iWl9pbQOrZlTIy 0n+uJlyC9kLzSbMmiuCS5sBxh35wfjElbKEUBw5EQia95ZvKg/ 5I66/GycUxhjdEzsF06DjQ0MINzwTzcVjfpWZED40sBC9LLJzg MNISpHS0S7qlF1AnUz3Ni93GhTo= Received: from DNVEXAPP1N04.corpzone.internalzone.com (dnvexapp1n04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c29_a81f_7a6764ba_4277_4549_b3c4_eb0c96b1645d; Tue, 10 Oct 2017 10:09:36 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 09:08:17 -0600 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 09:08:15 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Oct 2017 09:08:15 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 09:08:14 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 15:08:13 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 15:08:13 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , kaname nishizuka , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAACzkMAABuu0fgAB0EBwAABJ3VIAAPnrUAAALICxAAAWAMgAAAGzUQ Date: Tue, 10 Oct 2017 15:08:13 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0da501d341c7$6460d000$2d227000$@jpshallow.com> <0e1601d341d8$0531af80$0f950e80$@jpshallow.com> In-Reply-To: <0e1601d341d8$0531af80$0f950e80$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.17.191] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:xTFK4Cie++STLv44faVWvcDf0y54Wf3o/kO4gPRqnEDyfjLn3HVtEjQeZalb/N0V0lwPoRlaTW60jfdmDPRZbqR1G+FiCIEDDd58P9WuxTIAZdhbeMwdVvWxHHlAonHYZpae99wt05h/UER2+AciAC2qeeV0NefRtC0vbQZ71kLbuQf0YSFbJmK+zE85+LTfQyzNo3HyWPd1FSx9oTnv3NiF3XHgR6B/IF3sAiQpX3cHSA1QDDb4Jwft+p/QYwAbxgv6bdVwy8Ej66OR2YEvQ/zqmGwrednJWTYLuwfxDI1ybNYBFwHGQAgVnIDw0SG2Eh/MBi/TJQ74xsdUi7CwEQ==; 5:+39A6Q0sYTNHv8n3dX030kpS2R8gDv+oPQrjK658UPoNe1SuMyBqo3CpQOPU6mLuItnaY71hnINWNBqyzfhPDEIaHu//vu6YXTlMDnr4KMIAQVuID0iKrZ+XLPoKIc433d1/+JRErfpjXnq16xdUZw==; 24:Xyetcbb6JEW6rKkW570QIfgAq6R0MaC2JgQG9qfE9bIjs4+B0Dt0sjzjS1YCTEDw3iQHOQAQ40Xu1dgkjR93F0yqoqK3Jg37kGmDYviXHmY=; 7:7xbRDNaDqN/qSltx0cDtSZ8AVmeb5+x9F0cNWY29ZATojwWe/KU072hTq333KkMCdW4fDZl8C6eZk+69t5wwMBsL/Tv/0wExBkeplcO4/O7RitYMLiByHCRGfVeKTNx458iFy7FLg/IO6TmH+sbJcCSZjN0o6Nm/fyoDgWflImoJF9y3TbMwO7WFXPKDrsF5gNjCeKhM1bvm82gMu8Qh+1qyHqX6mRICnqY4SdqrAu8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 29a0f24a-c5d9-44d4-c5e3-08d50ff0ba1e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(189002)(24454002)(377454003)(32952001)(199003)(51444003)(551544002)(53546010)(236005)(93886005)(2906002)(5660300001)(68736007)(189998001)(33656002)(6436002)(102836003)(6116002)(7736002)(3846002)(790700001)(316002)(2950100002)(14454004)(606006)(110136005)(53936002)(55016002)(99286003)(53946003)(7696004)(86362001)(2201001)(6246003)(9686003)(54896002)(6306002)(966005)(2900100001)(3660700001)(76176999)(25786009)(66066001)(101416001)(50986999)(478600001)(72206003)(54356999)(97736004)(80792005)(2501003)(77096006)(6506006)(229853002)(74316002)(106356001)(3280700002)(8936002)(81156014)(8676002)(105586002)(81166006)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788917FCAFA7B8403915594EA750DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 15:08:13.1314 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6117> : streams <1766660> : uri <2514312> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 15:14:50 -0000 --_000_DM5PR16MB1788917FCAFA7B8403915594EA750DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUjJdDQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBz aGFsbG93LmNvbV0NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgODoyNyBQTQ0KVG86 IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZl ZS5jb20+OyBrYW5hbWUgbmlzaGl6dWthIDxrYW5hbWVAbnR0djYuanA+OyBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tOyBkb3RzQGlldGYub3JnOyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNA YXJib3IubmV0Pg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMN Cg0KSGkgVGlydSwNCg0KU2VlIGlubGluZS4NCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90 cyBbbWFpbHRvOmlldGYtc3VwanBzLWRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNClNlbnQ6IDEwIE9jdG9iZXIgMjAxNyAxNTozNA0K VG86IEpvbiBTaGFsbG93OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsga2Fu YW1lIG5pc2hpenVrYTsgUm9sYW5kIERvYmJpbnM7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpTdWJqZWN0OiBSZTogW0Rv dHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSBKb24sDQoNClBsZWFzZSBzZWUgaW5s aW5lDQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNv bV0NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgNjoyOCBQTQ0KVG86IEtvbmRhLCBU aXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFp bHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PjsgZG90c0BpZXRmLm9yZzxt YWlsdG86ZG90c0BpZXRmLm9yZz47IGthbmFtZSBuaXNoaXp1a2EgPGthbmFtZUBudHR2Ni5qcDxt YWlsdG86a2FuYW1lQG50dHY2LmpwPj47IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5u ZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KU3ViamVjdDogUkU6IFtE b3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KSSBhbSBoYXZpbmcg dHJvdWJsZSBwYXJzaW5nIHRoaXMg4oCTIGl0IGlzIGRlZmluaXRpb24gb2YgdGVybXMg4oCTIHNl cnZlciBhbmQgY2xpZW50IHdoZW4gcmVmZXJyaW5nIHRvIERPVFMgQ2xpZW50LCBET1RTIFNlcnZl ciBhbmQgRE9UUyBHYXRld2F5LiAgSSB0aGluayB0aGVyZSBpcyBhIHR5cG8uICBbSSBtYW55IHRp bWVzIGhhdmUgZ290IG11ZGRsZWQgaW4gbXkgdGhpbmtpbmcgd2hlbiByZWZlcnJpbmcgdG8sIHNh eSwgRE9UUyBHVyBjbGllbnQgc2lkZSDigJMgd2hpY2ggYWN0dWFsbHkgaXMgYSBET1RTIHNlcnZl ciBpbiBpdHMgb3duIHJpZ2h0cy5dDQoNCltUUl0gVGhlIERPVFMgY2xpZW50IGNlcnRpZmljYXRl IG1heSBub3QgZml0IHdpdGhpbiB0aGUgcGF0aCBNVFUuIFRoZSBhbHRlcm5hdGl2ZSBhcHByb2Fj aCBpcywgdGhlIHNlcnZlci1zaWRlIERPVFMgR1cgY29tcHV0ZXMgU0hBLTI1NiBvZiB0aGUgU3Vi amVjdCBQdWJsaWMgS2V5IEluZm8gKFNQS0kpIG9mIHRoZSBjbGllbnQgY2VydGlmaWNhdGUgYW5k IHNlbmQgdGhlIGhhc2hlZCBvdXRwdXQgdG8gdGhlIERPVFMgc2VydmVyIGluIHRoZSBuZXcgY2xp ZW50LWlkIHBhcmFtZXRlciAoc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NDY5 I3NlY3Rpb24tMi40KS4gU0hBLTI1NiBpcyByZXNpc3RhbnQgdG8gY29sbGlzaW9ucy4gRnVydGhl ciwgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGFuZCBET1RTIHNlcnZlciBhcmUgaW4gdGhlIHNh bWUgZG9tYWluIG9wZXJhdGluZyB0aGUgRVNUIHNlcnZlciwgRE9UUyBjbGllbnQgd2lsbCBiZSB1 c2luZyB0aGUgY2VydGlmaWNhdGUgcHJvdmlzaW9uZWQgYnkgdGhlIEVTVCBzZXJ2ZXIgdG8gYXV0 aGVudGljYXRlIGl0c2VsZiB0byB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGFuZCBJIGRv buKAmXQgc2VlIGFueSBhbWJpZ3VvdXMgaW5mb3JtYXRpb24gaW4gdGhlIGhhc2hlZCBjbGllbnQg aWRlbnRpdHkgZ2VuZXJhdGVkIGFuZCBjb252ZXllZCBieSB0aGUgc2VydmVyLXNpZGUgRE9UUyBn YXRld2F5IHRvIHRoZSBET1RTIHNlcnZlci4NClRvIG1lLCBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3 YXkgZGVmaW5pdGlvbiBpcyB0aGUgdXBzdHJlYW0gRE9UUyBzZXJ2ZXIgZmFjaW5nIHBhcnQgb2Yg dGhlIERPVFMgR2F0ZXdheSDigJMgYzIgaW4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgfCBEIHwgICAgfA0K ICAgICAgICAgKy0tLS0rICAgICAgICAgIHwgICAgfCBPIHwgICAgfCAgICAgICAgICstLS0tKw0K ICAgICAgICAgfCBjMSB8LS0tLS0tLS0tLXwgczEgfCBUIHwgYzIgfC0tLS0tLS0tLXwgczIgfA0K ICAgICAgICAgKy0tLS0rICAgICAgICAgIHwgICAgfCBTIHwgICAgfCAgICAgICAgICstLS0tKw0K ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgfCBHIHwgICAgfA0KICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tKw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmUtMDQjc2VjdGlvbi0yLjIuMw0KDQpJc3N1ZSAxDQo9 PT09PT09PQ0KU28gaG93IGRvZXMg4oCcRE9UUyBjbGllbnQgd2lsbCBiZSB1c2luZyB0aGUgY2Vy dGlmaWNhdGUgcHJvdmlzaW9uZWQgYnkgdGhlIEVTVCBzZXJ2ZXIgdG8gYXV0aGVudGljYXRlIGl0 c2VsZiB0byB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F54oCdIHdvcms/DQotICgoYzEpIHRv IChjMikgaXMgaWxsZWdhbCEpDQoNCltUUl0gYzEgYXV0aGVudGljYXRlcyB0byBzMSB1c2luZyB0 aGUgY2VydGlmaWNhdGUgaXQgcmVjZWl2ZWQgZnJvbSB0aGUgRVNUIHNlcnZlciBpbiB0aGUgc2Ft ZSBkb21haW4gYXMgczEsIGMyIGFuZCBzMi4NCltKb25dLCBTbyB5b3VyIHRleHQgc2hvdWxkIHJl YWxseSBoYXZlIHJlYWQg4oCcRE9UUyBjbGllbnQgd2lsbCBiZSB1c2luZyB0aGUgY2VydGlmaWNh dGUgcHJvdmlzaW9uZWQgYnkgdGhlIEVTVCBzZXJ2ZXIgdG8gYXV0aGVudGljYXRlIGl0c2VsZiB0 byB0aGUgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F54oCdLg0KDQpbVFIyXSBBZ3JlZWQuDQoNCklz c3VlIDINCj09PT09DQrigJxzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgYW5kIERPVFMgc2VydmVy IGFyZSBpbiB0aGUgc2FtZSBkb21haW4gb3BlcmF0aW5nIHRoZSBFU1Qgc2VydmVyLCBET1RTIGNs aWVudCB3aWxsIGJlIHVzaW5nIHRoZSBjZXJ0aWZpY2F0ZSBwcm92aXNpb25lZCBieSB0aGUgRVNU IHNlcnZlcuKAnQ0KDQpXaGlsc3QgKGMyKSBhbmQgKHMyKSB3aWxsIGJlIGluIHRoZSBzYW1lIGRv bWFpbiBmb3IgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCB0aGUgc2FtZSBpcyBub3QgbmVjZXNzYXJp bHkgdHJ1ZSBmb3IgKGMxKSBhbmQgKHMyKS4NCg0KDQpIb3dldmVyIHRoZSB1c2Ugb2YgU1BLSSB3 aWxsIHdvcmsgaWYgYWxsIHRoZSAoYzEpIHR5cGUgY2xpZW50cyB0YWxraW5nIHRvIChzMSkgYXJl IHVzaW5nIFBLSS4NCg0KW1RSXSBUaGUgYXNzdW1wdGlvbiBpcyBET1RTIGFnZW50cyBpbiBkaWZm ZXJlbnQgZG9tYWlucyBtdXN0IHVzZSBQS0kgZm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbi4NCltK b25dIFRvIG1lIGEgRE9UUyBHVyBpcyB0aGUgYnJlYWsgcG9pbnQgYmV0d2VlbiAyIGRpZmZlcmVu dCBkb21haW5zLg0K4oCcU0VDLTAwMeKAnSBpbiByZXF1aXJlbWVudHMgc3BlYyBzdGF0ZXMNCiAg IFNFQy0wMDEgIFBlZXIgTXV0dWFsIEF1dGhlbnRpY2F0aW9uOiBET1RTIGFnZW50cyBNVVNUIGF1 dGhlbnRpY2F0ZQ0KICAgICAgZWFjaCBvdGhlciBiZWZvcmUgYSBET1RTIHNpZ25hbCBvciBkYXRh IGNoYW5uZWwgaXMgY29uc2lkZXJlZA0KICAgICAgdmFsaWQuICBUaGUgbWV0aG9kIG9mIGF1dGhl bnRpY2F0aW9uIGlzIG5vdCBzcGVjaWZpZWQsIGJ1dCBzaG91bGQNCiAgICAgIGZvbGxvdyBjdXJy ZW50IGluZHVzdHJ5IGJlc3QgcHJhY3RpY2VzIHdpdGggcmVzcGVjdCB0byBhbnkNCiAgICAgIGNy eXB0b2dyYXBoaWMgbWVjaGFuaXNtcyB0byBhdXRoZW50aWNhdGUgdGhlIHJlbW90ZSBwZWVyLg0K 4oCcMy4xLjIgRXN0YWJsaXNoaW5nIHRoZSBET1RTIFNlc3Npb27igJ0gaW4gdGhlIGFyY2hpdGVj dHVyZSBzcGVjIHN0YXRlcw0KRm9yIGV4YW1wbGUsIGEgRE9UUyBjbGllbnQgbWF5IGJlIGRpcmVj dGx5IGNvbmZpZ3VyZWQNCiAgIHRvIHVzZSBhIHNwZWNpZmljIERPVFMgc2VydmVyIElQIGFkZHJl c3MgYW5kIHBvcnQsIGFuZCBkaXJlY3RseQ0KICAgcHJvdmlkZWQgd2l0aCBhbnkgZGF0YSBuZWNl c3NhcnkgdG8gc2F0aXNmeSB0aGUgUGVlciBNdXR1YWwNCiAgIEF1dGhlbnRpY2F0aW9uIHJlcXVp cmVtZW50IGluIFtJLUQuaWV0Zi1kb3RzLXJlcXVpcmVtZW50c10sIHN1Y2ggYXMNCiAgIHN5bW1l dHJpYyBvciBhc3ltbWV0cmljIGtleXMsIHVzZXJuYW1lcyBhbmQgcGFzc3dvcmRzLCBldGMuICBB bGwNCiAgIGNvbmZpZ3VyYXRpb24gYW5kIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uIGluIHRo aXMgc2NlbmFyaW8gaXMNCiAgIHByb3ZpZGVkIG91dC1vZi1iYW5kIGJ5IHRoZSBkb21haW4gb3Bl cmF0aW5nIHRoZSBET1RTIHNlcnZlci4NCltKb25dIFRoaXMgZG9lcyBub3Qgc2F5IGl0IGhhcyB0 byBiZSBQS0kuDQoNCltUUjJdIFllcywgd2UgbmVlZCB0byBkaXNjdXNzIGluIHRoZSBXRyB0byBt YW5kYXRlIFBLSSBhY3Jvc3MgZG9tYWlucy4gSSBhbSBwbGFubmluZyB0byBwdXQgYSBkcmFmdCB0 byBkaXNjdXNzIHRoZSBwb3NzaWJsZSBtdXR1YWwgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBm b3IgdGhlIFdHIHRvIGRlY2lkZSBtYW5kYXRvcnkgYW5kIG9wdGlvbmFsIG1lY2hhbmlzbXMgdG8g aW1wbGVtZW50IGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpJZiB0aGVyZSBpcyBhbm90aGVyIHRy dXN0IG1lY2hhbmlzbSBmb3IgKGMxKTwtPigoczEpLCB0aGVuIGl0IGlzIGdvaW5nIHRvIGhhdmUg dG8gYmUgYSBoYXNoIG9uIHNvbWV0aGluZyBkaWZmZXJlbnQuDQoNCltUUl0gWWVzLCB3ZSBjYW4g cHJvcG9zZSBTUEtJIGFzIG9uZSBtZWNoYW5pc21zIChzaW5jZSBzMSwgYzIgYW5kIHMzIGFyZSBp biB0aGUgc2FtZSBkb21haW4sIHRoZXkgYWxsIHdpbGwgYmUgYXdhcmUgb2YgdGhlIGFsdGVybmF0 ZSB0cnVzdCBtZWNoYW5pc20pLg0KW0pvbl0gTm90IHNvIGVhc3kgaWYgdGhlIERPVFMgZG9tYWlu cyB1c2UgZGlmZmVyZW50IG11dHVhbCBhdXRoZW50aWNhdGlvbi4NCg0KW1RSMl0gSSBkb27igJl0 IHNlZSBhIHByb2JsZW0sIGlmIGxldOKAmXMgc2F5IHNoYXJlZCBzZWNyZXQgaXMgdXNlZCBmb3Ig bXV0dWFsIGF1dGhlbnRpY2F0aW9uIGIvdyBET1RTIGFnZW50cyB0aGVuIFNIQS0yNTYgY2FuIGJl IGNvbXB1dGVkIGZvciB0aGUgc2hhcmVkIHNlY3JldCwgc2ltaWxhcmx5IGlmIHJhdyBwdWJsaWMg a2V5cyBhcmUgdXNlZCB0aGVuIFNIQS0yNTYgY2FuIGJlIGNhbGN1bGF0ZWQgZm9yIHRoZSByYXcg cHVibGljIGtleS4NCg0KLVRpcnUNCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFp bHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAxMCBPY3RvYmVy IDIwMTcgMTI6NTMNClRvOiBrYW5hbWUgbmlzaGl6dWthOyBKb24gU2hhbGxvdzsgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47 IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucw0KU3Vi amVjdDogUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgS2FuYW1lLA0K DQpQbGVhc2Ugc2VlIGlubGluZQ0KDQpGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2Yga2FuYW1lIG5pc2hpenVrYQ0KU2VudDogVHVlc2RheSwgT2N0 b2JlciAxMCwgMjAxNyA4OjQ5IEFNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGly dW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlf S29uZGFATWNBZmVlLmNvbT4+OyBKb24gU2hhbGxvdyA8c3VwanBzLWlldGZAanBzaGFsbG93LmNv bTxtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbT4+OyBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRm Lm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJv ci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQpTdWJqZWN0OiBSZTogW0RvdHNdIERP VFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSwNCg0KPiBJIGFncmVlIHRoZSBiZWxvdyBwcm9i bGVtcyBhcmUgYXBwbGljYWJsZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0 IGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4NCkkg YWdyZWUgd2l0aCB0aGlzIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBjYXNlLg0KQXQgdGhlIHNh bWUgdGltZSwgSSBhZ3JlZSB3aXRoIGJlbG93Og0KPiBJIGFncmVlIHRoYXQgaXMgbm90IGEgZ29v ZCB0aGluZyB0byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1hdGlvbiB3aGVuIHBhc3Np bmcgdGhyb3VnaCBhIERPVFMgR1csDQoNClRoZW4sIHNob3VsZCBET1RTIEdXIHNlbmQg4oCcY2xp ZW50IGlkZW50aXR54oCdIChpLmUuIGNlcnRpZmljYXRlcyBvZiBET1RTIGNsaWVudHMpIGl0c2Vs ZiBvciBoYXNoZWQo4oCcY2xpZW50IGlkZW50aXR54oCdKSB0byBET1RTIHNlcnZlcj8NCklmIGxh dGVyLCBob3cgY2FuIERPVFMgc2VydmVyIHJlYWN0IHRvIHRoZSBhbWJpZ3VvdXMgaW5mb3JtYXRp b24gb2YgdGhlIGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHnigJ0pLg0KW1RSXSBUaGUgRE9UUyBj bGllbnQgY2VydGlmaWNhdGUgbWF5IG5vdCBmaXQgd2l0aGluIHRoZSBwYXRoIE1UVS4gVGhlIGFs dGVybmF0aXZlIGFwcHJvYWNoIGlzLCB0aGUgc2VydmVyLXNpZGUgRE9UUyBHVyBjb21wdXRlcyBT SEEtMjU2IG9mIHRoZSBTdWJqZWN0IFB1YmxpYyBLZXkgSW5mbyAoU1BLSSkgb2YgdGhlIGNsaWVu dCBjZXJ0aWZpY2F0ZSBhbmQgc2VuZCB0aGUgaGFzaGVkIG91dHB1dCB0byB0aGUgRE9UUyBzZXJ2 ZXIgaW4gdGhlIG5ldyBjbGllbnQtaWQgcGFyYW1ldGVyIChzZWUgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzc0Njkjc2VjdGlvbi0yLjQpLiBTSEEtMjU2IGlzIHJlc2lzdGFudCB0byBj b2xsaXNpb25zLiBGdXJ0aGVyLCBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgYW5kIERPVFMgc2Vy dmVyIGFyZSBpbiB0aGUgc2FtZSBkb21haW4gb3BlcmF0aW5nIHRoZSBFU1Qgc2VydmVyLCBET1RT IGNsaWVudCB3aWxsIGJlIHVzaW5nIHRoZSBjZXJ0aWZpY2F0ZSBwcm92aXNpb25lZCBieSB0aGUg RVNUIHNlcnZlciB0byBhdXRoZW50aWNhdGUgaXRzZWxmIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RT IGdhdGV3YXkgYW5kIEkgZG9u4oCZdCBzZWUgYW55IGFtYmlndW91cyBpbmZvcm1hdGlvbiBpbiB0 aGUgaGFzaGVkIGNsaWVudCBpZGVudGl0eSBnZW5lcmF0ZWQgYW5kIGNvbnZleWVkIGJ5IHRoZSBz ZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgdG8gdGhlIERPVFMgc2VydmVyLg0KLVRpcnUNCg0KcmVn YXJkcywNCkthbmFtZQ0KT24gMjAxNy8xMC8wOSAyMjozNCwgS29uZGEsIFRpcnVtYWxlc3dhciBS ZWRkeSB3cm90ZToNCkhpIEpvbiwNCg0KSSBhZ3JlZSB0aGUgYmVsb3cgcHJvYmxlbXMgYXJlIGFw cGxpY2FibGUgZm9yIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgbXVzdCBjb252ZXkgdGhl IOKAnGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIEJ1dCBmb3IgdGhlIGNs aWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgc2hvdWxkIHJlc29sdmUgY29uZmxpY3RpbmcgcnVs ZXMgYi93IERPVFMgY2xpZW50cyAoZS5nLiBvbmUgY2xpZW50IGluc3RhbGxpbmcgYmxhY2stbGlz dCBBQ0wgZm9yIGFuIElQIGFkZHJlc3MgYnV0IHRoZSBvdGhlciBjbGllbnQgaW5zdGFsbHMgd2hp dGUtbGlzdCBBQ0wgZm9yIHRoZSBzYW1lIElQIGFkZHJlc3MsIHNhbWUgYWxpYXMtbmFtZXMgZm9y IGRpZmZlcmVudCBtaXRpZ2F0aW9uIHNjb3BlcykuIEkgZG9u4oCZdCBzZWUgdGhlIG5lZWQgZm9y IGEgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50 aXR54oCdIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgb3IgRE9UUyBzZXJ2ZXIuDQoN Ci1UaXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93 LmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDcsIDIwMTcgMjowNyBQTQ0KVG86IEtvbmRh LCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+ PG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsgbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRv dHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucyA8cmRvYmJp bnNAYXJib3IubmV0PjxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pg0KU3ViamVjdDogUkU6IFtE b3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KVGhpcyBkaXNjdXNz aW9uIGdvZXMgYmV5b25kIGp1c3QgdGhlIG1pdGlnYXRpb24gcmVxdWVzdC4gIFdlIG5lZWQgdG8g Y29uc2lkZXIgd2hhdCBoYXBwZW5zIHdpdGggYm90aCBhbGlhcy1uYW1lIGFuZCBhY2wtbmFtZSAo ZGF0YSBjaGFubmVsKQ0KDQpUaGUgc2ltcGxlIGNhc2Ugb2YgYSBtaXRpZ2F0aW9uIHJlcXVlc3Qg d2l0aCBubyBhbGlhcy1uYW1lIGRvZXMgbm90IHJlcXVpcmUgYW55IGtub3dsZWRnZSBvZiB0aGUg b3JpZ2luYWwgY2xpZW50Lg0KDQpIb3dldmVyLCBpZiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0IHVz ZXMgYWxpYXMtbmFtZSwgdGhlbiB0aGVyZSBhcmUgMyB3YXlzIG9mIGhhbmRsaW5nIHRoaXMNCg0K YSkgICAgIFRoZSBET1RTIEdXIHJlcGxhY2VzIHRoZSBhbGlhcy1uYW1lIHdpdGggaXRzIGFjdHVh bCBkZWZpbml0aW9uICh0YXJnZXQtaXBzIGV0Yy4gbWVyZ2VkIGFzIGFwcHJvcHJpYXRlKSwgc28g YWxpYXMtbmFtZSBpcyBub3QgZm9yd2FyZGVkIG9uIHRvIFNlcnZlciDigJMganVzdCB0aGUgZXhw YW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGZvcndhcmRlZA0KDQpiKSAgICBUaGUgRE9UUyBH VyB1cGRhdGVzIHRoZSBhbGlhcy1uYW1lIHdpdGggYSB1bmlxdWUgYWxpYXMtbmFtZSB0aGF0IGlz IGZvcndhcmRlZCAoYW5kIGhhcyB0byBkbyB0aGUgc2FtZSB0aGluZyB3aGVuIHRoZSBhbGlhcy1u YW1lIGlzIGNvbmZpZ3VyZWQgb24gdGhlIGRhdGEgY2hhbm5lbCkg4oCTIHRvIGhhbmRsZSAyIG9y IG1vcmUgY2xpZW50cyBkZWZpbmluZyB0aGUgc2FtZSBhbGlhcy1uYW1lIHdoaWNoIGhhdmUgZGlm ZmVyZW50IGNoYXJhY3RlcmlzdGljcw0KDQpjKSAgICAgVGhlIERPVFMgR1cgcmVjb2duaXNlcyB0 aGF0IGFsaWFzLW5hbWUgaXMgbm90IHVuaXF1ZSBhbmQgYWRkcyBpbiDigJ1hZGRpdGlvbmFsLWNs aWVudC1pbmZv4oCdIChJIHRoaW5rIEkgcHJlZmVyIHRoaXMg4oCcLWluZm/igJ0gbmFtZSB0byBj bGllbnQtaWQgb3Igb3JpZ2luYWwtY2xpZW50LWlkIGFzIOKAnC1pZOKAnSBpcyB0b28gY2xvc2Vs eSAgYXNzb2NpYXRlZCB3aXRoIENsaWVudCBJZGVudGl0eSBkZXJpdmVkIGZyb20gdGhlIERPVFMg R1cgQ2xpZW50IGNlcnRpZmljYXRlKQ0KV2UgaGF2ZSBhZ3JlZWQgdGhhdCB3aGVuIGEgY2xpZW50 IHJlcXVlc3RzIG1pdGlnYXRpb24gc3RhdHVzLCB0aGUg4oCcYWxpYXMtbmFtZeKAnSBzaG91bGQg YmUgcmV0dXJuZWQgYXMg4oCcYWxpYXMtbmFtZeKAnSBhbmQgbm90IHRoZSBzdWJzdGl0dXRlZCBh bGlhcy1uYW1lIGNvbmZpZ3VyYXRpb24gKHRoaXMgZG9lcyBuZWVkIHRvIGJlIHN0YXRlZCBpbiB0 aGUgc3BlYyBmb3IgY2xhcml0eSkuICBUaGlzIG1ha2VzIChhKSBkaWZmaWN1bHQgdG8gYmUgaGFu ZGxlZCBieSBET1RTIEdXIHdoaWNoIHRoZW4gcmFpc2VzIHRoZSBxdWVzdGlvbiDigJMgZG8gd2Ug cmVhbGx5IG5lZWQgYWxpYXMtbmFtZT8NCg0KVGhlIGRlZmluaXRpb24gYW5kIGFzc29jaWF0aW9u IG9mIEFDTHMvRmlsdGVycyBvZiB0aGUgZGF0YSBjaGFubmVsIGlzIG1vcmUgZGlmZmljdWx0IOKA kyB0aGUgU2VydmVyIG11c3QgaW5zdGFsbCAvIGFwcGx5IHRoZSBhcHByb3ByaWF0ZSBBQ0xzIG9u IGEgcGVyIChPcmlnaW5hbCkgQ2xpZW50IGJhc2lzIHdoZW4gbWl0aWdhdGlvbiBpcyBpbnZva2Vk Lg0KQ2xpZW50IDHigJlzIGNvbmNlcHQgb2YgYSBXaGl0ZWxpc3QgSVAgY291bGQgYmUgQ2xpZW50 IDLigJlzIGNvbmNlcHQgb2YgYSBCbGFja2xpc3QgSVAuICBUaGUgU2VydmVyIG5lZWRzIHRvIGtu b3cgd2hpY2ggY2xpZW50IGlzIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRpb24gYW5kIGluc3RhbGwg dGhlIGNvcnJlY3QgQUNMcyDigJMgaWYgdGhlcmUgd2FzIG5vIOKAnWFkZGl0aW9uYWwtY2xpZW50 LWluZm/igJ0sIHRoZSBTZXJ2ZXIgb25seSBrbm93cyB0aGF0IGhlIGhhcyB0byBpbnN0YWxsIEFM TCBvZiB0aGUgQUNMcyAoaS5lLiBib3RoIHRoZSBCbGFjayBhbmQgV2hpdGUgbGlzdCBvZiB0aGUg c2FtZSBJUCBhcyBkZWZpbmVkIGJ5IENsaWVudCAxIGFuZCBDbGllbnQgMikgYXMgZGVmaW5lZCBi eSBoaXMgY2xpZW50IChET1RTIEdXKSB3aGVuIGhpcyBjbGllbnQgcmVxdWVzdHMgYSBtaXRpZ2F0 aW9uLiAgSGVyZSwgSSB0aGluayB0aGF0IGlmIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgY2xpZW50 IGZvciB0aGUgRE9UUyBHVywg4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSBpcyByZXF1aXJl ZC4NCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAwNyBPY3RvYmVyIDIwMTcgMDQ6MjgNClRvOiBK b24gU2hhbGxvdzsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+ OyBSb2xhbmQgRG9iYmlucw0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxs ZW5nZXMNCg0KSW4gY2FzZSBvZiBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksIHdoeSBkb2VzIHRo ZSBET1RTIHNlcnZlciBuZWVkIHRvIGtub3cgd2hpY2gg4oCcRE9UUyBjbGllbnTigJ0gaGFzIGNv bnZleWVkIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgPw0KRm9yIGV4YW1wbGUsIHRoZSBET1RTIGNs aWVudCBjb3VsZCBiZSBhIEREb1MgZGV0ZWN0b3Igb3IgYW4gQXBwbGljYXRpb24gc2VydmVyLCBh bmQgdGhlIGNsaWVudC1zaWRlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHJlc29sdmUgdGhlIGNvbmZs aWN0aW5nIG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBjbGllbnRzLCBhZ2dyZWdh dGUgdGhlIG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBjbGllbnQgYW5kIHNlbmQg dGhlIHVwZGF0ZWQgbWl0aWdhdGlvbiByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4NCg0KLVRp cnUNCg0KRnJvbTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29t XQ0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDYsIDIwMTcgNzo0MiBQTQ0KVG86IEtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRv OlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PjsgbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0 Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJi b3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0KU3ViamVjdDogUkU6IFtEb3RzXSBE T1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KVW5sZXNzIEkgYW0gbWlzc2lu ZyBzb21ldGhpbmcsIGhvdyBkb2VzIHRoZSBDbGllbnQgc2lkZSBvZiBET1RTIEdXIGNvbnZleSB0 byB0aGUgdXBzdHJlYW0gc2VydmVyIGEgdW5pcXVlIOKAnGNsaWVudC1pZOKAnSB3aGljaCBpcyBk aWZmZXJlbnQgdG8gdGhlIGltcGxpZWQgY2xpZW50IGlkIGFzIGRlcml2ZWQgZnJvbSB0aGUgUEtJ IGNlcnRpZmljYXRlIHRoYXQgdGhlIERPVFMgR1figJlDbGllbnQgdXNlcy9wcmVzZW50cyB3aGVu IGNvbW11bmljYXRpbmcgdG8gdGhlIHNlcnZlcj8NClRvIG1lLCB0aGVyZSBuZWVkcyB0byBiZSBh biBvcHRpb24gc3VjaCBhcyDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0gb3Ig4oCcY2xpZW50LWlk 4oCdICh3aGljaCBpcyBjb25mdXNpbmcgd2hlbiBhbHNvIHJlZmVycmluZyB0byB0aGUgY2xpZW50 IGlkZW50aXR5IGFzIGRlcml2ZWQgZnJvbSB0aGUgKERPVFMgR1cpIENsaWVudOKAmXMgUEtJIGNl cnRpZmljYXRlKSBhcyBhIHBhcnQgb2YgdGhlIHByb3RvY29sLg0KDQpJIGFncmVlIHRoYXQgdGhl IERPVFMgR1cgY2FuIGdlbmVyYXRlIGl0cyBvd24gdW5pcXVlIGNsaWVudC1pZCB0byBzdG9wIG11 bHRpcGxlIGVudHJpZXMgYmVpbmcgbmVlZGVkLg0KDQpJIGFncmVlIHRoYXQgaXMgbm90IGEgZ29v ZCB0aGluZyB0byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1hdGlvbiB3aGVuIHBhc3Np bmcgdGhyb3VnaCBhIERPVFMgR1csIHNvIG15IFJFUVVJUkVEIGRvZXMgbm90IG1ha2Ugc2Vuc2Uu DQoNClJlZ2FyZHMNCg0KSm9uDQpQUyDigJMgSSBhbSBoYXZpbmcgdG8gZGVhbCB3aXRoIG90aGVy IHN0dWZmIGF0IHByZXNlbnQg4oCTIEkgd2lsbCBnZXQgYmFjayBsYXRlciBvbiB0aGUgb3RoZXIg aXNzdWVzIHVuZGVyIGRpc2N1c3Npb24NCg0KRnJvbTogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRk eSBbbWFpbHRvOiBUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPG1haWx0bzpUaXJ1 bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPl0NClNlbnQ6IDA2IE9jdG9iZXIgMjAxNyAx NDo1OA0KVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+OyBKb24gU2hhbGxvdzsgJ0RvYmJpbnMsIFJvbGFuZCc7IGRvdHNA aWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMg R2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpJIGRvbuKAmXQgc2VlIGEgbmVlZCBmb3IgY2xpZW50LXNp ZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0g dG8gdGhlIERPVFMgc2VydmVyLiDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSBsb29rcyByZXF1 aXJlZCBvbmx5IGZvciB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5cy4gSW4gY2FzZSBvZiBz ZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IGNhbiBjb252ZXkgdGhlIGNsaWVudC1pZCBnZW5l cmF0ZWQgZnJvbSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2Vy dmVyLiBUaGUgRE9UUyBnYXRld2F5IGNhbiBnZW5lcmF0ZSBhIHVuaXF1ZSBjbGllbnQtaWQgYW5k IGRvZXMgbm90IGhhdmUgdG8gc2VuZCBhbiBhcnJheSBvZiBjbGllbnQtaWRzIHRvIHRoZSBET1RT IHNlcnZlciB0byByZXNvbHZlIGNsYXNoZXMuDQoNCi1UaXJ1DQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRG90cyBtYWlsaW5nIGxpc3QNCg0K RG90c0BpZXRmLm9yZzxtYWlsdG86RG90c0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoNCg== --_000_DM5PR16MB1788917FCAFA7B8403915594EA750DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAz O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjsNCgljb2xvcjpi bGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiU2Vnb2UgVUkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1 bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpwLlRleHRlZGVidWxs ZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJe21zby1zdHlsZS1uYW1l OiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHls ZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUzNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTM1DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzYNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5JbmxpbmUgW1RSMl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9w Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEpvbiBT aGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDEwLCAyMDE3IDg6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+IEtv bmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0O1RpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZl ZS5jb20mZ3Q7OyBrYW5hbWUgbmlzaGl6dWthICZsdDtrYW5hbWVAbnR0djYuanAmZ3Q7OyBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBkb3RzQGlldGYub3JnOyBSb2xhbmQgRG9iYmlucyAm bHQ7cmRvYmJpbnNAYXJib3IubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNd IERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGkgVGlydSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2VlIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5Kb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IERvdHMgWzxhIGhy ZWY9Im1haWx0bzppZXRmLXN1cGpwcy1kb3RzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzppZXRm LXN1cGpwcy1kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5L b25kYSwgVGlydW1hbGVzd2FyIFJlZGR5PGJyPg0KPGI+U2VudDo8L2I+IDEwIE9jdG9iZXIgMjAx NyAxNTozNDxicj4NCjxiPlRvOjwvYj4gSm9uIFNoYWxsb3c7IDxhIGhyZWY9Im1haWx0bzpkb3Rz QGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsga2FuYW1lIG5pc2hpenVrYTsgUm9sYW5kIERv YmJpbnM7DQo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtE b3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5IaSBKb24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5QbGVhc2Ugc2VlIGlubGluZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBKb24gU2hhbGxvdyBbPGEgaHJlZj0ibWFp bHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20iPm1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxs b3cuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDEwLCAyMDE3 IDY6MjggUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0Ozxh IGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj5UaXJ1bWFs ZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86ZG90 c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT47IGthbmFtZSBuaXNoaXp1a2EgJmx0OzxhIGhy ZWY9Im1haWx0bzprYW5hbWVAbnR0djYuanAiPmthbmFtZUBudHR2Ni5qcDwvYT4mZ3Q7OyBSb2xh bmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+cmRvYmJp bnNAYXJib3IubmV0PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gaGF2aW5nIHRy b3VibGUgcGFyc2luZyB0aGlzIOKAkyBpdCBpcyBkZWZpbml0aW9uIG9mIHRlcm1zIOKAkyBzZXJ2 ZXIgYW5kIGNsaWVudCB3aGVuIHJlZmVycmluZyB0byBET1RTIENsaWVudCwgRE9UUyBTZXJ2ZXIg YW5kIERPVFMgR2F0ZXdheS4mbmJzcDsgSQ0KIHRoaW5rIHRoZXJlIGlzIGEgdHlwby4mbmJzcDsg W0kgbWFueSB0aW1lcyBoYXZlIGdvdCBtdWRkbGVkIGluIG15IHRoaW5raW5nIHdoZW4gcmVmZXJy aW5nIHRvLCBzYXksIERPVFMgR1cgY2xpZW50IHNpZGUg4oCTIHdoaWNoIGFjdHVhbGx5IGlzIGEg RE9UUyBzZXJ2ZXIgaW4gaXRzIG93biByaWdodHMuXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+W1RSXSBUaGUgRE9UUyBjbGllbnQgY2VydGlmaWNhdGUgbWF5IG5vdCBmaXQgd2l0aGluIHRo ZSBwYXRoIE1UVS4gVGhlIGFsdGVybmF0aXZlIGFwcHJvYWNoIGlzLCB0aGUgc2VydmVyLXNpZGUg RE9UUyBHVyBjb21wdXRlcyBTSEEtMjU2IG9mIHRoZSBTdWJqZWN0IFB1YmxpYyBLZXkgSW5mbyAo U1BLSSkgb2YNCiB0aGUgY2xpZW50IGNlcnRpZmljYXRlIGFuZCBzZW5kIHRoZSBoYXNoZWQgb3V0 cHV0IHRvIHRoZSBET1RTIHNlcnZlciBpbiB0aGUgbmV3IGNsaWVudC1pZCBwYXJhbWV0ZXIgKHNl ZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0Njkjc2VjdGlvbi0y LjQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NDY5I3NlY3Rpb24tMi40PC9hPiku IFNIQS0yNTYgaXMgcmVzaXN0YW50IHRvIGNvbGxpc2lvbnMuIEZ1cnRoZXIsIHNlcnZlci1zaWRl IERPVFMgZ2F0ZXdheSBhbmQgRE9UUyBzZXJ2ZXIgYXJlIGluIHRoZSBzYW1lIGRvbWFpbiBvcGVy YXRpbmcgdGhlIEVTVCBzZXJ2ZXIsIERPVFMgY2xpZW50DQogd2lsbCBiZSB1c2luZyB0aGUgY2Vy dGlmaWNhdGUgcHJvdmlzaW9uZWQgYnkgdGhlIEVTVCBzZXJ2ZXIgdG8gYXV0aGVudGljYXRlIGl0 c2VsZiB0byB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGFuZCBJIGRvbuKAmXQgc2VlIGFu eSBhbWJpZ3VvdXMgaW5mb3JtYXRpb24gaW4gdGhlIGhhc2hlZCBjbGllbnQgaWRlbnRpdHkgZ2Vu ZXJhdGVkIGFuZCBjb252ZXllZCBieSB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IHRvIHRo ZSBET1RTIHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvIG1lLA0KPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5zZXJ2ZXItc2lkZSBET1RTIGdhdGV3 YXkgZGVmaW5pdGlvbiBpcyB0aGUgdXBzdHJlYW0gRE9UUyBzZXJ2ZXIgZmFjaW5nIHBhcnQgb2Yg dGhlIERPVFMgR2F0ZXdheSDigJMgYzIgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7JiM0MzstLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwgRCB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgTyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8IGMxIHwtLS0tLS0tLS0tfCBzMSB8IFQgfCBjMiB8LS0tLS0tLS0tfCBzMiB8PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tJiM0MzsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZu YnNwOyB8IFMgfCZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyB8IEcgfCZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJiM0MzstLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtYXJj aGl0ZWN0dXJlLTA0I3NlY3Rpb24tMi4yLjMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWRvdHMtYXJjaGl0ZWN0dXJlLTA0I3NlY3Rpb24tMi4yLjM8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPklzc3VlIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPj09PT09PT09PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbyBob3cgZG9lcyDigJw8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPkRPVFMgY2xpZW50IHdpbGwgYmUgdXNpbmcgdGhlIGNlcnRp ZmljYXRlIHByb3Zpc2lvbmVkIGJ5IHRoZSBFU1Qgc2VydmVyIHRvIGF1dGhlbnRpY2F0ZSBpdHNl bGYNCiB0byB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F54oCdIHdvcms/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPi0gKChjMSkgdG8gKGMyKSBpcyBpbGxlZ2FsISk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPltUUl0gYzEgYXV0aGVudGljYXRlcyB0byBzMSB1 c2luZyB0aGUgY2VydGlmaWNhdGUgaXQgcmVjZWl2ZWQgZnJvbSB0aGUgRVNUIHNlcnZlciBpbiB0 aGUgc2FtZSBkb21haW4gYXMgczEsIGMyIGFuZCBzMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0pvbl0s IFNvIHlvdXIgdGV4dCBzaG91bGQgcmVhbGx5IGhhdmUgcmVhZA0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0Ij5ET1RTIGNsaWVudCB3aWxsIGJlIHVzaW5nIHRoZSBjZXJ0aWZpY2F0 ZSBwcm92aXNpb25lZCBieSB0aGUgRVNUIHNlcnZlciB0byBhdXRoZW50aWNhdGUgaXRzZWxmIHRv IHRoZQ0KPGI+Y2xpZW50PC9iPi1zaWRlIERPVFMgZ2F0ZXdheeKAnS48L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+W1RSMl0gQWdyZWVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0Ij5Jc3N1ZSAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPj09PT09PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPuKAnHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBhbmQgRE9UUyBzZXJ2ZXIgYXJlIGlu IHRoZSBzYW1lIGRvbWFpbiBvcGVyYXRpbmcgdGhlIEVTVCBzZXJ2ZXIsIERPVFMgY2xpZW50IHdp bGwgYmUgdXNpbmcgdGhlIGNlcnRpZmljYXRlIHByb3Zpc2lvbmVkIGJ5IHRoZSBFU1Qgc2VydmVy 4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5XaGlsc3QgKGMy KSBhbmQgKHMyKSB3aWxsIGJlIGluIHRoZSBzYW1lIGRvbWFpbiBmb3IgbXV0dWFsIGF1dGhlbnRp Y2F0aW9uLCB0aGUgc2FtZSBpcyBub3QgbmVjZXNzYXJpbHkgdHJ1ZSBmb3IgKGMxKSBhbmQgKHMy KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0Ij5Ib3dldmVyIHRoZSB1c2Ugb2YgU1BLSSB3aWxsIHdvcmsgaWYg YWxsIHRoZSAoYzEpIHR5cGUgY2xpZW50cyB0YWxraW5nIHRvIChzMSkgYXJlIHVzaW5nIFBLSS4m bmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ W1RSXSBUaGUgYXNzdW1wdGlvbiBpcyBET1RTIGFnZW50cyBpbiBkaWZmZXJlbnQgZG9tYWlucyBt dXN0IHVzZSBQS0kgZm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bSm9uXSBUbyBtZSBhIERPVFMg R1cgaXMgdGhlIGJyZWFrIHBvaW50IGJldHdlZW4gMiBkaWZmZXJlbnQgZG9tYWlucy4mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj7igJxTRUMtMDAx4oCdIGluIHJlcXVpcmVtZW50cyBzcGVjIHN0 YXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDo1LjE1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsgU0VDLTAwMSZuYnNwOyBQZWVyIE11dHVhbCBBdXRoZW50aWNhdGlvbjogRE9UUyBhZ2Vu dHMgTVVTVCBhdXRoZW50aWNhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4xNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVhY2ggb3RoZXIgYmVmb3Jl IGEgRE9UUyBzaWduYWwgb3IgZGF0YSBjaGFubmVsIGlzIGNvbnNpZGVyZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4xNXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHZhbGlkLiZuYnNwOyBUaGUgbWV0aG9kIG9mIGF1dGhlbnRpY2F0aW9uIGlzIG5vdCBz cGVjaWZpZWQsIGJ1dCBzaG91bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4xNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvbGxvdyBjdXJyZW50IGlu ZHVzdHJ5IGJlc3QgcHJhY3RpY2VzIHdpdGggcmVzcGVjdCB0byBhbnk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNt cyB0byBhdXRoZW50aWNhdGUgdGhlIHJlbW90ZSBwZWVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJwz LjEuMiBFc3RhYmxpc2hpbmcgdGhlIERPVFMgU2Vzc2lvbuKAnSBpbiB0aGUgYXJjaGl0ZWN0dXJl IHNwZWMgc3RhdGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjUuMTVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkZvciBleGFtcGxlLCBhIERPVFMgY2xpZW50IG1heSBiZSBkaXJlY3RseSBjb25maWd1cmVkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjUuMTVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyB0 byB1c2UgYSBzcGVjaWZpYyBET1RTIHNlcnZlciBJUCBhZGRyZXNzIGFuZCBwb3J0LCBhbmQgZGly ZWN0bHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6NS4xNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IHByb3ZpZGVkIHdpdGggYW55IGRhdGEgbmVjZXNzYXJ5IHRvIHNhdGlzZnkgdGhlIFBl ZXIgTXV0dWFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjUuMTVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyBBdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudCBpbiBbSS1ELmlldGYtZG90cy1y ZXF1aXJlbWVudHNdLCBzdWNoIGFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMTVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBzeW1tZXRyaWMgb3IgYXN5bW1ldHJpYyBrZXlzLCB1c2Vy bmFtZXMgYW5kIHBhc3N3b3JkcywgZXRjLiZuYnNwOyBBbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4xNXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24gYW5kIGF1 dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uIGluIHRoaXMgc2NlbmFyaW8gaXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IHByb3ZpZGVkIG91dC1vZi1iYW5kIGJ5IHRoZSBkb21haW4gb3Bl cmF0aW5nIHRoZSBET1RTIHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0pvbl0gVGhpcyBkb2Vz IG5vdCBzYXkgaXQgaGFzIHRvIGJlIFBLSS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+W1RSMl0gWWVzLCB3ZSBuZWVkIHRvIGRpc2N1c3Mg aW4gdGhlIFdHIHRvIG1hbmRhdGUgUEtJIGFjcm9zcyBkb21haW5zLiBJIGFtIHBsYW5uaW5nIHRv IHB1dCBhIGRyYWZ0IHRvIGRpc2N1c3MgdGhlIHBvc3NpYmxlIG11dHVhbCBhdXRoZW50aWNhdGlv biBtZWNoYW5pc21zDQogZm9yIHRoZSBXRyB0byBkZWNpZGUgbWFuZGF0b3J5IGFuZCBvcHRpb25h bCBtZWNoYW5pc21zIHRvIGltcGxlbWVudCBmb3IgaW50ZXJvcGVyYWJpbGl0eS4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SWYgdGhlcmUgaXMgYW5vdGhl ciB0cnVzdCBtZWNoYW5pc20gZm9yIChjMSkmbHQ7LSZndDsoKHMxKSwgdGhlbiBpdCBpcyBnb2lu ZyB0byBoYXZlIHRvIGJlIGEgaGFzaCBvbiBzb21ldGhpbmcgZGlmZmVyZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3 aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+W1RSXSBZZXMsIHdlIGNhbiBw cm9wb3NlIFNQS0kgYXMgb25lIG1lY2hhbmlzbXMgKHNpbmNlIHMxLCBjMiBhbmQgczMgYXJlIGlu IHRoZSBzYW1lIGRvbWFpbiwgdGhleSBhbGwgd2lsbCBiZSBhd2FyZSBvZiB0aGUgYWx0ZXJuYXRl IHRydXN0IG1lY2hhbmlzbSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltKb25dIE5vdCBzbyBlYXN5IGlm IHRoZSBET1RTIGRvbWFpbnMgdXNlIGRpZmZlcmVudCBtdXR1YWwgYXV0aGVudGljYXRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5bVFIyXSBJIGRv buKAmXQgc2VlIGEgcHJvYmxlbSwgaWYgbGV04oCZcyBzYXkgc2hhcmVkIHNlY3JldCBpcyB1c2Vk IGZvciBtdXR1YWwgYXV0aGVudGljYXRpb24gYi93IERPVFMgYWdlbnRzIHRoZW4gU0hBLTI1NiBj YW4gYmUgY29tcHV0ZWQgZm9yIHRoZSBzaGFyZWQgc2VjcmV0LA0KIHNpbWlsYXJseSBpZiByYXcg cHVibGljIGtleXMgYXJlIHVzZWQgdGhlbiBTSEEtMjU2IGNhbiBiZSBjYWxjdWxhdGVkIGZvciB0 aGUgcmF3IHB1YmxpYyBrZXkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Kb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dCI+IERvdHMgW21haWx0bzoNCjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZg0K PC9iPktvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk8YnI+DQo8Yj5TZW50OjwvYj4gMTAgT2N0b2Jl ciAyMDE3IDEyOjUzPGJyPg0KPGI+VG86PC9iPiBrYW5hbWUgbmlzaGl6dWthOyBKb24gU2hhbGxv dzsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3Jn Ij5kb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5IaSBLYW5hbWUsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5QbGVhc2Ugc2VlIGlubGluZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBEb3RzIFs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tYWls dG86ZG90cy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5rYW5hbWUgbmlzaGl6dWthPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgODo0OSBBTTxicj4NCjxiPlRv OjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRp cnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij4mZ3Q7Ow0KIEpvbiBTaGFsbG93ICZsdDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+c3Vw anBzLWlldGZAanBzaGFsbG93LmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPiZndDs7DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjsNCjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5kb3RzQGlldGYu b3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+OyBSb2xhbmQg RG9iYmlucyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+cmRvYmJpbnNAYXJib3IubmV0PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNd IERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGksPGJyPg0KPGJy Pg0KJmd0OyBJIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJsZSBmb3Igc2Vy dmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50 aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4NCjxicj4NCkkgYWdyZWUgd2l0aCB0aGlzIHNlcnZl ci1zaWRlIERPVFMgZ2F0ZXdheSBjYXNlLjxicj4NCkF0IHRoZSBzYW1lIHRpbWUsIEkgYWdyZWUg d2l0aCBiZWxvdzo8YnI+DQomZ3Q7IEkgYWdyZWUgdGhhdCBpcyBub3QgYSBnb29kIHRoaW5nIHRv IOKAnGxlYWvigJ0gb3V0IGludGVybmFsIGluZm9ybWF0aW9uIHdoZW4gcGFzc2luZyB0aHJvdWdo IGEgRE9UUyBHVywNCjxicj4NCjxicj4NClRoZW4sIHNob3VsZCBET1RTIEdXIHNlbmQg4oCcY2xp ZW50IGlkZW50aXR54oCdIChpLmUuIGNlcnRpZmljYXRlcyBvZiBET1RTIGNsaWVudHMpIGl0c2Vs ZiBvciBoYXNoZWQo4oCcY2xpZW50IGlkZW50aXR54oCdKSB0byBET1RTIHNlcnZlcj88YnI+DQpJ ZiBsYXRlciwgaG93IGNhbiBET1RTIHNlcnZlciByZWFjdCB0byB0aGUgYW1iaWd1b3VzIGluZm9y bWF0aW9uIG9mIHRoZSBoYXNoZWQo4oCcY2xpZW50IGlkZW50aXR54oCdKS48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dCI+W1RSXSBUaGUgRE9UUyBjbGllbnQgY2VydGlmaWNhdGUgbWF5IG5vdCBmaXQgd2l0 aGluIHRoZSBwYXRoIE1UVS4gVGhlIGFsdGVybmF0aXZlIGFwcHJvYWNoIGlzLCB0aGUgc2VydmVy LXNpZGUgRE9UUyBHVyBjb21wdXRlcyBTSEEtMjU2IG9mIHRoZSBTdWJqZWN0IFB1YmxpYyBLZXkg SW5mbyAoU1BLSSkgb2YNCiB0aGUgY2xpZW50IGNlcnRpZmljYXRlIGFuZCBzZW5kIHRoZSBoYXNo ZWQgb3V0cHV0IHRvIHRoZSBET1RTIHNlcnZlciBpbiB0aGUgbmV3IGNsaWVudC1pZCBwYXJhbWV0 ZXIgKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0Njkjc2Vj dGlvbi0yLjQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NDY5I3NlY3Rpb24tMi40 PC9hPikuIFNIQS0yNTYgaXMgcmVzaXN0YW50IHRvIGNvbGxpc2lvbnMuIEZ1cnRoZXIsIHNlcnZl ci1zaWRlIERPVFMgZ2F0ZXdheSBhbmQgRE9UUyBzZXJ2ZXIgYXJlIGluIHRoZSBzYW1lIGRvbWFp biBvcGVyYXRpbmcgdGhlIEVTVCBzZXJ2ZXIsIERPVFMgY2xpZW50DQogd2lsbCBiZSB1c2luZyB0 aGUgY2VydGlmaWNhdGUgcHJvdmlzaW9uZWQgYnkgdGhlIEVTVCBzZXJ2ZXIgdG8gYXV0aGVudGlj YXRlIGl0c2VsZiB0byB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGFuZCBJIGRvbuKAmXQg c2VlIGFueSBhbWJpZ3VvdXMgaW5mb3JtYXRpb24gaW4gdGhlIGhhc2hlZCBjbGllbnQgaWRlbnRp dHkgZ2VuZXJhdGVkIGFuZCBjb252ZXllZCBieSB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5 IHRvIHRoZSBET1RTIHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0Ij4tVGlydTwvc3Bhbj48YnI+DQo8YnI+DQpyZWdhcmRzLDxicj4NCkthbmFtZTxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjAxNy8xMC8wOSAyMjozNCwgS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEpvbiw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBhZ3Jl ZSB0aGUgYmVsb3cgcHJvYmxlbXMgYXJlIGFwcGxpY2FibGUgZm9yIHNlcnZlci1zaWRlIERPVFMg Z2F0ZXdheSwgaXQgbXVzdCBjb252ZXkgdGhlIOKAnGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUg RE9UUyBzZXJ2ZXIuIEJ1dCBmb3IgdGhlIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgc2hv dWxkDQogcmVzb2x2ZSBjb25mbGljdGluZyBydWxlcyBiL3cgRE9UUyBjbGllbnRzIChlLmcuIG9u ZSBjbGllbnQgaW5zdGFsbGluZyBibGFjay1saXN0IEFDTCBmb3IgYW4gSVAgYWRkcmVzcyBidXQg dGhlIG90aGVyIGNsaWVudCBpbnN0YWxscyB3aGl0ZS1saXN0IEFDTCBmb3IgdGhlIHNhbWUgSVAg YWRkcmVzcywgc2FtZSBhbGlhcy1uYW1lcyBmb3IgZGlmZmVyZW50IG1pdGlnYXRpb24gc2NvcGVz KS4gSSBkb27igJl0IHNlZSB0aGUgbmVlZCBmb3IgYSBjbGllbnQtc2lkZQ0KIERPVFMgZ2F0ZXdh eSB0byBjb252ZXkgdGhlIOKAnGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgc2VydmVyLXNpZGUg RE9UUyBnYXRld2F5IG9yIERPVFMgc2VydmVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tVGlydTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb24gU2hhbGxv dyBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPm1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgT2N0b2JlciA3 LCAyMDE3IDI6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkg PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29t Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDtUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29t Jmd0Ozwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj47DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj47DQo8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ZG90c0BpZXRm Lm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj47IFJvbGFuZCBEb2JiaW5zDQo8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbHQ7 cmRvYmJpbnNAYXJib3IubmV0Jmd0Ozwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgZGlz Y3Vzc2lvbiBnb2VzIGJleW9uZCBqdXN0IHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QuJm5ic3A7IFdl IG5lZWQgdG8gY29uc2lkZXIgd2hhdCBoYXBwZW5zIHdpdGggYm90aCBhbGlhcy1uYW1lIGFuZCBh Y2wtbmFtZSAoZGF0YSBjaGFubmVsKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgc2ltcGxlIGNhc2Ugb2YgYSBt aXRpZ2F0aW9uIHJlcXVlc3Qgd2l0aCBubyBhbGlhcy1uYW1lIGRvZXMgbm90IHJlcXVpcmUgYW55 IGtub3dsZWRnZSBvZiB0aGUgb3JpZ2luYWwgY2xpZW50LiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhv d2V2ZXIsIGlmIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgdXNlcyBhbGlhcy1uYW1lLCB0aGVuIHRo ZXJlIGFyZSAzIHdheXMgb2YgaGFuZGxpbmcgdGhpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj5hKTxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIERPVFMg R1cgcmVwbGFjZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBpdHMgYWN0dWFsIGRlZmluaXRpb24gKHRh cmdldC1pcHMgZXRjLiBtZXJnZWQgYXMgYXBwcm9wcmlhdGUpLCBzbyBhbGlhcy1uYW1lIGlzIG5v dCBmb3J3YXJkZWQgb24gdG8gU2VydmVyIOKAkyBqdXN0IHRoZQ0KIGV4cGFuZGVkIG1pdGlnYXRp b24gcmVxdWVzdCBpcyBmb3J3YXJkZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+Yik8c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RTIEdXIHVwZGF0ZXMgdGhl IGFsaWFzLW5hbWUgd2l0aCBhIHVuaXF1ZSBhbGlhcy1uYW1lIHRoYXQgaXMgZm9yd2FyZGVkIChh bmQgaGFzIHRvIGRvIHRoZSBzYW1lIHRoaW5nIHdoZW4gdGhlIGFsaWFzLW5hbWUgaXMgY29uZmln dXJlZCBvbiB0aGUgZGF0YSBjaGFubmVsKQ0KIOKAkyB0byBoYW5kbGUgMiBvciBtb3JlIGNsaWVu dHMgZGVmaW5pbmcgdGhlIHNhbWUgYWxpYXMtbmFtZSB3aGljaCBoYXZlIGRpZmZlcmVudCBjaGFy YWN0ZXJpc3RpY3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+Yyk8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RTIEdXIHJlY29nbmlzZXMgdGhhdCBh bGlhcy1uYW1lIGlzIG5vdCB1bmlxdWUgYW5kIGFkZHMgaW4g4oCdYWRkaXRpb25hbC1jbGllbnQt aW5mb+KAnSAoSSB0aGluayBJIHByZWZlciB0aGlzIOKAnC1pbmZv4oCdIG5hbWUgdG8gY2xpZW50 LWlkIG9yIG9yaWdpbmFsLWNsaWVudC1pZA0KIGFzIOKAnC1pZOKAnSBpcyB0b28gY2xvc2VseSAm bmJzcDthc3NvY2lhdGVkIHdpdGggQ2xpZW50IElkZW50aXR5IGRlcml2ZWQgZnJvbSB0aGUgRE9U UyBHVyBDbGllbnQgY2VydGlmaWNhdGUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5X ZSBoYXZlIGFncmVlZCB0aGF0IHdoZW4gYSBjbGllbnQgcmVxdWVzdHMgbWl0aWdhdGlvbiBzdGF0 dXMsIHRoZSDigJxhbGlhcy1uYW1l4oCdIHNob3VsZCBiZSByZXR1cm5lZCBhcyDigJxhbGlhcy1u YW1l4oCdIGFuZCBub3QgdGhlIHN1YnN0aXR1dGVkIGFsaWFzLW5hbWUNCiBjb25maWd1cmF0aW9u ICh0aGlzIGRvZXMgbmVlZCB0byBiZSBzdGF0ZWQgaW4gdGhlIHNwZWMgZm9yIGNsYXJpdHkpLiZu YnNwOyBUaGlzIG1ha2VzIChhKSBkaWZmaWN1bHQgdG8gYmUgaGFuZGxlZCBieSBET1RTIEdXIHdo aWNoIHRoZW4gcmFpc2VzIHRoZSBxdWVzdGlvbiDigJMgZG8gd2UgcmVhbGx5IG5lZWQgYWxpYXMt bmFtZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+VGhlIGRlZmluaXRpb24gYW5kIGFzc29jaWF0aW9uIG9mIEFDTHMv RmlsdGVycyBvZiB0aGUgZGF0YSBjaGFubmVsIGlzIG1vcmUgZGlmZmljdWx0IOKAkyB0aGUgU2Vy dmVyIG11c3QgaW5zdGFsbCAvIGFwcGx5IHRoZSBhcHByb3ByaWF0ZSBBQ0xzIG9uIGENCiBwZXIg KE9yaWdpbmFsKSBDbGllbnQgYmFzaXMgd2hlbiBtaXRpZ2F0aW9uIGlzIGludm9rZWQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DbGllbnQgMeKAmXMgY29uY2VwdCBvZiBhIFdoaXRl bGlzdCBJUCBjb3VsZCBiZSBDbGllbnQgMuKAmXMgY29uY2VwdCBvZiBhIEJsYWNrbGlzdCBJUC4m bmJzcDsgVGhlIFNlcnZlciBuZWVkcyB0byBrbm93IHdoaWNoIGNsaWVudCBpcyByZXF1ZXN0aW5n IHRoZSBtaXRpZ2F0aW9uDQogYW5kIGluc3RhbGwgdGhlIGNvcnJlY3QgQUNMcyDigJMgaWYgdGhl cmUgd2FzIG5vIOKAnWFkZGl0aW9uYWwtY2xpZW50LWluZm/igJ0sIHRoZSBTZXJ2ZXIgb25seSBr bm93cyB0aGF0IGhlIGhhcyB0byBpbnN0YWxsIEFMTCBvZiB0aGUgQUNMcyAoaS5lLiBib3RoIHRo ZSBCbGFjayBhbmQgV2hpdGUgbGlzdCBvZiB0aGUgc2FtZSBJUCBhcyBkZWZpbmVkIGJ5IENsaWVu dCAxIGFuZCBDbGllbnQgMikgYXMgZGVmaW5lZCBieSBoaXMgY2xpZW50IChET1RTIEdXKQ0KIHdo ZW4gaGlzIGNsaWVudCByZXF1ZXN0cyBhIG1pdGlnYXRpb24uJm5ic3A7IEhlcmUsIEkgdGhpbmsg dGhhdCBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGNsaWVudCBmb3IgdGhlIERPVFMgR1csIOKA nWFkZGl0aW9uYWwtY2xpZW50LWluZm/igJ0gaXMgcmVxdWlyZWQuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Sm9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZiI+IERvdHMgW21haWx0bzoNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG90 cy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+ZG90cy1ib3VuY2VzQGlldGYub3Jn PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Lb25kYSwg VGlydW1hbGVzd2FyIFJlZGR5PGJyPg0KPGI+U2VudDo8L2I+IDA3IE9jdG9iZXIgMjAxNyAwNDoy ODxicj4NCjxiPlRvOjwvYj4gSm9uIFNoYWxsb3c7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj47DQo8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5kb3RzQGlldGYub3JnPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+OyBSb2xhbmQgRG9iYmluczxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JbiBjYXNlIG9mIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgd2h5 IGRvZXMgdGhlIERPVFMgc2VydmVyIG5lZWQgdG8ga25vdyB3aGljaCDigJxET1RTIGNsaWVudOKA nSBoYXMgY29udmV5ZWQgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCA/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgZXhhbXBsZSwg dGhlIERPVFMgY2xpZW50IGNvdWxkIGJlIGEgRERvUyBkZXRlY3RvciBvciBhbiBBcHBsaWNhdGlv biBzZXJ2ZXIsIGFuZCB0aGUgY2xpZW50LXNpZGUgZ2F0ZXdheSB3aWxsIGhhdmUgdG8gcmVzb2x2 ZSB0aGUgY29uZmxpY3RpbmcgbWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIHRoZQ0KIERPVFMgY2xp ZW50cywgYWdncmVnYXRlIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xp ZW50IGFuZCBzZW5kIHRoZSB1cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUgRE9UUyBz ZXJ2ZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi1UaXJ1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEpvbiBTaGFsbG93IFs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bWFpbHRvOnN1 cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciA2LCAyMDE3IDc6NDIgUE08YnI+DQo8Yj5U bzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U aXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDs7DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj47DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ZG90c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj47IFJvbGFuZCBEb2JiaW5zICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJkb2Ji aW5zQGFyYm9yLm5ldCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5yZG9iYmluc0BhcmJvci5uZXQ8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNd IERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGkgVGlydSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VW5sZXNzIEkgYW0gbWlzc2luZyBzb21ldGhpbmcsIGhv dyBkb2VzIHRoZSBDbGllbnQgc2lkZSBvZiBET1RTIEdXIGNvbnZleSB0byB0aGUgdXBzdHJlYW0g c2VydmVyIGEgdW5pcXVlIOKAnGNsaWVudC1pZOKAnSB3aGljaCBpcyBkaWZmZXJlbnQgdG8gdGhl IGltcGxpZWQNCiBjbGllbnQgaWQgYXMgZGVyaXZlZCBmcm9tIHRoZSBQS0kgY2VydGlmaWNhdGUg dGhhdCB0aGUgRE9UUyBHV+KAmUNsaWVudCB1c2VzL3ByZXNlbnRzIHdoZW4gY29tbXVuaWNhdGlu ZyB0byB0aGUgc2VydmVyPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG8gbWUsIHRo ZXJlIG5lZWRzIHRvIGJlIGFuIG9wdGlvbiBzdWNoIGFzIOKAnG9yaWdpbmFsLWNsaWVudC1pZOKA nSBvciDigJxjbGllbnQtaWTigJ0gKHdoaWNoIGlzIGNvbmZ1c2luZyB3aGVuIGFsc28gcmVmZXJy aW5nIHRvIHRoZSBjbGllbnQgaWRlbnRpdHkgYXMNCiBkZXJpdmVkIGZyb20gdGhlIChET1RTIEdX KSBDbGllbnTigJlzIFBLSSBjZXJ0aWZpY2F0ZSkgYXMgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IHRoZSBET1RTIEdXIGNhbiBnZW5lcmF0ZSBpdHMgb3du IHVuaXF1ZSBjbGllbnQtaWQgdG8gc3RvcCBtdWx0aXBsZSBlbnRyaWVzIGJlaW5nIG5lZWRlZC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KA nSBvdXQgaW50ZXJuYWwgaW5mb3JtYXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdX LCBzbyBteSBSRVFVSVJFRCBkb2VzIG5vdCBtYWtlIHNlbnNlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkpvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UFMg4oCTIEkg YW0gaGF2aW5nIHRvIGRlYWwgd2l0aCBvdGhlciBzdHVmZiBhdCBwcmVzZW50IOKAkyBJIHdpbGwg Z2V0IGJhY2sgbGF0ZXIgb24gdGhlIG90aGVyIGlzc3VlcyB1bmRlciBkaXNjdXNzaW9uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IEtvbmRhLCBU aXJ1bWFsZXN3YXIgUmVkZHkgW21haWx0bzoNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86VGlydW1h bGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPlRpcnVtYWxlc3dh clJlZGR5X0tvbmRhQG1jYWZlZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gMDYgT2N0b2JlciAyMDE3IDE0OjU4PGJyPg0KPGI+VG86PC9iPiA8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZiI+OyBKb24gU2hhbGxvdzsgJ0RvYmJpbnMsIFJvbGFuZCc7DQo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOmRvdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5kb3RzQGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9U UyBHYXRld2F5cyBDaGFsbGVuZ2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkg ZG9u4oCZdCBzZWUgYSBuZWVkIGZvciBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgdG8gY29udmV5 IHRoZSDigJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIOKAnERP VFMgY2xpZW50IGlkZW50aXR54oCdIGxvb2tzIHJlcXVpcmVkIG9ubHkgZm9yIHRoZSBzZXJ2ZXIt c2lkZSBET1RTDQogZ2F0ZXdheXMuIEluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5 LCBpdCBjYW4gY29udmV5IHRoZSBjbGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMg Y2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBj YW4gZ2VuZXJhdGUgYSB1bmlxdWUgY2xpZW50LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQg YW4gYXJyYXkgb2YgY2xpZW50LWlkcyB0byB0aGUgRE9UUyBzZXJ2ZXIgdG8NCiByZXNvbHZlIGNs YXNoZXMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LVRpcnU8L3NwYW4+PHNwYW4gbGFuZz0i RlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkZSIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+RG90cyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPjxzcGFuIGxh bmc9IkZSIj5Eb3RzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJGUiI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG90cyI+PHNwYW4gbGFuZz0iRlIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG90czwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB1788917FCAFA7B8403915594EA750DM5PR16MB1788namp_-- From nobody Tue Oct 10 08:25:14 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DDA134E30 for ; Tue, 10 Oct 2017 08:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y80rzD86vDZ for ; Tue, 10 Oct 2017 08:25:07 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 353E713510C for ; Tue, 10 Oct 2017 08:16:59 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e1wH8-0003LN-EZ; Tue, 10 Oct 2017 16:16:54 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "kaname nishizuka" , , , "Roland Dobbins" References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> <0df701d341d5 $cfd88770$6f89 9650$@jpshallow.com> In-Reply-To: Date: Tue, 10 Oct 2017 16:16:56 +0100 Message-ID: <0e3501d341da$cf9e4b50$6edae1f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E36_01D341E3.31676E40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIAJQ6kjUASRe9X8Bri7ZGgMYlBpaAoe6cxMBVc+iCQKRB52aAQ1mQBsCgZLhxwLPqneOAaZ2QR+iIp30sA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 15:25:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E36_01D341E3.31676E40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 Then that breaks a signal GET for mitigation status from (c1) = (mitigation request uses alias-name) =E2=80=93 what gets sent back in = the alias-name field when the response that is sent by (s3) when it gets = to (c1)? =20 I thought we had agreed to leave the alias name =E2=80=93 as is = =E2=80=93 (not substituted) in what is sent back to (c1) from (s1). =20 (c1) is not particularly interested in how (c11) is getting mitigated = and probably does not want (c11) stats added into his =E2=80=93 (s3) = need to know how to differentiate between (c1) and (c11) =E2=80=93 which = is easily done if (c1) (or (c11) information is passed up to (s3), = starting with (s1). =20 This whole thing needs to be scalable, and I am struggling with how to = actually implement your proposal. Allowing each DOTS GW to learn and = pass on something extra that differentiates the DOTS GW immediate = clients makes the implementation relatively easy. There is no need for = a DOTS GW to add in additional information if extra information is = already embedded =E2=80=93 unless he sees a name clash from 2 or more of = his uniquely identified DOTS clients =E2=80=93 which will be different = entities anyway. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 15:52 To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 The conflicting alias-names from DOTS client (c1) and another client = (let=E2=80=99 call (c11)) behind (s1) should be resolved by s1 itself, = it is also the responsibility of (s1) to resolve conflicting mitigation = requests from (c1) and (c11), aggregate the mitigation requests from the = DOTS clients (c1 and c11) and send the updated mitigation request (c2). =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 8:11 PM To: Konda, Tirumaleswar Reddy ; = kaname nishizuka ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 I agree in part, but we need to look at the end (c1) to end (s3) = potential issues. What you are proposing works fine for (s2) to (s3). =20 (c1) requests mitigation with an alias-name =E2=80=9Calias-1=E2=80=9D. = If (s1) does not pass anything extra to (c2) for onward transmission, = (s2) sees a single client (c2) requesting mitigation with alias-name = =E2=80=9Calias-1=E2=80=9D. Fine, that works. If there was another DOTS client in the same location as (c1)(i.e. = c1diff), both using (s1) who also decided to use alias-name = =E2=80=9Calias-1=E2=80=9D who then requests mitigation, (s2) has no idea = that there are different =E2=80=9Calias-1=E2=80=9D definitions if (c2) = does not send also an extra differentiator.=20 =20 So, any DOTS GW in the chain should be passing on a = =E2=80=9Cunique-extra=E2=80=9D piece of information. =20 Regards =20 Jon=20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 15:15 To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Agree with your response, consider a deployment which has the following = DOTS agents. =20 DOTS clients (c1) =C3=9F----------------=C3=A0 (s1) client-side DOTS = gateway (c2) =C3=9F------------=C3=A0 (s2) server-side DOTS gateway (c3) = =C3=9F----------=C3=A0 (s3) DOTS server =20 My point is, (c2) need not convey the =E2=80=9Cc1 identity=E2=80=9D to = (s2) but (s2) needs to convey the =E2=80=9Cc2 identity=E2=80=9D to (c3) = and (c3) in-turn propagates the =E2=80=9Cc2 identity=E2=80=9D to (s3). =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 6:15 PM To: Konda, Tirumaleswar Reddy ; = kaname nishizuka ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Agreed that only a DOTS GW server facing needs to send information to = the upstream DOTS Server =E2=80=93 which could also be a DOTS GW. +-------------+ | | D | | +----+ | | O | | +----+ | c1 |----------| s1 | T | c2 |---------| s2 | +----+ | | S | | +----+ | | G | | +-------------+ https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-2.2.3= =20 However, the DOTS GW client facing (s1) is the one with knowledge of the = individual clients that are currently using the DOTS server running on = the DOTS GW. This information has to somehow be passed over to the DOTS = GW server facing (c2), but separate DOTS stacks are being run for (s1) = and (c2) as per architecture spec 2.2.3. I was referring to what (s1) = may need to pass on to (c2) in my email response to Kaname, not what is = sent by (c1). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 13:16 To: Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 I thought we agreed that based on the current DOTS requirements only the = server-side DOTS GW needs to convey the DOTS client (or client-side DOTS = WG) identity to the DOTS server.=20 =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 2:53 PM To: 'kaname nishizuka' ; Konda, Tirumaleswar Reddy = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Kaname, =20 I do not think that information necessarily needs to be the original = client identity. The GW Client side will have its own identity which = the DOTS Server can use to differentiate between DOTS (GW) Clients. =20 So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash collisions. Or = it could be a simple list such as C1, C2 =E2=80=A6Cn. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 10 October 2017 04:19 To: Konda, Tirumaleswar Reddy; Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi, > I agree the below problems are applicable for server-side DOTS = gateway, it must convey the =E2=80=9Cclient identity=E2=80=9D to the = DOTS server.=20 I agree with this server-side DOTS gateway case. At the same time, I agree with below: > I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW,=20 Then, should DOTS GW send =E2=80=9Cclient identity=E2=80=9D (i.e. = certificates of DOTS clients) itself or hashed(=E2=80=9Cclient = identity=E2=80=9D) to DOTS server? If later, how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient identity=E2=80=9D). regards, Kaname On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote: Hi Jon, =20 I agree the below problems are applicable for server-side DOTS gateway, = it must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. = But for the client-side DOTS gateway, it should resolve conflicting = rules b/w DOTS clients (e.g. one client installing black-list ACL for an = IP address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:07 PM To: Konda, Tirumaleswar Reddy = = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds = in =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0E36_01D341E3.31676E40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Then that breaks a signal GET for mitigation status from (c1) = (mitigation request uses alias-name) =E2=80=93 what gets sent back in = the alias-name field when the response that is sent by (s3) when it gets = to (c1)?

 

I thought we had agreed to leave the alias name =E2=80=93 as is = =E2=80=93 (not substituted) in what is sent back to (c1) from = (s1).

 

(c1) is not particularly interested in how (c11) is getting mitigated = and probably does not want (c11) stats added into his =E2=80=93 (s3) = need to know how to differentiate between (c1) and (c11) =E2=80=93 which = is easily done if (c1) (or (c11) information is passed up to (s3), = starting with (s1).

 

This whole thing needs to be scalable, and I am struggling with how = to actually implement your proposal.=C2=A0 Allowing each DOTS GW to = learn and pass on something extra that differentiates the DOTS GW = immediate clients makes the implementation relatively easy.=C2=A0 There = is no need for a DOTS GW to add in additional information if extra = information is already embedded =E2=80=93 unless he sees a name clash = from 2 or more of his uniquely identified DOTS clients =E2=80=93 which = will be different entities anyway.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy
Sent: 10 October 2017 15:52
To: = Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS = Gateways Challenges

 

The conflicting alias-names from DOTS client (c1) and another = client (let=E2=80=99 call (c11)) behind (s1) should be resolved by s1 = itself, it is also the responsibility of (s1) to resolve conflicting = mitigation requests from (c1) and (c11), aggregate = the mitigation requests from the DOTS clients (c1 and c11) and send the = updated mitigation request (c2).

 =

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 8:11 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

I agree in part, but we need to look at the end (c1) to end (s3) = potential issues.  What you are proposing works fine for (s2) to = (s3).

 

(c1) requests mitigation with an alias-name = =E2=80=9Calias-1=E2=80=9D.  If (s1) does not pass anything extra to = (c2) for onward transmission, (s2) sees a single client (c2) requesting = mitigation with alias-name =E2=80=9Calias-1=E2=80=9D.  Fine, that = works.

If there was another DOTS client in the same location as (c1)(i.e. = c1diff), both using (s1) who also decided to use alias-name = =E2=80=9Calias-1=E2=80=9D who then requests mitigation, (s2) has no idea = that there are different =E2=80=9Calias-1=E2=80=9D definitions if (c2) = does not send also an extra differentiator.

 

So, any DOTS GW in the chain should be passing on a = =E2=80=9Cunique-extra=E2=80=9D piece of = information.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 15:15
To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Agree with your response, consider a deployment which has the = following DOTS agents.

 

DOTS clients (c1) =C3=9F<= /span>----------------=C3=A0<= /span> (s1) client-side DOTS gateway (c2) =C3=9F<= /span>------------=C3=A0<= /span> (s2) server-side DOTS gateway (c3) =C3=9F<= /span>----------=C3=A0<= /span> (s3) DOTS server

 

My point is, (c2) need not convey the =E2=80=9Cc1 = identity=E2=80=9D to (s2) but (s2) needs to convey the =E2=80=9Cc2 = identity=E2=80=9D to (c3) and (c3) in-turn propagates the =E2=80=9Cc2 = identity=E2=80=9D to (s3).

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 6:15 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Agreed that only a DOTS GW server facing needs to send information to = the upstream DOTS Server =E2=80=93 which could also be a DOTS = GW.

  =             &= nbsp;          +-------= ------+

          = ;            =    |    | D |    = |

         = +----+          = |    | O |    = |         = +----+

         | c1 = |----------| s1 | T | c2 |---------| s2 |

         = +----+     =      |    | S = |    |         = +----+

          = ;            =    |    | G |    = |

          = ;            =    +-------------+

https://tools.ietf.org/html/draft-ietf-dots-architecture-04#sec= tion-2.2.3

 

However, the DOTS GW client facing (s1) is the one with knowledge of = the individual clients that are currently using  the DOTS server = running on the DOTS GW.  This information has to somehow be passed = over to the DOTS GW server facing (c2), but separate DOTS stacks are = being run for (s1) and (c2) as per architecture spec 2.2.3.  I was = referring to what (s1) may need to pass on to (c2) in my email response = to Kaname, not what is sent by (c1).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 13:16
To: Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

I thought we agreed that based on the current DOTS requirements = only the server-side DOTS GW needs to convey the DOTS client (or = client-side DOTS WG) identity to the DOTS server. =

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 2:53 PM
To: = 'kaname nishizuka' <kaname@nttv6.jp>; Konda, = Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Kaname,

 

I do not think that information necessarily needs to be the original = client identity.  The GW Client side will have its own identity = which the DOTS Server can use to differentiate between DOTS (GW) = Clients.

 

So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash = collisions.  Or it could be a simple list such as C1, C2 = =E2=80=A6Cn.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of kaname nishizuka
Sent: 10 October 2017 = 04:19
To: Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi,

> I agree the below = problems are applicable for server-side DOTS gateway, it must convey the = =E2=80=9Cclient identity=E2=80=9D to the DOTS server.
I agree with = this server-side DOTS gateway case.
At the same time, I agree with = below:
> I agree that is not a good thing to = =E2=80=9Cleak=E2=80=9D out internal information when passing through a = DOTS GW,

Then, should DOTS GW send =E2=80=9Cclient = identity=E2=80=9D (i.e. certificates of DOTS clients) itself or = hashed(=E2=80=9Cclient identity=E2=80=9D) to DOTS server?
If later, = how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient = identity=E2=80=9D).

regards,
Kaname

On 2017/10/09 22:34, Konda, Tirumaleswar Reddy = wrote:

Hi = Jon,

 

I agree = the below problems are applicable for server-side DOTS gateway, it must = convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. But for = the client-side DOTS gateway, it should resolve conflicting rules b/w = DOTS clients (e.g. one client installing black-list ACL for an IP = address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, October 7, 2017 2:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_= Konda@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
S= ubject: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client.  =

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)     &nb= sp; The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)      = The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)     &nb= sp; The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely  associated with Client = Identity derived from the DOTS GW Client = certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).  This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.  The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.  Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= = Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:28
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, October 6, 2017 7:42 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= = Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 06 October 2017 14:58
To: = mohamed.boucadair@orange.com= ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: = [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 

-Tiru

 

________________=
_______________________________
Dots mailing =
list
Dots@ietf.org
https://www.ietf.org/=
mailman/listinfo/dots

 

------=_NextPart_000_0E36_01D341E3.31676E40-- From nobody Tue Oct 10 09:15:39 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88059132930 for ; Tue, 10 Oct 2017 09:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=mcafee.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 bLKcFTFuj_In for ; Tue, 10 Oct 2017 09:15:32 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 011CD134531 for ; Tue, 10 Oct 2017 08:59:36 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507651176; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=G FfZXqqFQGOGG3JUmzHqHy+A7AMxvUoMtNpDjWWLSP I=; b=drXYMZ3g85u5uaqEDj2JJ0vahyYbRTB0fQfMZQUVoDrq X0Ah5AMbuSCRGdrlaHZHjTeQB3pFqV93WguyeZs3u8Xa/RSdIL 7Zcu3FWGaTHyqBQDs06jAvoQ487slpmW9VkPh5/veDPbxsFPjI YOVlJWo3KnoWGvE7R5R45KQoQ9Y= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c29_ec37_a6406104_e5d1_4847_b5a3_25a68a66b2b3; Tue, 10 Oct 2017 10:59:35 -0500 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 09:58:39 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 09:58:38 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Oct 2017 09:58:38 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Oct 2017 09:58:36 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 10 Oct 2017 15:58:35 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 15:58:35 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , kaname nishizuka , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAACzkMAABuu0fgAB0EBwAADL1rgAAF4fWwAAEncgAAAJP24AADfJaAAAAklGAAARtaAAAA3fKA Date: Tue, 10 Oct 2017 15:58:35 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> <0df701d341d5$cfd88770$6f89 9650$@jpshallow.com> <0e3501d341da$cf9e4b50$6edae1f0$@jpshallow.com> In-Reply-To: <0e3501d341da$cf9e4b50$6edae1f0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.172.17.191] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:WbBlrZgn7w78Wb5de+NFSpfwLCPi6HEkKHMczCrbE18J7DBE9zMRQtKGvEzYGWPBwBHf0lTPy5goh6j7JK19rgjzYoR4lw5q5d0jIHdvwqLaKpn7ToF0ilU1ZkNnHIs+4W+GFaRGpMMc0rYcYtt4UEZJfL7koK0Hg3Ps/YwVhpwkz4kYtj0Fp/0927UpY6YDmgVZoYprhoFt5J7qSTeO9inqVDlTdYTiakitIl+iufMc/WlOwA2r8odF41uszFdz/qklA7ABCIN14e9LHPPUCyr/wpq4ziHDQqGmVE9Z6H3fsh12AkjKeC8INa/PP6433qLkMrrcad0yWpMOjqdRiQ==; 5:hIAYC8/qWgpxryWNqpzZ+zUXmKajlUEkz5LOoTUOtbUgbxwLDvQ9+8QQwhb2f54Ob6GRBA0jFA0Zt5mAIZTb7VdwIWPhmkSmulzaOFoIQ1j6ETcbY2USF8IVFnETFHBZ+sgoQPzj9O9aFfw7uMZOFQ==; 24:2qZEITPZ6uzNYQBRMfBg0Eb3e4J5eSCpg2B7ypSOcdFIxeGlIwbDsL3UieaveC9dbYuoc+tuyt5ecCjwmv7LTdcKt3CxXSnT3EjPc997Xn8=; 7:PRN9spQJX21rjrZ7SMaN0M2/qbn5hrlVbH7c8ouuP2t98D8RSav+2qEvI7IPpxnFe7R9QJuwG+jjOMgWqey748VljIFzRqAYYKkR3oZLNauWYA4p2Pljx5jmcLGv8pOsEYJJVK1/UIeUSOkFG+7UkaUfKoi0IKJ/ggGitr3IZby18FT6hrWg6d4wes9k/LYPOhIuW50fByQvFnLna8//OY6P0AeOm16xSb0h0HbCoxo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 84ddd4bb-b3d9-47ba-7f71-08d50ff7c3a3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(377454003)(32952001)(199003)(24454002)(51444003)(189002)(53546010)(2900100001)(106356001)(105586002)(77096006)(478600001)(6436002)(14454004)(189998001)(25786009)(76176999)(54356999)(50986999)(6506006)(81156014)(966005)(72206003)(606006)(561944003)(101416001)(81166006)(8676002)(8936002)(3846002)(790700001)(6116002)(102836003)(33656002)(7696004)(66066001)(7736002)(74316002)(229853002)(316002)(2950100002)(54896002)(6306002)(236005)(9686003)(2201001)(9326002)(93886005)(53936002)(5660300001)(86362001)(97736004)(99286003)(55016002)(80792005)(53946003)(68736007)(2501003)(3660700001)(2906002)(3280700002)(110136005)(6246003)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788CBCF3F6ADCED2D28FEBFEA750DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 15:58:35.5466 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6119> : streams <1766665> : uri <2514332> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 16:15:36 -0000 --_000_DM5PR16MB1788CBCF3F6ADCED2D28FEBFEA750DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uLA0KDQpUaGUgcm9sZSBvZiBzMSBpcyBtdWNoIG1vcmUgdGhhbiBqdXN0IGZvcndhcmRp bmcgdGhlIERPVFMgY2xpZW50IG1lc3NhZ2VzLCBwbGVhc2Ugc2VlIChTSUctMDA5IGluIHRoZSBy ZXF1aXJlbWVudHMgZHJhZnRzKSwgaWYgYSBET1RTIGNsaWVudCBoYXMgdXNlZCB0aGUgc2FtZSBh bGlhcyBuYW1lIHByZXZpb3VzbHkgY29udmV5ZWQgYnkgYW5vdGhlciBjbGllbnQgdGhlbiBzMSBt dXN0IHJlamVjdCB0aGUgcmVxdWVzdC4gSWYgY29uZmxpY3RpbmcgcmVxdWVzdHMgYXJlIHJlc29s dmVkIGJ5IHMxIHRoZW4gYW55IHJlc3BvbnNlIG1lc3NhZ2Ugc2VudCBieSBzMyB3aWxsIGJlIGZv cndhcmRlZCBieSBzMSB0byB0aGUgcmlnaHQgRE9UUyBjbGllbnQuDQoNCi1UaXJ1DQoNCkZyb206 IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NClNlbnQ6IFR1 ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgODo0NyBQTQ0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyBrYW5hbWUgbmlzaGl6 dWthIDxrYW5hbWVAbnR0djYuanA+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBkb3Rz QGlldGYub3JnOyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0Pg0KU3ViamVjdDog UkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KVGhlbiB0 aGF0IGJyZWFrcyBhIHNpZ25hbCBHRVQgZm9yIG1pdGlnYXRpb24gc3RhdHVzIGZyb20gKGMxKSAo bWl0aWdhdGlvbiByZXF1ZXN0IHVzZXMgYWxpYXMtbmFtZSkg4oCTIHdoYXQgZ2V0cyBzZW50IGJh Y2sgaW4gdGhlIGFsaWFzLW5hbWUgZmllbGQgd2hlbiB0aGUgcmVzcG9uc2UgdGhhdCBpcyBzZW50 IGJ5IChzMykgd2hlbiBpdCBnZXRzIHRvIChjMSk/DQoNCkkgdGhvdWdodCB3ZSBoYWQgYWdyZWVk IHRvIGxlYXZlIHRoZSBhbGlhcyBuYW1lIOKAkyBhcyBpcyDigJMgKG5vdCBzdWJzdGl0dXRlZCkg aW4gd2hhdCBpcyBzZW50IGJhY2sgdG8gKGMxKSBmcm9tIChzMSkuDQoNCihjMSkgaXMgbm90IHBh cnRpY3VsYXJseSBpbnRlcmVzdGVkIGluIGhvdyAoYzExKSBpcyBnZXR0aW5nIG1pdGlnYXRlZCBh bmQgcHJvYmFibHkgZG9lcyBub3Qgd2FudCAoYzExKSBzdGF0cyBhZGRlZCBpbnRvIGhpcyDigJMg KHMzKSBuZWVkIHRvIGtub3cgaG93IHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiAoYzEpIGFuZCAo YzExKSDigJMgd2hpY2ggaXMgZWFzaWx5IGRvbmUgaWYgKGMxKSAob3IgKGMxMSkgaW5mb3JtYXRp b24gaXMgcGFzc2VkIHVwIHRvIChzMyksIHN0YXJ0aW5nIHdpdGggKHMxKS4NCg0KVGhpcyB3aG9s ZSB0aGluZyBuZWVkcyB0byBiZSBzY2FsYWJsZSwgYW5kIEkgYW0gc3RydWdnbGluZyB3aXRoIGhv dyB0byBhY3R1YWxseSBpbXBsZW1lbnQgeW91ciBwcm9wb3NhbC4gIEFsbG93aW5nIGVhY2ggRE9U UyBHVyB0byBsZWFybiBhbmQgcGFzcyBvbiBzb21ldGhpbmcgZXh0cmEgdGhhdCBkaWZmZXJlbnRp YXRlcyB0aGUgRE9UUyBHVyBpbW1lZGlhdGUgY2xpZW50cyBtYWtlcyB0aGUgaW1wbGVtZW50YXRp b24gcmVsYXRpdmVseSBlYXN5LiAgVGhlcmUgaXMgbm8gbmVlZCBmb3IgYSBET1RTIEdXIHRvIGFk ZCBpbiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGlmIGV4dHJhIGluZm9ybWF0aW9uIGlzIGFscmVh ZHkgZW1iZWRkZWQg4oCTIHVubGVzcyBoZSBzZWVzIGEgbmFtZSBjbGFzaCBmcm9tIDIgb3IgbW9y ZSBvZiBoaXMgdW5pcXVlbHkgaWRlbnRpZmllZCBET1RTIGNsaWVudHMg4oCTIHdoaWNoIHdpbGwg YmUgZGlmZmVyZW50IGVudGl0aWVzIGFueXdheS4NCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTog RG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0Bp ZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAx MCBPY3RvYmVyIDIwMTcgMTU6NTINClRvOiBKb24gU2hhbGxvdzsga2FuYW1lIG5pc2hpenVrYTsg bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9i Ymlucw0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KVGhl IGNvbmZsaWN0aW5nIGFsaWFzLW5hbWVzIGZyb20gRE9UUyBjbGllbnQgKGMxKSBhbmQgYW5vdGhl ciBjbGllbnQgKGxldOKAmSBjYWxsIChjMTEpKSBiZWhpbmQgKHMxKSBzaG91bGQgYmUgcmVzb2x2 ZWQgYnkgczEgaXRzZWxmLCBpdCBpcyBhbHNvIHRoZSByZXNwb25zaWJpbGl0eSBvZiAoczEpIHRv IHJlc29sdmUgY29uZmxpY3RpbmcgbWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIChjMSkgYW5kIChj MTEpLCBhZ2dyZWdhdGUgdGhlIG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBjbGll bnRzIChjMSBhbmQgYzExKSBhbmQgc2VuZCB0aGUgdXBkYXRlZCBtaXRpZ2F0aW9uIHJlcXVlc3Qg KGMyKS4NCg0KLVRpcnUNCg0KRnJvbTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tXQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMCwgMjAxNyA4OjExIFBNDQpU bzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNB ZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4+OyBrYW5h bWUgbmlzaGl6dWthIDxrYW5hbWVAbnR0djYuanA8bWFpbHRvOmthbmFtZUBudHR2Ni5qcD4+OyBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2Ji aW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQpTdWJq ZWN0OiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSBUaXJ1LA0KDQpJ IGFncmVlIGluIHBhcnQsIGJ1dCB3ZSBuZWVkIHRvIGxvb2sgYXQgdGhlIGVuZCAoYzEpIHRvIGVu ZCAoczMpIHBvdGVudGlhbCBpc3N1ZXMuICBXaGF0IHlvdSBhcmUgcHJvcG9zaW5nIHdvcmtzIGZp bmUgZm9yIChzMikgdG8gKHMzKS4NCg0KKGMxKSByZXF1ZXN0cyBtaXRpZ2F0aW9uIHdpdGggYW4g YWxpYXMtbmFtZSDigJxhbGlhcy0x4oCdLiAgSWYgKHMxKSBkb2VzIG5vdCBwYXNzIGFueXRoaW5n IGV4dHJhIHRvIChjMikgZm9yIG9ud2FyZCB0cmFuc21pc3Npb24sIChzMikgc2VlcyBhIHNpbmds ZSBjbGllbnQgKGMyKSByZXF1ZXN0aW5nIG1pdGlnYXRpb24gd2l0aCBhbGlhcy1uYW1lIOKAnGFs aWFzLTHigJ0uICBGaW5lLCB0aGF0IHdvcmtzLg0KSWYgdGhlcmUgd2FzIGFub3RoZXIgRE9UUyBj bGllbnQgaW4gdGhlIHNhbWUgbG9jYXRpb24gYXMgKGMxKShpLmUuIGMxZGlmZiksIGJvdGggdXNp bmcgKHMxKSB3aG8gYWxzbyBkZWNpZGVkIHRvIHVzZSBhbGlhcy1uYW1lIOKAnGFsaWFzLTHigJ0g d2hvIHRoZW4gcmVxdWVzdHMgbWl0aWdhdGlvbiwgKHMyKSBoYXMgbm8gaWRlYSB0aGF0IHRoZXJl IGFyZSBkaWZmZXJlbnQg4oCcYWxpYXMtMeKAnSBkZWZpbml0aW9ucyBpZiAoYzIpIGRvZXMgbm90 IHNlbmQgYWxzbyBhbiBleHRyYSBkaWZmZXJlbnRpYXRvci4NCg0KU28sIGFueSBET1RTIEdXIGlu IHRoZSBjaGFpbiBzaG91bGQgYmUgcGFzc2luZyBvbiBhIOKAnHVuaXF1ZS1leHRyYeKAnSBwaWVj ZSBvZiBpbmZvcm1hdGlvbi4NCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFpbHRv OiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9u IEJlaGFsZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAxMCBPY3RvYmVyIDIw MTcgMTU6MTUNClRvOiBKb24gU2hhbGxvdzsga2FuYW1lIG5pc2hpenVrYTsgbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRv dHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucw0KU3ViamVj dDogUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KQWdyZWUgd2l0aCB5b3Vy IHJlc3BvbnNlLCBjb25zaWRlciBhIGRlcGxveW1lbnQgd2hpY2ggaGFzIHRoZSBmb2xsb3dpbmcg RE9UUyBhZ2VudHMuDQoNCkRPVFMgY2xpZW50cyAoYzEpIDwtLS0tLS0tLS0tLS0tLS0tLS0tLT4g KHMxKSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgKGMyKSA8LS0tLS0tLS0tLS0tLS0tLT4gKHMy KSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgKGMzKSA8LS0tLS0tLS0tLS0tLS0+IChzMykgRE9U UyBzZXJ2ZXINCg0KTXkgcG9pbnQgaXMsIChjMikgbmVlZCBub3QgY29udmV5IHRoZSDigJxjMSBp ZGVudGl0eeKAnSB0byAoczIpIGJ1dCAoczIpIG5lZWRzIHRvIGNvbnZleSB0aGUg4oCcYzIgaWRl bnRpdHnigJ0gdG8gKGMzKSBhbmQgKGMzKSBpbi10dXJuIHByb3BhZ2F0ZXMgdGhlIOKAnGMyIGlk ZW50aXR54oCdIHRvIChzMykuDQoNCi1UaXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86 c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIw MTcgNjoxNSBQTQ0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJl ZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZl ZS5jb20+Pjsga2FuYW1lIG5pc2hpenVrYSA8a2FuYW1lQG50dHY2LmpwPG1haWx0bzprYW5hbWVA bnR0djYuanA+PjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+ OyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJv ci5uZXQ+Pg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0K SGkgVGlydSwNCg0KQWdyZWVkIHRoYXQgb25seSBhIERPVFMgR1cgc2VydmVyIGZhY2luZyBuZWVk cyB0byBzZW5kIGluZm9ybWF0aW9uIHRvIHRoZSB1cHN0cmVhbSBET1RTIFNlcnZlciDigJMgd2hp Y2ggY291bGQgYWxzbyBiZSBhIERPVFMgR1cuDQogICAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB8IEQgfCAgICB8DQog ICAgICAgICArLS0tLSsgICAgICAgICAgfCAgICB8IE8gfCAgICB8ICAgICAgICAgKy0tLS0rDQog ICAgICAgICB8IGMxIHwtLS0tLS0tLS0tfCBzMSB8IFQgfCBjMiB8LS0tLS0tLS0tfCBzMiB8DQog ICAgICAgICArLS0tLSsgICAgICAgICAgfCAgICB8IFMgfCAgICB8ICAgICAgICAgKy0tLS0rDQog ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB8IEcgfCAgICB8DQogICAgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1kb3RzLWFyY2hpdGVjdHVyZS0wNCNzZWN0aW9uLTIuMi4zDQoNCkhvd2V2ZXIsIHRo ZSBET1RTIEdXIGNsaWVudCBmYWNpbmcgKHMxKSBpcyB0aGUgb25lIHdpdGgga25vd2xlZGdlIG9m IHRoZSBpbmRpdmlkdWFsIGNsaWVudHMgdGhhdCBhcmUgY3VycmVudGx5IHVzaW5nICB0aGUgRE9U UyBzZXJ2ZXIgcnVubmluZyBvbiB0aGUgRE9UUyBHVy4gIFRoaXMgaW5mb3JtYXRpb24gaGFzIHRv IHNvbWVob3cgYmUgcGFzc2VkIG92ZXIgdG8gdGhlIERPVFMgR1cgc2VydmVyIGZhY2luZyAoYzIp LCBidXQgc2VwYXJhdGUgRE9UUyBzdGFja3MgYXJlIGJlaW5nIHJ1biBmb3IgKHMxKSBhbmQgKGMy KSBhcyBwZXIgYXJjaGl0ZWN0dXJlIHNwZWMgMi4yLjMuICBJIHdhcyByZWZlcnJpbmcgdG8gd2hh dCAoczEpIG1heSBuZWVkIHRvIHBhc3Mgb24gdG8gKGMyKSBpbiBteSBlbWFpbCByZXNwb25zZSB0 byBLYW5hbWUsIG5vdCB3aGF0IGlzIHNlbnQgYnkgKGMxKS4NCg0KUmVnYXJkcw0KDQpKb24NCg0K RnJvbTogRG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91 bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpT ZW50OiAxMCBPY3RvYmVyIDIwMTcgMTM6MTYNClRvOiBKb24gU2hhbGxvdzsgJ2thbmFtZSBuaXNo aXp1a2EnOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJv bGFuZCBEb2JiaW5zDQpTdWJqZWN0OiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdl cw0KDQpJIHRob3VnaHQgd2UgYWdyZWVkIHRoYXQgYmFzZWQgb24gdGhlIGN1cnJlbnQgRE9UUyBy ZXF1aXJlbWVudHMgb25seSB0aGUgc2VydmVyLXNpZGUgRE9UUyBHVyBuZWVkcyB0byBjb252ZXkg dGhlIERPVFMgY2xpZW50IChvciBjbGllbnQtc2lkZSBET1RTIFdHKSBpZGVudGl0eSB0byB0aGUg RE9UUyBzZXJ2ZXIuDQoNCi1UaXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBz LWlldGZAanBzaGFsbG93LmNvbV0NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgMjo1 MyBQTQ0KVG86ICdrYW5hbWUgbmlzaGl6dWthJyA8a2FuYW1lQG50dHY2LmpwPG1haWx0bzprYW5h bWVAbnR0djYuanA+PjsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVl LmNvbT4+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJv bGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5l dD4+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSBL YW5hbWUsDQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgaW5mb3JtYXRpb24gbmVjZXNzYXJpbHkgbmVl ZHMgdG8gYmUgdGhlIG9yaWdpbmFsIGNsaWVudCBpZGVudGl0eS4gIFRoZSBHVyBDbGllbnQgc2lk ZSB3aWxsIGhhdmUgaXRzIG93biBpZGVudGl0eSB3aGljaCB0aGUgRE9UUyBTZXJ2ZXIgY2FuIHVz ZSB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gRE9UUyAoR1cpIENsaWVudHMuDQoNClNvLCB5ZXMs IGEgaGFzaGVkIHNldCBvZiBuYW1lcyBjYW4gYmUgdXNlZCDigJMgaXQgaXMgdXAgdG8gdGhlIERP VFMgR1cgQ2xpZW50IHNpZGUgdG8gbWFrZSBzdXJlIHRoYXQgdGhlcmUgYXJlIG5vIGhhc2ggY29s bGlzaW9ucy4gIE9yIGl0IGNvdWxkIGJlIGEgc2ltcGxlIGxpc3Qgc3VjaCBhcyBDMSwgQzIg4oCm Q24uDQoNClJlZ2FyZHMNCg0KSm9uDQoNCkZyb206IERvdHMgW21haWx0bzogZG90cy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yga2Fu YW1lIG5pc2hpenVrYQ0KU2VudDogMTAgT2N0b2JlciAyMDE3IDA0OjE5DQpUbzogS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeTsgSm9uIFNoYWxsb3c7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1h aWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMNClN1YmplY3Q6IFJlOiBbRG90c10g RE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpLA0KDQo+IEkgYWdyZWUgdGhlIGJlbG93IHBy b2JsZW1zIGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IG11 c3QgY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLg0K SSBhZ3JlZSB3aXRoIHRoaXMgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGNhc2UuDQpBdCB0aGUg c2FtZSB0aW1lLCBJIGFncmVlIHdpdGggYmVsb3c6DQo+IEkgYWdyZWUgdGhhdCBpcyBub3QgYSBn b29kIHRoaW5nIHRvIOKAnGxlYWvigJ0gb3V0IGludGVybmFsIGluZm9ybWF0aW9uIHdoZW4gcGFz c2luZyB0aHJvdWdoIGEgRE9UUyBHVywNCg0KVGhlbiwgc2hvdWxkIERPVFMgR1cgc2VuZCDigJxj bGllbnQgaWRlbnRpdHnigJ0gKGkuZS4gY2VydGlmaWNhdGVzIG9mIERPVFMgY2xpZW50cykgaXRz ZWxmIG9yIGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHnigJ0pIHRvIERPVFMgc2VydmVyPw0KSWYg bGF0ZXIsIGhvdyBjYW4gRE9UUyBzZXJ2ZXIgcmVhY3QgdG8gdGhlIGFtYmlndW91cyBpbmZvcm1h dGlvbiBvZiB0aGUgaGFzaGVkKOKAnGNsaWVudCBpZGVudGl0eeKAnSkuDQoNCnJlZ2FyZHMsDQpL YW5hbWUNCk9uIDIwMTcvMTAvMDkgMjI6MzQsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgd3Jv dGU6DQpIaSBKb24sDQoNCkkgYWdyZWUgdGhlIGJlbG93IHByb2JsZW1zIGFyZSBhcHBsaWNhYmxl IGZvciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IG11c3QgY29udmV5IHRoZSDigJxjbGll bnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiBCdXQgZm9yIHRoZSBjbGllbnQtc2lk ZSBET1RTIGdhdGV3YXksIGl0IHNob3VsZCByZXNvbHZlIGNvbmZsaWN0aW5nIHJ1bGVzIGIvdyBE T1RTIGNsaWVudHMgKGUuZy4gb25lIGNsaWVudCBpbnN0YWxsaW5nIGJsYWNrLWxpc3QgQUNMIGZv ciBhbiBJUCBhZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xpZW50IGluc3RhbGxzIHdoaXRlLWxpc3Qg QUNMIGZvciB0aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1lIGFsaWFzLW5hbWVzIGZvciBkaWZmZXJl bnQgbWl0aWdhdGlvbiBzY29wZXMpLiBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkIGZvciBhIGNsaWVu dC1zaWRlIERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKAnGNsaWVudCBpZGVudGl0eeKAnSB0 byB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IG9yIERPVFMgc2VydmVyLg0KDQotVGlydQ0K DQpGcm9tOiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQpT ZW50OiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3IDI6MDcgUE0NClRvOiBLb25kYSwgVGlydW1h bGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjxtYWlsdG86 VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYu b3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9y Lm5ldD48bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9U UyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUsDQoNClRoaXMgZGlzY3Vzc2lvbiBnb2Vz IGJleW9uZCBqdXN0IHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QuICBXZSBuZWVkIHRvIGNvbnNpZGVy IHdoYXQgaGFwcGVucyB3aXRoIGJvdGggYWxpYXMtbmFtZSBhbmQgYWNsLW5hbWUgKGRhdGEgY2hh bm5lbCkNCg0KVGhlIHNpbXBsZSBjYXNlIG9mIGEgbWl0aWdhdGlvbiByZXF1ZXN0IHdpdGggbm8g YWxpYXMtbmFtZSBkb2VzIG5vdCByZXF1aXJlIGFueSBrbm93bGVkZ2Ugb2YgdGhlIG9yaWdpbmFs IGNsaWVudC4NCg0KSG93ZXZlciwgaWYgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCB1c2VzIGFsaWFz LW5hbWUsIHRoZW4gdGhlcmUgYXJlIDMgd2F5cyBvZiBoYW5kbGluZyB0aGlzDQoNCmEpICAgICAg IFRoZSBET1RTIEdXIHJlcGxhY2VzIHRoZSBhbGlhcy1uYW1lIHdpdGggaXRzIGFjdHVhbCBkZWZp bml0aW9uICh0YXJnZXQtaXBzIGV0Yy4gbWVyZ2VkIGFzIGFwcHJvcHJpYXRlKSwgc28gYWxpYXMt bmFtZSBpcyBub3QgZm9yd2FyZGVkIG9uIHRvIFNlcnZlciDigJMganVzdCB0aGUgZXhwYW5kZWQg bWl0aWdhdGlvbiByZXF1ZXN0IGlzIGZvcndhcmRlZA0KDQpiKSAgICAgIFRoZSBET1RTIEdXIHVw ZGF0ZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBhIHVuaXF1ZSBhbGlhcy1uYW1lIHRoYXQgaXMgZm9y d2FyZGVkIChhbmQgaGFzIHRvIGRvIHRoZSBzYW1lIHRoaW5nIHdoZW4gdGhlIGFsaWFzLW5hbWUg aXMgY29uZmlndXJlZCBvbiB0aGUgZGF0YSBjaGFubmVsKSDigJMgdG8gaGFuZGxlIDIgb3IgbW9y ZSBjbGllbnRzIGRlZmluaW5nIHRoZSBzYW1lIGFsaWFzLW5hbWUgd2hpY2ggaGF2ZSBkaWZmZXJl bnQgY2hhcmFjdGVyaXN0aWNzDQoNCmMpICAgICAgIFRoZSBET1RTIEdXIHJlY29nbmlzZXMgdGhh dCBhbGlhcy1uYW1lIGlzIG5vdCB1bmlxdWUgYW5kIGFkZHMgaW4g4oCdYWRkaXRpb25hbC1jbGll bnQtaW5mb+KAnSAoSSB0aGluayBJIHByZWZlciB0aGlzIOKAnC1pbmZv4oCdIG5hbWUgdG8gY2xp ZW50LWlkIG9yIG9yaWdpbmFsLWNsaWVudC1pZCBhcyDigJwtaWTigJ0gaXMgdG9vIGNsb3NlbHkg IGFzc29jaWF0ZWQgd2l0aCBDbGllbnQgSWRlbnRpdHkgZGVyaXZlZCBmcm9tIHRoZSBET1RTIEdX IENsaWVudCBjZXJ0aWZpY2F0ZSkNCldlIGhhdmUgYWdyZWVkIHRoYXQgd2hlbiBhIGNsaWVudCBy ZXF1ZXN0cyBtaXRpZ2F0aW9uIHN0YXR1cywgdGhlIOKAnGFsaWFzLW5hbWXigJ0gc2hvdWxkIGJl IHJldHVybmVkIGFzIOKAnGFsaWFzLW5hbWXigJ0gYW5kIG5vdCB0aGUgc3Vic3RpdHV0ZWQgYWxp YXMtbmFtZSBjb25maWd1cmF0aW9uICh0aGlzIGRvZXMgbmVlZCB0byBiZSBzdGF0ZWQgaW4gdGhl IHNwZWMgZm9yIGNsYXJpdHkpLiAgVGhpcyBtYWtlcyAoYSkgZGlmZmljdWx0IHRvIGJlIGhhbmRs ZWQgYnkgRE9UUyBHVyB3aGljaCB0aGVuIHJhaXNlcyB0aGUgcXVlc3Rpb24g4oCTIGRvIHdlIHJl YWxseSBuZWVkIGFsaWFzLW5hbWU/DQoNClRoZSBkZWZpbml0aW9uIGFuZCBhc3NvY2lhdGlvbiBv ZiBBQ0xzL0ZpbHRlcnMgb2YgdGhlIGRhdGEgY2hhbm5lbCBpcyBtb3JlIGRpZmZpY3VsdCDigJMg dGhlIFNlcnZlciBtdXN0IGluc3RhbGwgLyBhcHBseSB0aGUgYXBwcm9wcmlhdGUgQUNMcyBvbiBh IHBlciAoT3JpZ2luYWwpIENsaWVudCBiYXNpcyB3aGVuIG1pdGlnYXRpb24gaXMgaW52b2tlZC4N CkNsaWVudCAx4oCZcyBjb25jZXB0IG9mIGEgV2hpdGVsaXN0IElQIGNvdWxkIGJlIENsaWVudCAy 4oCZcyBjb25jZXB0IG9mIGEgQmxhY2tsaXN0IElQLiAgVGhlIFNlcnZlciBuZWVkcyB0byBrbm93 IHdoaWNoIGNsaWVudCBpcyByZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uIGFuZCBpbnN0YWxsIHRo ZSBjb3JyZWN0IEFDTHMg4oCTIGlmIHRoZXJlIHdhcyBubyDigJ1hZGRpdGlvbmFsLWNsaWVudC1p bmZv4oCdLCB0aGUgU2VydmVyIG9ubHkga25vd3MgdGhhdCBoZSBoYXMgdG8gaW5zdGFsbCBBTEwg b2YgdGhlIEFDTHMgKGkuZS4gYm90aCB0aGUgQmxhY2sgYW5kIFdoaXRlIGxpc3Qgb2YgdGhlIHNh bWUgSVAgYXMgZGVmaW5lZCBieSBDbGllbnQgMSBhbmQgQ2xpZW50IDIpIGFzIGRlZmluZWQgYnkg aGlzIGNsaWVudCAoRE9UUyBHVykgd2hlbiBoaXMgY2xpZW50IHJlcXVlc3RzIGEgbWl0aWdhdGlv bi4gIEhlcmUsIEkgdGhpbmsgdGhhdCBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGNsaWVudCBm b3IgdGhlIERPVFMgR1csIOKAnWFkZGl0aW9uYWwtY2xpZW50LWluZm/igJ0gaXMgcmVxdWlyZWQu DQoNClJlZ2FyZHMNCg0KSm9uDQoNCkZyb206IERvdHMgW21haWx0bzogZG90cy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgS29uZGEs IFRpcnVtYWxlc3dhciBSZWRkeQ0KU2VudDogMDcgT2N0b2JlciAyMDE3IDA0OjI4DQpUbzogSm9u IFNoYWxsb3c7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsg Um9sYW5kIERvYmJpbnMNClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVu Z2VzDQoNCkluIGNhc2Ugb2YgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5LCB3aHkgZG9lcyB0aGUg RE9UUyBzZXJ2ZXIgbmVlZCB0byBrbm93IHdoaWNoIOKAnERPVFMgY2xpZW504oCdIGhhcyBjb252 ZXllZCB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0ID8NCkZvciBleGFtcGxlLCB0aGUgRE9UUyBjbGll bnQgY291bGQgYmUgYSBERG9TIGRldGVjdG9yIG9yIGFuIEFwcGxpY2F0aW9uIHNlcnZlciwgYW5k IHRoZSBjbGllbnQtc2lkZSBnYXRld2F5IHdpbGwgaGF2ZSB0byByZXNvbHZlIHRoZSBjb25mbGlj dGluZyBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50cywgYWdncmVnYXRl IHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50IGFuZCBzZW5kIHRo ZSB1cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuDQoNCi1UaXJ1 DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0N ClNlbnQ6IEZyaWRheSwgT2N0b2JlciA2LCAyMDE3IDc6NDIgUE0NClRvOiBLb25kYSwgVGlydW1h bGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpU aXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPj47IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYu b3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9y Lm5ldDxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pj4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9U UyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUsDQoNClVubGVzcyBJIGFtIG1pc3Npbmcg c29tZXRoaW5nLCBob3cgZG9lcyB0aGUgQ2xpZW50IHNpZGUgb2YgRE9UUyBHVyBjb252ZXkgdG8g dGhlIHVwc3RyZWFtIHNlcnZlciBhIHVuaXF1ZSDigJxjbGllbnQtaWTigJ0gd2hpY2ggaXMgZGlm ZmVyZW50IHRvIHRoZSBpbXBsaWVkIGNsaWVudCBpZCBhcyBkZXJpdmVkIGZyb20gdGhlIFBLSSBj ZXJ0aWZpY2F0ZSB0aGF0IHRoZSBET1RTIEdX4oCZQ2xpZW50IHVzZXMvcHJlc2VudHMgd2hlbiBj b21tdW5pY2F0aW5nIHRvIHRoZSBzZXJ2ZXI/DQpUbyBtZSwgdGhlcmUgbmVlZHMgdG8gYmUgYW4g b3B0aW9uIHN1Y2ggYXMg4oCcb3JpZ2luYWwtY2xpZW50LWlk4oCdIG9yIOKAnGNsaWVudC1pZOKA nSAod2hpY2ggaXMgY29uZnVzaW5nIHdoZW4gYWxzbyByZWZlcnJpbmcgdG8gdGhlIGNsaWVudCBp ZGVudGl0eSBhcyBkZXJpdmVkIGZyb20gdGhlIChET1RTIEdXKSBDbGllbnTigJlzIFBLSSBjZXJ0 aWZpY2F0ZSkgYXMgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbC4NCg0KSSBhZ3JlZSB0aGF0IHRoZSBE T1RTIEdXIGNhbiBnZW5lcmF0ZSBpdHMgb3duIHVuaXF1ZSBjbGllbnQtaWQgdG8gc3RvcCBtdWx0 aXBsZSBlbnRyaWVzIGJlaW5nIG5lZWRlZC4NCg0KSSBhZ3JlZSB0aGF0IGlzIG5vdCBhIGdvb2Qg dGhpbmcgdG8g4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5mb3JtYXRpb24gd2hlbiBwYXNzaW5n IHRocm91Z2ggYSBET1RTIEdXLCBzbyBteSBSRVFVSVJFRCBkb2VzIG5vdCBtYWtlIHNlbnNlLg0K DQpSZWdhcmRzDQoNCkpvbg0KUFMg4oCTIEkgYW0gaGF2aW5nIHRvIGRlYWwgd2l0aCBvdGhlciBz dHVmZiBhdCBwcmVzZW50IOKAkyBJIHdpbGwgZ2V0IGJhY2sgbGF0ZXIgb24gdGhlIG90aGVyIGlz c3VlcyB1bmRlciBkaXNjdXNzaW9uDQoNCkZyb206IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkg W21haWx0bzogVGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbTxtYWlsdG86VGlydW1h bGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbT5dDQpTZW50OiAwNiBPY3RvYmVyIDIwMTcgMTQ6 NTgNClRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPjsgSm9uIFNoYWxsb3c7ICdEb2JiaW5zLCBSb2xhbmQnOyBkb3RzQGll dGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTIEdh dGV3YXlzIENoYWxsZW5nZXMNCg0KSSBkb27igJl0IHNlZSBhIG5lZWQgZm9yIGNsaWVudC1zaWRl IERPVFMgZ2F0ZXdheSB0byBjb252ZXkgdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRv IHRoZSBET1RTIHNlcnZlci4g4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gbG9va3MgcmVxdWly ZWQgb25seSBmb3IgdGhlIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheXMuIEluIGNhc2Ugb2Ygc2Vy dmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5IHRoZSBjbGllbnQtaWQgZ2VuZXJh dGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZl ci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1bmlxdWUgY2xpZW50LWlkIGFuZCBk b2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4gYXJyYXkgb2YgY2xpZW50LWlkcyB0byB0aGUgRE9UUyBz ZXJ2ZXIgdG8gcmVzb2x2ZSBjbGFzaGVzLg0KDQotVGlydQ0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRvdHMgbWFpbGluZyBsaXN0DQoNCkRv dHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZG90cw0KDQo= --_000_DM5PR16MB1788CBCF3F6ADCED2D28FEBFEA750DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1 IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7 DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNl cmlmOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFj azt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpi bGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBVSSIsc2Fu cy1zZXJpZjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRl IGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30N CnAuVGV4dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxsZXMNCgl7 bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRl IGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1h bDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVt YWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMzUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUzNg0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUzOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi PkhpIEpvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi PlRoZSByb2xlIG9mIHMxIGlzIG11Y2ggbW9yZSB0aGFuIGp1c3QgZm9yd2FyZGluZyB0aGUgRE9U UyBjbGllbnQgbWVzc2FnZXMsIHBsZWFzZSBzZWUgKFNJRy0wMDkgaW4gdGhlIHJlcXVpcmVtZW50 cyBkcmFmdHMpLCBpZiBhIERPVFMgY2xpZW50IGhhcyB1c2VkIHRoZSBzYW1lDQogYWxpYXMgbmFt ZSBwcmV2aW91c2x5IGNvbnZleWVkIGJ5IGFub3RoZXIgY2xpZW50IHRoZW4gczEgbXVzdCByZWpl Y3QgdGhlIHJlcXVlc3QuIElmIGNvbmZsaWN0aW5nIHJlcXVlc3RzIGFyZSByZXNvbHZlZCBieSBz MSB0aGVuIGFueSByZXNwb25zZSBtZXNzYWdlIHNlbnQgYnkgczMgd2lsbCBiZSBmb3J3YXJkZWQg YnkgczEgdG8gdGhlIHJpZ2h0IERPVFMgY2xpZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEpvbiBTaGFsbG93 IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBPY3RvYmVyIDEwLCAyMDE3IDg6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBU aXJ1bWFsZXN3YXIgUmVkZHkgJmx0O1RpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20m Z3Q7OyBrYW5hbWUgbmlzaGl6dWthICZsdDtrYW5hbWVAbnR0djYuanAmZ3Q7OyBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tOyBkb3RzQGlldGYub3JnOyBSb2xhbmQgRG9iYmlucyAmbHQ7cmRv YmJpbnNAYXJib3IubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMg R2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkg VGlydSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+VGhlbiB0aGF0IGJyZWFrcyBhIHNpZ25hbCBHRVQgZm9yIG1pdGln YXRpb24gc3RhdHVzIGZyb20gKGMxKSAobWl0aWdhdGlvbiByZXF1ZXN0IHVzZXMgYWxpYXMtbmFt ZSkg4oCTIHdoYXQgZ2V0cyBzZW50IGJhY2sgaW4gdGhlIGFsaWFzLW5hbWUgZmllbGQNCiB3aGVu IHRoZSByZXNwb25zZSB0aGF0IGlzIHNlbnQgYnkgKHMzKSB3aGVuIGl0IGdldHMgdG8gKGMxKT88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SSB0aG91Z2h0IHdlIGhhZCBhZ3JlZWQgdG8gbGVhdmUgdGhlIGFsaWFzIG5h bWUg4oCTIGFzIGlzIOKAkyAobm90IHN1YnN0aXR1dGVkKSBpbiB3aGF0IGlzIHNlbnQgYmFjayB0 byAoYzEpIGZyb20gKHMxKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+KGMxKSBpcyBub3QgcGFydGljdWxhcmx5IGlu dGVyZXN0ZWQgaW4gaG93IChjMTEpIGlzIGdldHRpbmcgbWl0aWdhdGVkIGFuZCBwcm9iYWJseSBk b2VzIG5vdCB3YW50IChjMTEpIHN0YXRzIGFkZGVkIGludG8gaGlzIOKAkyAoczMpIG5lZWQgdG8g a25vdyBob3cNCiB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gKGMxKSBhbmQgKGMxMSkg4oCTIHdo aWNoIGlzIGVhc2lseSBkb25lIGlmIChjMSkgKG9yIChjMTEpIGluZm9ybWF0aW9uIGlzIHBhc3Nl ZCB1cCB0byAoczMpLCBzdGFydGluZyB3aXRoIChzMSkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgd2hvbGUg dGhpbmcgbmVlZHMgdG8gYmUgc2NhbGFibGUsIGFuZCBJIGFtIHN0cnVnZ2xpbmcgd2l0aCBob3cg dG8gYWN0dWFsbHkgaW1wbGVtZW50IHlvdXIgcHJvcG9zYWwuJm5ic3A7IEFsbG93aW5nIGVhY2gg RE9UUyBHVyB0byBsZWFybiBhbmQgcGFzcw0KIG9uIHNvbWV0aGluZyBleHRyYSB0aGF0IGRpZmZl cmVudGlhdGVzIHRoZSBET1RTIEdXIGltbWVkaWF0ZSBjbGllbnRzIG1ha2VzIHRoZSBpbXBsZW1l bnRhdGlvbiByZWxhdGl2ZWx5IGVhc3kuJm5ic3A7IFRoZXJlIGlzIG5vIG5lZWQgZm9yIGEgRE9U UyBHVyB0byBhZGQgaW4gYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBpZiBleHRyYSBpbmZvcm1hdGlv biBpcyBhbHJlYWR5IGVtYmVkZGVkIOKAkyB1bmxlc3MgaGUgc2VlcyBhIG5hbWUgY2xhc2ggZnJv bSAyIG9yDQogbW9yZSBvZiBoaXMgdW5pcXVlbHkgaWRlbnRpZmllZCBET1RTIGNsaWVudHMg4oCT IHdoaWNoIHdpbGwgYmUgZGlmZmVyZW50IGVudGl0aWVzIGFueXdheS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVn YXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Kb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IERvdHMg W21haWx0bzoNCjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMtYm91 bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZg0KPC9iPktvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHk8YnI+DQo8Yj5TZW50OjwvYj4gMTAgT2N0b2JlciAyMDE3IDE1OjUyPGJyPg0KPGI+ VG86PC9iPiBKb24gU2hhbGxvdzsga2FuYW1lIG5pc2hpenVrYTsgPGEgaHJlZj0ibWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTwvYT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsg Um9sYW5kIERvYmJpbnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3 YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij5UaGUgY29uZmxpY3RpbmcgYWxpYXMtbmFtZXMgZnJvbSBET1RTIGNsaWVudCAoYzEp IGFuZCBhbm90aGVyIGNsaWVudCAobGV04oCZIGNhbGwgKGMxMSkpIGJlaGluZCAoczEpIHNob3Vs ZCBiZSByZXNvbHZlZCBieSBzMSBpdHNlbGYsIGl0IGlzIGFsc28gdGhlIHJlc3BvbnNpYmlsaXR5 DQogb2YgKHMxKSB0byByZXNvbHZlIGNvbmZsaWN0aW5nIG1pdGlnYXRpb24gcmVxdWVzdHMgZnJv bSAoYzEpIGFuZCAoYzExKSwgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+YWdncmVnYXRlIHRoZSBt aXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50cyAoYzEgYW5kIGMxMSkgYW5k IHNlbmQgdGhlIHVwZGF0ZWQgbWl0aWdhdGlvbiByZXF1ZXN0IChjMikuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pi1UaXJ1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gSm9uIFNoYWxsb3cgWzxhIGhy ZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tIj5tYWlsdG86c3VwanBzLWlldGZA anBzaGFsbG93LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAx MCwgMjAxNyA4OjExIFBNPGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5 ICZsdDs8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+ VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTwvYT4mZ3Q7OyBrYW5hbWUgbmlzaGl6 dWthICZsdDs8YSBocmVmPSJtYWlsdG86a2FuYW1lQG50dHY2LmpwIj5rYW5hbWVAbnR0djYuanA8 L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5t b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0 Zi5vcmciPg0KZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJt YWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgVGlydSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3Jl ZSBpbiBwYXJ0LCBidXQgd2UgbmVlZCB0byBsb29rIGF0IHRoZSBlbmQgKGMxKSB0byBlbmQgKHMz KSBwb3RlbnRpYWwgaXNzdWVzLiZuYnNwOyBXaGF0IHlvdSBhcmUgcHJvcG9zaW5nIHdvcmtzIGZp bmUgZm9yIChzMikgdG8gKHMzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+KGMxKSByZXF1ZXN0cyBtaXRpZ2F0aW9u IHdpdGggYW4gYWxpYXMtbmFtZSDigJxhbGlhcy0x4oCdLiZuYnNwOyBJZiAoczEpIGRvZXMgbm90 IHBhc3MgYW55dGhpbmcgZXh0cmEgdG8gKGMyKSBmb3Igb253YXJkIHRyYW5zbWlzc2lvbiwgKHMy KSBzZWVzIGEgc2luZ2xlDQogY2xpZW50IChjMikgcmVxdWVzdGluZyBtaXRpZ2F0aW9uIHdpdGgg YWxpYXMtbmFtZSDigJxhbGlhcy0x4oCdLiZuYnNwOyBGaW5lLCB0aGF0IHdvcmtzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgdGhlcmUgd2FzIGFub3RoZXIgRE9UUyBjbGllbnQg aW4gdGhlIHNhbWUgbG9jYXRpb24gYXMgKGMxKShpLmUuIGMxZGlmZiksIGJvdGggdXNpbmcgKHMx KSB3aG8gYWxzbyBkZWNpZGVkIHRvIHVzZSBhbGlhcy1uYW1lIOKAnGFsaWFzLTHigJ0gd2hvIHRo ZW4NCiByZXF1ZXN0cyBtaXRpZ2F0aW9uLCAoczIpIGhhcyBubyBpZGVhIHRoYXQgdGhlcmUgYXJl IGRpZmZlcmVudCDigJxhbGlhcy0x4oCdIGRlZmluaXRpb25zIGlmIChjMikgZG9lcyBub3Qgc2Vu ZCBhbHNvIGFuIGV4dHJhIGRpZmZlcmVudGlhdG9yLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvLCBhbnkgRE9U UyBHVyBpbiB0aGUgY2hhaW4gc2hvdWxkIGJlIHBhc3Npbmcgb24gYSDigJx1bmlxdWUtZXh0cmHi gJ0gcGllY2Ugb2YgaW5mb3JtYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Sm9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IERvdHMgW21haWx0bzoNCjxhIGhy ZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRmLm9yZzwv YT5dIDxiPk9uIEJlaGFsZiBPZg0KPC9iPktvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk8YnI+DQo8 Yj5TZW50OjwvYj4gMTAgT2N0b2JlciAyMDE3IDE1OjE1PGJyPg0KPGI+VG86PC9iPiBKb24gU2hh bGxvdzsga2FuYW1lIG5pc2hpenVrYTsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9 Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnM8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5BZ3JlZSB3 aXRoIHlvdXIgcmVzcG9uc2UsIGNvbnNpZGVyIGEgZGVwbG95bWVudCB3aGljaCBoYXMgdGhlIGZv bGxvd2luZyBET1RTIGFnZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPkRPVFMgY2xpZW50cyAoYzEpDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOndpbmRvd3RleHQiPsOfPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4tLS0tLS0tLS0tLS0tLS0tPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztj b2xvcjp3aW5kb3d0ZXh0Ij7DoDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+DQogKHMxKSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgKGMyKSA8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xv cjp3aW5kb3d0ZXh0Ij7Dnzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ LS0tLS0tLS0tLS0tPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+w6A8L3NwYW4+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4NCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+KHMyKSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgKGMz KQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldpbmdk aW5ncztjb2xvcjp3aW5kb3d0ZXh0Ij7Dnzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+LS0tLS0tLS0tLTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+w6A8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPg0KIChzMykgRE9UUyBzZXJ2ZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPk15IHBvaW50IGlzLCAoYzIpIG5l ZWQgbm90IGNvbnZleSB0aGUg4oCcYzEgaWRlbnRpdHnigJ0gdG8gKHMyKSBidXQgKHMyKSBuZWVk cyB0byBjb252ZXkgdGhlIOKAnGMyIGlkZW50aXR54oCdIHRvIChjMykgYW5kIChjMykgaW4tdHVy biBwcm9wYWdhdGVzIHRoZSDigJxjMiBpZGVudGl0eeKAnQ0KIHRvIChzMykuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4tVGlydTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBKb24gU2hhbGxvdyBbPGEgaHJlZj0i bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20iPm1haWx0bzpzdXBqcHMtaWV0ZkBqcHNo YWxsb3cuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDEwLCAy MDE3IDY6MTUgUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0 OzxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj5UaXJ1 bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDs7IGthbmFtZSBuaXNoaXp1a2Eg Jmx0OzxhIGhyZWY9Im1haWx0bzprYW5hbWVAbnR0djYuanAiPmthbmFtZUBudHR2Ni5qcDwvYT4m Z3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9y ZyI+DQpkb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0 bzpyZG9iYmluc0BhcmJvci5uZXQiPnJkb2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBUaXJ1LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BZ3JlZWQgdGhh dCBvbmx5IGEgRE9UUyBHVyBzZXJ2ZXIgZmFjaW5nIG5lZWRzIHRvIHNlbmQgaW5mb3JtYXRpb24g dG8gdGhlIHVwc3RyZWFtIERPVFMgU2VydmVyIOKAkyB3aGljaCBjb3VsZCBhbHNvIGJlIGEgRE9U UyBHVy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tLS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgfCBEIHwmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLSYjNDM7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsgfCBPIHwmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwgYzEgfC0tLS0tLS0tLS18IHMxIHwgVCB8IGMyIHwtLS0tLS0tLS18 IHMyIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0mIzQzOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwgUyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tJiM0Mzs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtZG90cy1hcmNoaXRlY3R1cmUtMDQjc2VjdGlvbi0yLjIuMyI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmUtMDQjc2VjdGlvbi0yLjIuMzwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgdGhlIERPVFMgR1cgY2xpZW50IGZhY2luZyAoczEpIGlz IHRoZSBvbmUgd2l0aCBrbm93bGVkZ2Ugb2YgdGhlIGluZGl2aWR1YWwgY2xpZW50cyB0aGF0IGFy ZSBjdXJyZW50bHkgdXNpbmcgJm5ic3A7dGhlIERPVFMgc2VydmVyIHJ1bm5pbmcgb24NCiB0aGUg RE9UUyBHVy4mbmJzcDsgVGhpcyBpbmZvcm1hdGlvbiBoYXMgdG8gc29tZWhvdyBiZSBwYXNzZWQg b3ZlciB0byB0aGUgRE9UUyBHVyBzZXJ2ZXIgZmFjaW5nIChjMiksIGJ1dCBzZXBhcmF0ZSBET1RT IHN0YWNrcyBhcmUgYmVpbmcgcnVuIGZvciAoczEpIGFuZCAoYzIpIGFzIHBlciBhcmNoaXRlY3R1 cmUgc3BlYyAyLjIuMy4mbmJzcDsgSSB3YXMgcmVmZXJyaW5nIHRvIHdoYXQgKHMxKSBtYXkgbmVl ZCB0byBwYXNzIG9uIHRvIChjMikgaW4gbXkgZW1haWwgcmVzcG9uc2UNCiB0byBLYW5hbWUsIG5v dCB3aGF0IGlzIHNlbnQgYnkgKGMxKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5K b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IERvdHMgW21haWx0bzoNCjxhIGhyZWY9 Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5d IDxiPk9uIEJlaGFsZiBPZg0KPC9iPktvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk8YnI+DQo8Yj5T ZW50OjwvYj4gMTAgT2N0b2JlciAyMDE3IDEzOjE2PGJyPg0KPGI+VG86PC9iPiBKb24gU2hhbGxv dzsgJ2thbmFtZSBuaXNoaXp1a2EnOyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0i bWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmluczxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkkgdGhvdWdo dCB3ZSBhZ3JlZWQgdGhhdCBiYXNlZCBvbiB0aGUgY3VycmVudCBET1RTIHJlcXVpcmVtZW50cyBv bmx5IHRoZSBzZXJ2ZXItc2lkZSBET1RTIEdXIG5lZWRzIHRvIGNvbnZleSB0aGUgRE9UUyBjbGll bnQgKG9yIGNsaWVudC1zaWRlIERPVFMgV0cpIGlkZW50aXR5DQogdG8gdGhlIERPVFMgc2VydmVy LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPi1UaXJ1 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEpvbiBTaGFs bG93IFs8YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+bWFpbHRvOnN1 cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IE9jdG9iZXIgMTAsIDIwMTcgMjo1MyBQTTxicj4NCjxiPlRvOjwvYj4gJ2thbmFtZSBuaXNoaXp1 a2EnICZsdDs8YSBocmVmPSJtYWlsdG86a2FuYW1lQG50dHY2LmpwIj5rYW5hbWVAbnR0djYuanA8 L2E+Jmd0OzsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRp cnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRh QE1jQWZlZS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFp bHRvOmRvdHNAaWV0Zi5vcmciPg0KZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zICZs dDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hh bGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgS2FuYW1lLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIGRvIG5vdCB0aGluayB0aGF0IGluZm9ybWF0aW9uIG5lY2Vzc2FyaWx5IG5lZWRz IHRvIGJlIHRoZSBvcmlnaW5hbCBjbGllbnQgaWRlbnRpdHkuJm5ic3A7IFRoZSBHVyBDbGllbnQg c2lkZSB3aWxsIGhhdmUgaXRzIG93biBpZGVudGl0eSB3aGljaCB0aGUgRE9UUw0KIFNlcnZlciBj YW4gdXNlIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBET1RTIChHVykgQ2xpZW50cy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+U28sIHllcywgYSBoYXNoZWQgc2V0IG9mIG5hbWVzIGNhbiBiZSB1c2VkIOKAkyBpdCBp cyB1cCB0byB0aGUgRE9UUyBHVyBDbGllbnQgc2lkZSB0byBtYWtlIHN1cmUgdGhhdCB0aGVyZSBh cmUgbm8gaGFzaCBjb2xsaXNpb25zLiZuYnNwOyBPciBpdCBjb3VsZCBiZQ0KIGEgc2ltcGxlIGxp c3Qgc3VjaCBhcyBDMSwgQzIg4oCmQ24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Sm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBEb3RzIFttYWlsdG86DQo8YSBocmVm PSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5rYW5hbWUgbmlzaGl6dWthPGJyPg0KPGI+U2VudDo8L2I+ IDEwIE9jdG9iZXIgMjAxNyAwNDoxOTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dh ciBSZWRkeTsgSm9uIFNoYWxsb3c7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIj4NCm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJt YWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVO LUdCIj5IaSw8YnI+DQo8YnI+DQomZ3Q7IEkgYWdyZWUgdGhlIGJlbG93IHByb2JsZW1zIGFyZSBh cHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IG11c3QgY29udmV5IHRo ZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLg0KPGJyPg0KSSBhZ3Jl ZSB3aXRoIHRoaXMgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGNhc2UuPGJyPg0KQXQgdGhlIHNh bWUgdGltZSwgSSBhZ3JlZSB3aXRoIGJlbG93Ojxicj4NCiZndDsgSSBhZ3JlZSB0aGF0IGlzIG5v dCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5mb3JtYXRpb24gd2hl biBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLA0KPGJyPg0KPGJyPg0KVGhlbiwgc2hvdWxkIERP VFMgR1cgc2VuZCDigJxjbGllbnQgaWRlbnRpdHnigJ0gKGkuZS4gY2VydGlmaWNhdGVzIG9mIERP VFMgY2xpZW50cykgaXRzZWxmIG9yIGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHnigJ0pIHRvIERP VFMgc2VydmVyPzxicj4NCklmIGxhdGVyLCBob3cgY2FuIERPVFMgc2VydmVyIHJlYWN0IHRvIHRo ZSBhbWJpZ3VvdXMgaW5mb3JtYXRpb24gb2YgdGhlIGhhc2hlZCjigJxjbGllbnQgaWRlbnRpdHni gJ0pLjxicj4NCjxicj4NCnJlZ2FyZHMsPGJyPg0KS2FuYW1lPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiAyMDE3 LzEwLzA5IDIyOjM0LCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5IaSBKb24sPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkkgYWdyZWUgdGhlIGJlbG93IHByb2JsZW1zIGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2ZXIt c2lkZSBET1RTIGdhdGV3YXksIGl0IG11c3QgY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHni gJ0gdG8gdGhlIERPVFMgc2VydmVyLiBCdXQgZm9yIHRoZSBjbGllbnQtc2lkZSBET1RTIGdhdGV3 YXksDQogaXQgc2hvdWxkIHJlc29sdmUgY29uZmxpY3RpbmcgcnVsZXMgYi93IERPVFMgY2xpZW50 cyAoZS5nLiBvbmUgY2xpZW50IGluc3RhbGxpbmcgYmxhY2stbGlzdCBBQ0wgZm9yIGFuIElQIGFk ZHJlc3MgYnV0IHRoZSBvdGhlciBjbGllbnQgaW5zdGFsbHMgd2hpdGUtbGlzdCBBQ0wgZm9yIHRo ZSBzYW1lIElQIGFkZHJlc3MsIHNhbWUgYWxpYXMtbmFtZXMgZm9yIGRpZmZlcmVudCBtaXRpZ2F0 aW9uIHNjb3BlcykuIEkgZG9u4oCZdCBzZWUgdGhlIG5lZWQNCiBmb3IgYSBjbGllbnQtc2lkZSBE T1RTIGdhdGV3YXkgdG8gY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIHNl cnZlci1zaWRlIERPVFMgZ2F0ZXdheSBvciBET1RTIHNlcnZlci48L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+LVRpcnU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEpv biBTaGFsbG93IFs8YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+bWFp bHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNh dHVyZGF5LCBPY3RvYmVyIDcsIDIwMTcgMjowNyBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeSA8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFA TWNBZmVlLmNvbSI+DQombHQ7VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSZndDs8 L2E+OyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5v cmciPmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmlucw0KPGEgaHJlZj0ibWFpbHRvOnJk b2JiaW5zQGFyYm9yLm5ldCI+Jmx0O3Jkb2JiaW5zQGFyYm9yLm5ldCZndDs8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgVGlydSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgZGlzY3Vzc2lvbiBnb2Vz IGJleW9uZCBqdXN0IHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QuJm5ic3A7IFdlIG5lZWQgdG8gY29u c2lkZXIgd2hhdCBoYXBwZW5zIHdpdGggYm90aCBhbGlhcy1uYW1lIGFuZCBhY2wtbmFtZSAoZGF0 YSBjaGFubmVsKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+VGhlIHNpbXBsZSBjYXNlIG9mIGEgbWl0aWdhdGlvbiByZXF1ZXN0 IHdpdGggbm8gYWxpYXMtbmFtZSBkb2VzIG5vdCByZXF1aXJlIGFueSBrbm93bGVkZ2Ugb2YgdGhl IG9yaWdpbmFsIGNsaWVudC4mbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgaWYgdGhlIG1pdGlnYXRp b24gcmVxdWVzdCB1c2VzIGFsaWFzLW5hbWUsIHRoZW4gdGhlcmUgYXJlIDMgd2F5cyBvZiBoYW5k bGluZyB0aGlzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hKTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RTIEdXIHJlcGxhY2VzIHRoZSBhbGlh cy1uYW1lIHdpdGggaXRzIGFjdHVhbCBkZWZpbml0aW9uICh0YXJnZXQtaXBzIGV0Yy4gbWVyZ2Vk IGFzIGFwcHJvcHJpYXRlKSwgc28gYWxpYXMtbmFtZSBpcyBub3QgZm9yd2FyZGVkIG9uIHRvIFNl cnZlciDigJMganVzdCB0aGUNCiBleHBhbmRlZCBtaXRpZ2F0aW9uIHJlcXVlc3QgaXMgZm9yd2Fy ZGVkPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5iKTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RTIEdXIHVwZGF0ZXMgdGhlIGFsaWFzLW5hbWUgd2l0aCBh IHVuaXF1ZSBhbGlhcy1uYW1lIHRoYXQgaXMgZm9yd2FyZGVkIChhbmQgaGFzIHRvIGRvIHRoZSBz YW1lIHRoaW5nIHdoZW4gdGhlIGFsaWFzLW5hbWUgaXMgY29uZmlndXJlZCBvbiB0aGUgZGF0YSBj aGFubmVsKQ0KIOKAkyB0byBoYW5kbGUgMiBvciBtb3JlIGNsaWVudHMgZGVmaW5pbmcgdGhlIHNh bWUgYWxpYXMtbmFtZSB3aGljaCBoYXZlIGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3M8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmMpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhlIERPVFMgR1cgcmVjb2duaXNlcyB0aGF0IGFsaWFzLW5hbWUgaXMgbm90 IHVuaXF1ZSBhbmQgYWRkcyBpbiDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdIChJIHRoaW5r IEkgcHJlZmVyIHRoaXMg4oCcLWluZm/igJ0gbmFtZSB0byBjbGllbnQtaWQgb3Igb3JpZ2luYWwt Y2xpZW50LWlkDQogYXMg4oCcLWlk4oCdIGlzIHRvbyBjbG9zZWx5ICZuYnNwO2Fzc29jaWF0ZWQg d2l0aCBDbGllbnQgSWRlbnRpdHkgZGVyaXZlZCBmcm9tIHRoZSBET1RTIEdXIENsaWVudCBjZXJ0 aWZpY2F0ZSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+V2UgaGF2ZSBhZ3JlZWQgdGhhdCB3aGVuIGEgY2xpZW50IHJlcXVlc3RzIG1pdGln YXRpb24gc3RhdHVzLCB0aGUg4oCcYWxpYXMtbmFtZeKAnSBzaG91bGQgYmUgcmV0dXJuZWQgYXMg 4oCcYWxpYXMtbmFtZeKAnSBhbmQgbm90IHRoZSBzdWJzdGl0dXRlZCBhbGlhcy1uYW1lDQogY29u ZmlndXJhdGlvbiAodGhpcyBkb2VzIG5lZWQgdG8gYmUgc3RhdGVkIGluIHRoZSBzcGVjIGZvciBj bGFyaXR5KS4mbmJzcDsgVGhpcyBtYWtlcyAoYSkgZGlmZmljdWx0IHRvIGJlIGhhbmRsZWQgYnkg RE9UUyBHVyB3aGljaCB0aGVuIHJhaXNlcyB0aGUgcXVlc3Rpb24g4oCTIGRvIHdlIHJlYWxseSBu ZWVkIGFsaWFzLW5hbWU/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZGVmaW5pdGlvbiBhbmQgYXNzb2NpYXRpb24gb2Yg QUNMcy9GaWx0ZXJzIG9mIHRoZSBkYXRhIGNoYW5uZWwgaXMgbW9yZSBkaWZmaWN1bHQg4oCTIHRo ZSBTZXJ2ZXIgbXVzdCBpbnN0YWxsIC8gYXBwbHkgdGhlIGFwcHJvcHJpYXRlIEFDTHMgb24gYQ0K IHBlciAoT3JpZ2luYWwpIENsaWVudCBiYXNpcyB3aGVuIG1pdGlnYXRpb24gaXMgaW52b2tlZC48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Q2xpZW50IDHigJlzIGNvbmNlcHQgb2YgYSBXaGl0ZWxpc3QgSVAgY291bGQgYmUgQ2xpZW50IDLi gJlzIGNvbmNlcHQgb2YgYSBCbGFja2xpc3QgSVAuJm5ic3A7IFRoZSBTZXJ2ZXIgbmVlZHMgdG8g a25vdyB3aGljaCBjbGllbnQgaXMgcmVxdWVzdGluZyB0aGUgbWl0aWdhdGlvbg0KIGFuZCBpbnN0 YWxsIHRoZSBjb3JyZWN0IEFDTHMg4oCTIGlmIHRoZXJlIHdhcyBubyDigJ1hZGRpdGlvbmFsLWNs aWVudC1pbmZv4oCdLCB0aGUgU2VydmVyIG9ubHkga25vd3MgdGhhdCBoZSBoYXMgdG8gaW5zdGFs bCBBTEwgb2YgdGhlIEFDTHMgKGkuZS4gYm90aCB0aGUgQmxhY2sgYW5kIFdoaXRlIGxpc3Qgb2Yg dGhlIHNhbWUgSVAgYXMgZGVmaW5lZCBieSBDbGllbnQgMSBhbmQgQ2xpZW50IDIpIGFzIGRlZmlu ZWQgYnkgaGlzIGNsaWVudCAoRE9UUyBHVykNCiB3aGVuIGhpcyBjbGllbnQgcmVxdWVzdHMgYSBt aXRpZ2F0aW9uLiZuYnNwOyBIZXJlLCBJIHRoaW5rIHRoYXQgaWYgdGhlcmUgaXMgbW9yZSB0aGFu IG9uZSBjbGllbnQgZm9yIHRoZSBET1RTIEdXLCDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCd IGlzIHJlcXVpcmVkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9uPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+ IERvdHMgW21haWx0bzoNCjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRv dHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZg0KPC9iPktvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHk8YnI+DQo8Yj5TZW50OjwvYj4gMDcgT2N0b2JlciAyMDE3IDA0OjI4PGJy Pg0KPGI+VG86PC9iPiBKb24gU2hhbGxvdzsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Ow0KPGEgaHJl Zj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmlu czxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdl czwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JbiBjYXNlIG9mIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgd2h5 IGRvZXMgdGhlIERPVFMgc2VydmVyIG5lZWQgdG8ga25vdyB3aGljaCDigJxET1RTIGNsaWVudOKA nSBoYXMgY29udmV5ZWQgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCA/PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgZXhhbXBsZSwgdGhlIERPVFMgY2xpZW50IGNv dWxkIGJlIGEgRERvUyBkZXRlY3RvciBvciBhbiBBcHBsaWNhdGlvbiBzZXJ2ZXIsIGFuZCB0aGUg Y2xpZW50LXNpZGUgZ2F0ZXdheSB3aWxsIGhhdmUgdG8gcmVzb2x2ZSB0aGUgY29uZmxpY3Rpbmcg bWl0aWdhdGlvbiByZXF1ZXN0cw0KIGZyb20gdGhlIERPVFMgY2xpZW50cywgYWdncmVnYXRlIHRo ZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50IGFuZCBzZW5kIHRoZSB1 cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi1UaXJ1PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBKb24gU2hhbGxvdyBbPGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5j b20iPm1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIE9jdG9iZXIgNiwgMjAxNyA3OjQyIFBNPGJyPg0KPGI+VG86PC9iPiBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDs8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbSI+VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTwv YT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRm Lm9yZyI+DQpkb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnMgJmx0OzxhIGhyZWY9Im1h aWx0bzpyZG9iYmluc0BhcmJvci5uZXQiPnJkb2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgVGlydSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlVubGVzcyBJIGFtIG1pc3Np bmcgc29tZXRoaW5nLCBob3cgZG9lcyB0aGUgQ2xpZW50IHNpZGUgb2YgRE9UUyBHVyBjb252ZXkg dG8gdGhlIHVwc3RyZWFtIHNlcnZlciBhIHVuaXF1ZSDigJxjbGllbnQtaWTigJ0gd2hpY2ggaXMg ZGlmZmVyZW50IHRvIHRoZSBpbXBsaWVkDQogY2xpZW50IGlkIGFzIGRlcml2ZWQgZnJvbSB0aGUg UEtJIGNlcnRpZmljYXRlIHRoYXQgdGhlIERPVFMgR1figJlDbGllbnQgdXNlcy9wcmVzZW50cyB3 aGVuIGNvbW11bmljYXRpbmcgdG8gdGhlIHNlcnZlcj88L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG8gbWUsIHRoZXJlIG5lZWRzIHRvIGJl IGFuIG9wdGlvbiBzdWNoIGFzIOKAnG9yaWdpbmFsLWNsaWVudC1pZOKAnSBvciDigJxjbGllbnQt aWTigJ0gKHdoaWNoIGlzIGNvbmZ1c2luZyB3aGVuIGFsc28gcmVmZXJyaW5nIHRvIHRoZSBjbGll bnQgaWRlbnRpdHkgYXMNCiBkZXJpdmVkIGZyb20gdGhlIChET1RTIEdXKSBDbGllbnTigJlzIFBL SSBjZXJ0aWZpY2F0ZSkgYXMgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbC48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUg dGhhdCB0aGUgRE9UUyBHVyBjYW4gZ2VuZXJhdGUgaXRzIG93biB1bmlxdWUgY2xpZW50LWlkIHRv IHN0b3AgbXVsdGlwbGUgZW50cmllcyBiZWluZyBuZWVkZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQg aXMgbm90IGEgZ29vZCB0aGluZyB0byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1hdGlv biB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR1csIHNvIG15IFJFUVVJUkVEIGRvZXMgbm90 IG1ha2Ugc2Vuc2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Kb248L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UFMg4oCTIEkgYW0gaGF2aW5n IHRvIGRlYWwgd2l0aCBvdGhlciBzdHVmZiBhdCBwcmVzZW50IOKAkyBJIHdpbGwgZ2V0IGJhY2sg bGF0ZXIgb24gdGhlIG90aGVyIGlzc3VlcyB1bmRlciBkaXNjdXNzaW9uPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp ZiI+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgW21haWx0bzoNCjxhIGhyZWY9Im1haWx0bzpU aXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBtY2FmZWUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwNiBPY3RvYmVyIDIwMTcgMTQ6 NTg8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgSm9uIFNoYWxsb3c7ICdE b2JiaW5zLCBSb2xhbmQnOw0KPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBD aGFsbGVuZ2VzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBzZWUgYSBuZWVkIGZvciBjbGllbnQt c2lkZSBET1RTIGdhdGV3YXkgdG8gY29udmV5IHRoZSDigJxET1RTIGNsaWVudCBpZGVudGl0eeKA nSB0byB0aGUgRE9UUyBzZXJ2ZXIuIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIGxvb2tzIHJl cXVpcmVkIG9ubHkgZm9yIHRoZSBzZXJ2ZXItc2lkZQ0KIERPVFMgZ2F0ZXdheXMuIEluIGNhc2Ug b2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBjYW4gY29udmV5IHRoZSBjbGllbnQtaWQg Z2VuZXJhdGVkIGZyb20gdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RT IHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdheSBjYW4gZ2VuZXJhdGUgYSB1bmlxdWUgY2xpZW50LWlk IGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNlbmQgYW4gYXJyYXkgb2YgY2xpZW50LWlkcyB0byB0aGUg RE9UUyBzZXJ2ZXINCiB0byByZXNvbHZlIGNsYXNoZXMuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4tVGlydTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLUdCIj5Eb3RzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5v cmciPkRvdHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLUdCIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RvdHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90czwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB1788CBCF3F6ADCED2D28FEBFEA750DM5PR16MB1788namp_-- From nobody Tue Oct 10 12:14:03 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E7B1346E0 for ; Tue, 10 Oct 2017 12:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENRaElHzjLww for ; Tue, 10 Oct 2017 12:13:56 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 1529D1346DE for ; Tue, 10 Oct 2017 12:13:56 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e1zyS-0003Tw-Q9; Tue, 10 Oct 2017 20:13:52 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "kaname nishizuka" , , , "Roland Dobbins" References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> <0df701d341d5 $cfd88770$6f89 9650$@jpshallow.com> <0e3501d341da$cf9e4b50$6edae1f0$@jpshallow.com> In-Reply-To: Date: Tue, 10 Oct 2017 20:13:54 +0100 Message-ID: <0e7b01d341fb$ea576870$bf063950$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E7C_01D34204.4C203D40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgJ5m8TuAlmBYqEBmF6SwQIo2FEXAknZl2kCYMXrIAJQ6kjUASRe9X8Bri7ZGgMYlBpaAoe6cxMBVc+iCQKRB52aAQ1mQBsCgZLhxwGTsEpCAaZ2QR8B9fzEPwIf+xIXogwLWzA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 19:14:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E7C_01D34204.4C203D40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 I agree that any conflicting request need to be sorted out by the = respective DOTS server component =E2=80=93 SIG-009 - especially if there = are conflicts over IP addresses in the mitigation requests. If (c1) and = (c11) whether using alias-name or not do a mitigation request and this = create a mitigation conflict, then (s1) needs to sort it out. =20 However aliases are set up by the data channel and potentially used by = the signal channel at a later time. =20 So, if (c1) and (c11) have different client identities, then in my = thinking (perhaps naively) that a setup of =E2=80=9Calias-1=E2=80=9D by = (c1) followed later by (c11) also defining the identical alias-name = =E2=80=9Calias-1=E2=80=9D then the alias-names are treated differently = by (s1) as it can separately associate =E2=80=9Calias-1=E2=80=9D with = the correct (c1) or (c11). As (c1n) could be a large number when = scaling out, there is an increased chance of 2 or more of the clients at = the (c1) level choosing the same alias-name. =20 [When the mitigation requests come in from (c1) and (c11), using their = appropriate alias-name and there is a conflict when the mitigation = request is expanded out =E2=80=93 this has to be sorted out by (s1). = However, I am assuming there is not a conflict in the expanded = mitigation request] =20 (s1) can handle this by the association of the alias-names with the = appropriate (c1n) identity. =20 Or are you saying that (s1) has to reject all duplicate alias-names = =E2=80=93 even though they are coming from different (c1n) entities? - this does not scale for me - (c11) =E2=80=93 goes Huh?!? =E2=80=93 I have not previously defined = this. What is broken here? =20 Assuming my understanding is correct that the (s1) can differentiate = between alias-names used by different (c1n) clients, when (c2) passes = the =E2=80=9Calias-1=E2=80=9D name upstream without any =E2=80=9Cextra = (c1n info)=E2=80=9D information to (s2), (s2) will reject the duplicate = ((c2) has passed on the data channel request from (c1) and (c11)) which = (c2) then sees and then has to tell (c11) =E2=80=98Your request to = define =E2=80=9Calias-1=E2=80=9D failed as it is already = defined=E2=80=99. So again, (c11) =E2=80=93 goes Huh?!? =E2=80=93 I = have not previously defined this. =20 I=E2=80=99m missing the point as to why you are concerned about adding = in this extra information between (c2) and (s2) =E2=80=93 we have plenty = of space in the UDP packet =E2=80=93 CBOR mapping has done a good data = reduction job. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 16:59 To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi Jon, =20 The role of s1 is much more than just forwarding the DOTS client = messages, please see (SIG-009 in the requirements drafts), if a DOTS = client has used the same alias name previously conveyed by another = client then s1 must reject the request. If conflicting requests are = resolved by s1 then any response message sent by s3 will be forwarded by = s1 to the right DOTS client. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 8:47 PM To: Konda, Tirumaleswar Reddy ; = kaname nishizuka ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Then that breaks a signal GET for mitigation status from (c1) = (mitigation request uses alias-name) =E2=80=93 what gets sent back in = the alias-name field when the response that is sent by (s3) when it gets = to (c1)? =20 I thought we had agreed to leave the alias name =E2=80=93 as is = =E2=80=93 (not substituted) in what is sent back to (c1) from (s1). =20 (c1) is not particularly interested in how (c11) is getting mitigated = and probably does not want (c11) stats added into his =E2=80=93 (s3) = need to know how to differentiate between (c1) and (c11) =E2=80=93 which = is easily done if (c1) (or (c11) information is passed up to (s3), = starting with (s1). =20 This whole thing needs to be scalable, and I am struggling with how to = actually implement your proposal. Allowing each DOTS GW to learn and = pass on something extra that differentiates the DOTS GW immediate = clients makes the implementation relatively easy. There is no need for = a DOTS GW to add in additional information if extra information is = already embedded =E2=80=93 unless he sees a name clash from 2 or more of = his uniquely identified DOTS clients =E2=80=93 which will be different = entities anyway. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 15:52 To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 The conflicting alias-names from DOTS client (c1) and another client = (let=E2=80=99 call (c11)) behind (s1) should be resolved by s1 itself, = it is also the responsibility of (s1) to resolve conflicting mitigation = requests from (c1) and (c11), aggregate the mitigation requests from the = DOTS clients (c1 and c11) and send the updated mitigation request (c2). =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 8:11 PM To: Konda, Tirumaleswar Reddy ; = kaname nishizuka ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 I agree in part, but we need to look at the end (c1) to end (s3) = potential issues. What you are proposing works fine for (s2) to (s3). =20 (c1) requests mitigation with an alias-name =E2=80=9Calias-1=E2=80=9D. = If (s1) does not pass anything extra to (c2) for onward transmission, = (s2) sees a single client (c2) requesting mitigation with alias-name = =E2=80=9Calias-1=E2=80=9D. Fine, that works. If there was another DOTS client in the same location as (c1)(i.e. = c1diff), both using (s1) who also decided to use alias-name = =E2=80=9Calias-1=E2=80=9D who then requests mitigation, (s2) has no idea = that there are different =E2=80=9Calias-1=E2=80=9D definitions if (c2) = does not send also an extra differentiator.=20 =20 So, any DOTS GW in the chain should be passing on a = =E2=80=9Cunique-extra=E2=80=9D piece of information. =20 Regards =20 Jon=20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 15:15 To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Agree with your response, consider a deployment which has the following = DOTS agents. =20 DOTS clients (c1) =C3=9F----------------=C3=A0 (s1) client-side DOTS = gateway (c2) =C3=9F------------=C3=A0 (s2) server-side DOTS gateway (c3) = =C3=9F----------=C3=A0 (s3) DOTS server =20 My point is, (c2) need not convey the =E2=80=9Cc1 identity=E2=80=9D to = (s2) but (s2) needs to convey the =E2=80=9Cc2 identity=E2=80=9D to (c3) = and (c3) in-turn propagates the =E2=80=9Cc2 identity=E2=80=9D to (s3). =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 6:15 PM To: Konda, Tirumaleswar Reddy ; = kaname nishizuka ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Agreed that only a DOTS GW server facing needs to send information to = the upstream DOTS Server =E2=80=93 which could also be a DOTS GW. +-------------+ | | D | | +----+ | | O | | +----+ | c1 |----------| s1 | T | c2 |---------| s2 | +----+ | | S | | +----+ | | G | | +-------------+ https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-2.2.3= =20 However, the DOTS GW client facing (s1) is the one with knowledge of the = individual clients that are currently using the DOTS server running on = the DOTS GW. This information has to somehow be passed over to the DOTS = GW server facing (c2), but separate DOTS stacks are being run for (s1) = and (c2) as per architecture spec 2.2.3. I was referring to what (s1) = may need to pass on to (c2) in my email response to Kaname, not what is = sent by (c1). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 13:16 To: Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 I thought we agreed that based on the current DOTS requirements only the = server-side DOTS GW needs to convey the DOTS client (or client-side DOTS = WG) identity to the DOTS server.=20 =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 2:53 PM To: 'kaname nishizuka' ; Konda, Tirumaleswar Reddy = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Kaname, =20 I do not think that information necessarily needs to be the original = client identity. The GW Client side will have its own identity which = the DOTS Server can use to differentiate between DOTS (GW) Clients. =20 So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash collisions. Or = it could be a simple list such as C1, C2 =E2=80=A6Cn. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 10 October 2017 04:19 To: Konda, Tirumaleswar Reddy; Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi, > I agree the below problems are applicable for server-side DOTS = gateway, it must convey the =E2=80=9Cclient identity=E2=80=9D to the = DOTS server.=20 I agree with this server-side DOTS gateway case. At the same time, I agree with below: > I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW,=20 Then, should DOTS GW send =E2=80=9Cclient identity=E2=80=9D (i.e. = certificates of DOTS clients) itself or hashed(=E2=80=9Cclient = identity=E2=80=9D) to DOTS server? If later, how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient identity=E2=80=9D). regards, Kaname On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote: Hi Jon, =20 I agree the below problems are applicable for server-side DOTS gateway, = it must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. = But for the client-side DOTS gateway, it should resolve conflicting = rules b/w DOTS clients (e.g. one client installing black-list ACL for an = IP address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:07 PM To: Konda, Tirumaleswar Reddy = = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds = in =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0E7C_01D34204.4C203D40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I agree that any conflicting request need to be sorted out by the = respective DOTS server component =E2=80=93 SIG-009 - especially if there = are conflicts over IP addresses in the mitigation requests. If (c1) and = (c11) whether using alias-name or not do a mitigation request and this = create a mitigation conflict, then (s1) needs to sort it = out.

 

However aliases are set up by the data channel and potentially used = by the signal channel at a later time.

 

So, if (c1) and (c11) have different client identities, then in my = thinking (perhaps naively) that a setup of =E2=80=9Calias-1=E2=80=9D by = (c1) followed later by (c11) also defining the identical alias-name = =E2=80=9Calias-1=E2=80=9D then the alias-names are treated differently = by (s1) as it can separately associate =E2=80=9Calias-1=E2=80=9D with = the correct (c1) or (c11).=C2=A0 As (c1n) could be a large number when = scaling out, there is an increased chance of 2 or more of the clients at = the (c1) level choosing the same alias-name.

 

[When the mitigation requests come in from (c1) and (c11), using = their appropriate alias-name and there is a conflict when the mitigation = request is expanded out =E2=80=93 this has to be sorted out by = (s1).=C2=A0 However, I am assuming there is not a conflict in the = expanded mitigation request]

 

(s1) can handle this by the association of the alias-names with the = appropriate (c1n) identity.

 

Or are you saying that (s1) has to reject all duplicate alias-names = =E2=80=93 even though they are coming from different (c1n) = entities?

- this does not scale for me

- (c11) =E2=80=93 goes Huh?!? =E2=80=93 I have not previously defined = this. What is broken here?

 

Assuming my understanding is correct that the (s1)=C2=A0 can = differentiate between alias-names used by different (c1n) clients, when = (c2) passes the =E2=80=9Calias-1=E2=80=9D name upstream without any = =E2=80=9Cextra (c1n info)=E2=80=9D information to (s2), (s2) will reject = the duplicate ((c2) has passed on the data channel request from (c1) and = (c11)) which (c2) then sees and then has to tell (c11) =E2=80=98Your = request to define =E2=80=9Calias-1=E2=80=9D failed as it is already = defined=E2=80=99. =C2=A0So again, (c11) =E2=80=93 goes Huh?!? =E2=80=93 = I have not previously defined this.

 

I=E2=80=99m missing the point as to why you are concerned about = adding in this extra information between (c2) and (s2) =E2=80=93 we have = plenty of space in the UDP packet =E2=80=93 CBOR mapping has done a good = data reduction job.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy
Sent: 10 October 2017 16:59
To: = Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS = Gateways Challenges

 

Hi Jon,

 

The role of s1 is much more than just forwarding the DOTS client = messages, please see (SIG-009 in the requirements drafts), if a DOTS = client has used the same alias name previously conveyed by another = client then s1 must reject the request. If conflicting requests are = resolved by s1 then any response message sent by s3 will be forwarded by = s1 to the right DOTS client.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 8:47 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Then that breaks a signal GET for mitigation status from (c1) = (mitigation request uses alias-name) =E2=80=93 what gets sent back in = the alias-name field when the response that is sent by (s3) when it gets = to (c1)?

 

I thought we had agreed to leave the alias name =E2=80=93 as is = =E2=80=93 (not substituted) in what is sent back to (c1) from = (s1).

 

(c1) is not particularly interested in how (c11) is getting mitigated = and probably does not want (c11) stats added into his =E2=80=93 (s3) = need to know how to differentiate between (c1) and (c11) =E2=80=93 which = is easily done if (c1) (or (c11) information is passed up to (s3), = starting with (s1).

 

This whole thing needs to be scalable, and I am struggling with how = to actually implement your proposal.  Allowing each DOTS GW to = learn and pass on something extra that differentiates the DOTS GW = immediate clients makes the implementation relatively easy.  There = is no need for a DOTS GW to add in additional information if extra = information is already embedded =E2=80=93 unless he sees a name clash = from 2 or more of his uniquely identified DOTS clients =E2=80=93 which = will be different entities anyway.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 15:52
To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

The conflicting alias-names from DOTS client (c1) and another = client (let=E2=80=99 call (c11)) behind (s1) should be resolved by s1 = itself, it is also the responsibility of (s1) to resolve conflicting = mitigation requests from (c1) and (c11), aggregate = the mitigation requests from the DOTS clients (c1 and c11) and send the = updated mitigation request (c2).

 =

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 8:11 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

I agree in part, but we need to look at the end (c1) to end (s3) = potential issues.  What you are proposing works fine for (s2) to = (s3).

 

(c1) requests mitigation with an alias-name = =E2=80=9Calias-1=E2=80=9D.  If (s1) does not pass anything extra to = (c2) for onward transmission, (s2) sees a single client (c2) requesting = mitigation with alias-name =E2=80=9Calias-1=E2=80=9D.  Fine, that = works.

If there was another DOTS client in the same location as (c1)(i.e. = c1diff), both using (s1) who also decided to use alias-name = =E2=80=9Calias-1=E2=80=9D who then requests mitigation, (s2) has no idea = that there are different =E2=80=9Calias-1=E2=80=9D definitions if (c2) = does not send also an extra differentiator.

 

So, any DOTS GW in the chain should be passing on a = =E2=80=9Cunique-extra=E2=80=9D piece of = information.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 15:15
To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Agree with your response, consider a deployment which has the = following DOTS agents.

 

DOTS clients (c1) =C3=9F<= /span>----------------=C3=A0<= /span> (s1) client-side DOTS gateway (c2) =C3=9F<= /span>------------=C3=A0<= /span> (s2) server-side DOTS gateway (c3) =C3=9F<= /span>----------=C3=A0<= /span> (s3) DOTS server

 

My point is, (c2) need not convey the =E2=80=9Cc1 = identity=E2=80=9D to (s2) but (s2) needs to convey the =E2=80=9Cc2 = identity=E2=80=9D to (c3) and (c3) in-turn propagates the =E2=80=9Cc2 = identity=E2=80=9D to (s3).

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 6:15 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Agreed that only a DOTS GW server facing needs to send information to = the upstream DOTS Server =E2=80=93 which could also be a DOTS = GW.

  =             &= nbsp;          +-------= ------+

          = ;            =    |    | D |    = |

         = +----+          = |    | O |    = |         = +----+

         | c1 = |----------| s1 | T | c2 |---------| s2 |

         = +----+     =      |    | S = |    |         = +----+

          = ;            =    |    | G |    = |

          = ;            =    +-------------+

https://tools.ietf.org/html/draft-ietf-dots-architecture-04#sec= tion-2.2.3

 

However, the DOTS GW client facing (s1) is the one with knowledge of = the individual clients that are currently using  the DOTS server = running on the DOTS GW.  This information has to somehow be passed = over to the DOTS GW server facing (c2), but separate DOTS stacks are = being run for (s1) and (c2) as per architecture spec 2.2.3.  I was = referring to what (s1) may need to pass on to (c2) in my email response = to Kaname, not what is sent by (c1).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 13:16
To: Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

I thought we agreed that based on the current DOTS requirements = only the server-side DOTS GW needs to convey the DOTS client (or = client-side DOTS WG) identity to the DOTS server. =

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 2:53 PM
To: = 'kaname nishizuka' <kaname@nttv6.jp>; Konda, = Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Kaname,

 

I do not think that information necessarily needs to be the original = client identity.  The GW Client side will have its own identity = which the DOTS Server can use to differentiate between DOTS (GW) = Clients.

 

So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash = collisions.  Or it could be a simple list such as C1, C2 = =E2=80=A6Cn.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of kaname nishizuka
Sent: 10 October 2017 = 04:19
To: Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi,

> I agree the below = problems are applicable for server-side DOTS gateway, it must convey the = =E2=80=9Cclient identity=E2=80=9D to the DOTS server.
I agree with = this server-side DOTS gateway case.
At the same time, I agree with = below:
> I agree that is not a good thing to = =E2=80=9Cleak=E2=80=9D out internal information when passing through a = DOTS GW,

Then, should DOTS GW send =E2=80=9Cclient = identity=E2=80=9D (i.e. certificates of DOTS clients) itself or = hashed(=E2=80=9Cclient identity=E2=80=9D) to DOTS server?
If later, = how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient = identity=E2=80=9D).

regards,
Kaname

On 2017/10/09 22:34, Konda, Tirumaleswar Reddy = wrote:

Hi = Jon,

 

I agree = the below problems are applicable for server-side DOTS gateway, it must = convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. But for = the client-side DOTS gateway, it should resolve conflicting rules b/w = DOTS clients (e.g. one client installing black-list ACL for an IP = address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, October 7, 2017 2:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_= Konda@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
S= ubject: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client.  =

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)     &nb= sp; The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)      = The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)     &nb= sp; The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely  associated with Client = Identity derived from the DOTS GW Client = certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).  This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.  The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.  Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= = Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:28
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, October 6, 2017 7:42 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= = Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 06 October 2017 14:58
To: = mohamed.boucadair@orange.com= ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: = [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 

-Tiru

 

________________=
_______________________________
Dots mailing =
list
Dots@ietf.org
https://www.ietf.org/=
mailman/listinfo/dots

 

------=_NextPart_000_0E7C_01D34204.4C203D40-- From nobody Tue Oct 10 21:38:52 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69107134483 for ; Tue, 10 Oct 2017 21:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.99 X-Spam-Level: X-Spam-Status: No, score=-6.99 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_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 sag8QE3IAewR for ; Tue, 10 Oct 2017 21:38:46 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 1F82E132D8A for ; Tue, 10 Oct 2017 21:38:45 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507696725; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=F xZe/SxIVY0TngqdRgJb6aUVMOec8C/572W79K8/D7 Y=; b=XKuH3Eb5KYJk87vOH3Ho9qr38fHl61z7cJea4KJqonSe mVfQUWbxCZ9UvxRKiWIPIZqUw5E9dLWYs5rHdlLv22L3BnMKHL ++lQrSLKJUQ+Ly014q/7eOcJpNDsxfmS5PvmKzceU2Cxtl6jyh aN7f0fD26G384Gk6KM8QbBAnWrg= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 0843_07eb_a0fb0e5a_328b_4124_a4ac_74b8f25e8cb6; Tue, 10 Oct 2017 23:38:43 -0500 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 11 Oct 2017 00:38:42 -0400 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 11 Oct 2017 00:38:40 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 11 Oct 2017 00:38:40 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 11 Oct 2017 00:38:40 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 11 Oct 2017 04:38:38 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Wed, 11 Oct 2017 04:38:38 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , kaname nishizuka , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAACzkMAABuu0fgAB0EBwAADL1rgAAF4fWwAAEncgAAAJP24AADfJaAAAAklGAAARtaAAAA3fKAAAdoswAADm/p4A== Date: Wed, 11 Oct 2017 04:38:38 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <76EE4654-4F7E-4DAD-82F9-B92F5C51360A@arbor.net> <075e01d33daf$b1f87e60$15e97b20$@jpshallow.com> <4A4C5D6A-B63F-40B4-8772-AD0B1E79F8D6@arbor.net> <07e201d33dce$09984dd0$1cc8e970$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0503FF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <091f01d33ead$07ec7e40$17c57ac0$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> <0df701d341d5$cfd88770$6f89 9650$@jpshallow.com> <0e3501d341da$cf9e4b50$6edae1f0$@jpshallow.com> <0e7b01d341fb$ea576870$bf063950$@jpshallow.com> In-Reply-To: <0e7b01d341fb$ea576870$bf063950$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:SFj58Z9z14g1QAPyK+FZ6+McV3SB5x46qJo1LzWuPZr5pnjICXlsY8tByIo94LLzQ6b7JwPhDWzGp7k04OfeXw1pOAfIjztYUlIp8YNKYrm8IkmmFtCyyRlXs+gyh3tM6ctCGE6QgyC/muoKVhTQpvrFtGVJNHBguMUnOTuN6i7Xe56NHn3rKoOUj2rkP8d2equkbCTJEl0HEOLYRlCE9Ic1dE/xgXcmcnn9t1uNZhk+91Ud2YLdg8E5lYY4SfwAUhMBWvBRp3WTF0ifc1ivt6hg3rZcwd8bTxYle7CM4MbcIpC375DHrteFmWw+84/5k83cVY6Qr5zbux5Pk72b/w==; 5:PzkIvSv+kW3l65sCb8TJZtRRdZEriDLTKh9fQOBeKFdgL+mr6wIW6TXATaGZ+AWsgglS79Q5cHlypsDO5H8bxhRP0WhffYcgZNIX42LymWvLmxjRMv4h0NYKNMuQUFy9kRoklnl8WZXE/yjeBh2Mmg==; 24:0RM/8xpxVKSIXaxcJV3EPH5rzPMew3BwvMA3vNbvWejfkcKXZkZfnbqHtiz1lSFZmSlYbuoH7pPe5I5ZAxS0KApGFU1AObmLGGoExHHEAVw=; 7:Ebry7bJccOC9VMXWF1OnPS+r46rbmJMsS7uOrEYIaAe6wmwtOBgzz0UxiXmyqBtcih0wwUji9+CATAxApn3A/zt0NhvsEKRm1E+Xf+jU02H+rFNogfPufV7iqn5SagZIREECEGnOKc9y+wgvDvMPo1+PucsJplNlrV7vxm5AB0zY7VX5sLfbsFa93Ys4Y9MIz1Ulr55gu7KgSdJvYtNkzAUybNay7qhlYVhbFX1KKdo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e2214109-c677-49e8-c557-08d51061f0fb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0457F11EAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(199003)(32952001)(189002)(51444003)(24454002)(377454003)(9686003)(9326002)(2201001)(229853002)(236005)(2950100002)(54896002)(6306002)(316002)(53936002)(66066001)(5660300001)(93886005)(7736002)(74316002)(2501003)(3660700001)(3280700002)(2906002)(7696004)(110136005)(6246003)(97736004)(80792005)(86362001)(55016002)(99286003)(68736007)(53946003)(189998001)(6436002)(14454004)(6506006)(25786009)(54356999)(50986999)(76176999)(478600001)(53546010)(106356001)(2900100001)(8936002)(101416001)(77096006)(102836003)(6116002)(790700001)(3846002)(33656002)(105586002)(561944003)(81156014)(72206003)(8676002)(606006)(81166006)(966005)(85282002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17881D83FE54C764512676ACEA4A0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2017 04:38:38.2134 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6133> : inlines <6121> : streams <1766741> : uri <2514616> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 04:38:50 -0000 --_000_DM5PR16MB17881D83FE54C764512676ACEA4A0DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uLA0KDQpQbGVhc2Ugc2VlIGlubGluZQ0KDQpGcm9tOiBKb24gU2hhbGxvdyBbbWFpbHRv OnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTEs IDIwMTcgMTI6NDQgQU0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsga2FuYW1lIG5pc2hpenVrYSA8a2FuYW1lQG50dHY2 LmpwPjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgZG90c0BpZXRmLm9yZzsgUm9sYW5k IERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyBH YXRld2F5cyBDaGFsbGVuZ2VzDQoNCkhpIFRpcnUsDQoNCkkgYWdyZWUgdGhhdCBhbnkgY29uZmxp Y3RpbmcgcmVxdWVzdCBuZWVkIHRvIGJlIHNvcnRlZCBvdXQgYnkgdGhlIHJlc3BlY3RpdmUgRE9U UyBzZXJ2ZXIgY29tcG9uZW50IOKAkyBTSUctMDA5IC0gZXNwZWNpYWxseSBpZiB0aGVyZSBhcmUg Y29uZmxpY3RzIG92ZXIgSVAgYWRkcmVzc2VzIGluIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3RzLiBJ ZiAoYzEpIGFuZCAoYzExKSB3aGV0aGVyIHVzaW5nIGFsaWFzLW5hbWUgb3Igbm90IGRvIGEgbWl0 aWdhdGlvbiByZXF1ZXN0IGFuZCB0aGlzIGNyZWF0ZSBhIG1pdGlnYXRpb24gY29uZmxpY3QsIHRo ZW4gKHMxKSBuZWVkcyB0byBzb3J0IGl0IG91dC4NCg0KSG93ZXZlciBhbGlhc2VzIGFyZSBzZXQg dXAgYnkgdGhlIGRhdGEgY2hhbm5lbCBhbmQgcG90ZW50aWFsbHkgdXNlZCBieSB0aGUgc2lnbmFs IGNoYW5uZWwgYXQgYSBsYXRlciB0aW1lLg0KDQpTbywgaWYgKGMxKSBhbmQgKGMxMSkgaGF2ZSBk aWZmZXJlbnQgY2xpZW50IGlkZW50aXRpZXMsIHRoZW4gaW4gbXkgdGhpbmtpbmcgKHBlcmhhcHMg bmFpdmVseSkgdGhhdCBhIHNldHVwIG9mIOKAnGFsaWFzLTHigJ0gYnkgKGMxKSBmb2xsb3dlZCBs YXRlciBieSAoYzExKSBhbHNvIGRlZmluaW5nIHRoZSBpZGVudGljYWwgYWxpYXMtbmFtZSDigJxh bGlhcy0x4oCdIHRoZW4gdGhlIGFsaWFzLW5hbWVzIGFyZSB0cmVhdGVkIGRpZmZlcmVudGx5IGJ5 IChzMSkgYXMgaXQgY2FuIHNlcGFyYXRlbHkgYXNzb2NpYXRlIOKAnGFsaWFzLTHigJ0gd2l0aCB0 aGUgY29ycmVjdCAoYzEpIG9yIChjMTEpLiAgQXMgKGMxbikgY291bGQgYmUgYSBsYXJnZSBudW1i ZXIgd2hlbiBzY2FsaW5nIG91dCwgdGhlcmUgaXMgYW4gaW5jcmVhc2VkIGNoYW5jZSBvZiAyIG9y IG1vcmUgb2YgdGhlIGNsaWVudHMgYXQgdGhlIChjMSkgbGV2ZWwgY2hvb3NpbmcgdGhlIHNhbWUg YWxpYXMtbmFtZS4NCg0KW1RSXSBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgd2lsbCBiZSBhIGxhcmdl IG51bWJlciBvZiBET1RTIGNsaWVudHMgaW4gYSBkb21haW4sIHR5cGljYWxseSBhIEREb1MgbWl0 aWdhdGlvbiBzeXN0ZW0gb3IgRERvUyBkZXRlY3RvciBpbiBhIGRvbWFpbiB3aWxsIGFjdCBhcyBE T1RTIGNsaWVudHMgKGFuZCBpbiBmdXR1cmUgY29udGVudCBzZXJ2ZXJzIHdpdGggRERvUyBkZXRl Y3Rpb24gY2FwYWJpbGl0eSBjYW4gYWxzbyBhY3QgYXMgRE9UUyBjbGllbnRzKS4NCg0KV2h5IGRv IHlvdSB0aGluayB0aGVyZSB3aWxsIGJlIGxhcmdlIG51bWJlciBvZiBET1RTIGNsaWVudHMgaW4g YSBkb21haW4gPw0KDQpbV2hlbiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0cyBjb21lIGluIGZyb20g KGMxKSBhbmQgKGMxMSksIHVzaW5nIHRoZWlyIGFwcHJvcHJpYXRlIGFsaWFzLW5hbWUgYW5kIHRo ZXJlIGlzIGEgY29uZmxpY3Qgd2hlbiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGV4cGFuZGVk IG91dCDigJMgdGhpcyBoYXMgdG8gYmUgc29ydGVkIG91dCBieSAoczEpLiAgSG93ZXZlciwgSSBh bSBhc3N1bWluZyB0aGVyZSBpcyBub3QgYSBjb25mbGljdCBpbiB0aGUgZXhwYW5kZWQgbWl0aWdh dGlvbiByZXF1ZXN0XQ0KDQooczEpIGNhbiBoYW5kbGUgdGhpcyBieSB0aGUgYXNzb2NpYXRpb24g b2YgdGhlIGFsaWFzLW5hbWVzIHdpdGggdGhlIGFwcHJvcHJpYXRlIChjMW4pIGlkZW50aXR5Lg0K DQpPciBhcmUgeW91IHNheWluZyB0aGF0IChzMSkgaGFzIHRvIHJlamVjdCBhbGwgZHVwbGljYXRl IGFsaWFzLW5hbWVzIOKAkyBldmVuIHRob3VnaCB0aGV5IGFyZSBjb21pbmcgZnJvbSBkaWZmZXJl bnQgKGMxbikgZW50aXRpZXM/DQotIHRoaXMgZG9lcyBub3Qgc2NhbGUgZm9yIG1lDQotIChjMTEp IOKAkyBnb2VzIEh1aD8hPyDigJMgSSBoYXZlIG5vdCBwcmV2aW91c2x5IGRlZmluZWQgdGhpcy4g V2hhdCBpcyBicm9rZW4gaGVyZSA/DQoNCltUUl0gYzExIGhhcyB0byByZS10cnkgd2l0aCBhIGRp ZmZlcmVudCBhbGlhcyBuYW1lLCBSRVNUQ09ORiAoYW5kIE5FVENPTkYpIGRlYWxzIHdpdGggdGhp cyBwcm9ibGVtIGJ5IHJldHVybmluZyDigJxkYXRhLWV4aXN0c+KAnSBlcnJvciByZXNwb25zZSAo NDA5IHJlc3BvbnNlIGNvZGUpLg0KDQpBc3N1bWluZyBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJl Y3QgdGhhdCB0aGUgKHMxKSAgY2FuIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBhbGlhcy1uYW1lcyB1 c2VkIGJ5IGRpZmZlcmVudCAoYzFuKSBjbGllbnRzLCB3aGVuIChjMikgcGFzc2VzIHRoZSDigJxh bGlhcy0x4oCdIG5hbWUgdXBzdHJlYW0gd2l0aG91dCBhbnkg4oCcZXh0cmEgKGMxbiBpbmZvKeKA nSBpbmZvcm1hdGlvbiB0byAoczIpLCAoczIpIHdpbGwgcmVqZWN0IHRoZSBkdXBsaWNhdGUgKChj MikgaGFzIHBhc3NlZCBvbiB0aGUgZGF0YSBjaGFubmVsIHJlcXVlc3QgZnJvbSAoYzEpIGFuZCAo YzExKSkgd2hpY2ggKGMyKSB0aGVuIHNlZXMgYW5kIHRoZW4gaGFzIHRvIHRlbGwgKGMxMSkg4oCY WW91ciByZXF1ZXN0IHRvIGRlZmluZSDigJxhbGlhcy0x4oCdIGZhaWxlZCBhcyBpdCBpcyBhbHJl YWR5IGRlZmluZWTigJkuICBTbyBhZ2FpbiwgKGMxMSkg4oCTIGdvZXMgSHVoPyE/IOKAkyBJIGhh dmUgbm90IHByZXZpb3VzbHkgZGVmaW5lZCB0aGlzLg0KDQpJ4oCZbSBtaXNzaW5nIHRoZSBwb2lu dCBhcyB0byB3aHkgeW91IGFyZSBjb25jZXJuZWQgYWJvdXQgYWRkaW5nIGluIHRoaXMgZXh0cmEg aW5mb3JtYXRpb24gYmV0d2VlbiAoYzIpIGFuZCAoczIpIOKAkyB3ZSBoYXZlIHBsZW50eSBvZiBz cGFjZSBpbiB0aGUgVURQIHBhY2tldCDigJMgQ0JPUiBtYXBwaW5nIGhhcyBkb25lIGEgZ29vZCBk YXRhIHJlZHVjdGlvbiBqb2IuDQoNCltUUl0gU3BhY2UgaXMgbm90IGEgcHJvYmxlbSBmb3IgYWRk aW5nIHRoZSBleHRyYSBpbmZvcm1hdGlvbiwgbXkgY29uY2VybiBpcyB0aGUgbmVlZCB0byBjb252 ZXkgdGhlIGV4dHJhIGluZm9ybWF0aW9uIGFuZCBET1RTIGdhdGV3YXkgbm90IGFzc2lzdGluZyB0 byByZXNvbHZlIHRoZSBzYW1lIGFsaWFzLW5hbWUgZnJvbSBkaWZmZXJlbnQgRE9UUyBjbGllbnRz Lg0KDQotVGlydQ0KDQpSZWdhcmRzDQoNCkpvbg0KDQpGcm9tOiBEb3RzIFttYWlsdG86IGRvdHMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxm IE9mIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNClNlbnQ6IDEwIE9jdG9iZXIgMjAxNyAxNjo1 OQ0KVG86IEpvbiBTaGFsbG93OyBrYW5hbWUgbmlzaGl6dWthOyBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRm Lm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zDQpTdWJqZWN0OiBSZTog W0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSBKb24sDQoNClRoZSByb2xlIG9m IHMxIGlzIG11Y2ggbW9yZSB0aGFuIGp1c3QgZm9yd2FyZGluZyB0aGUgRE9UUyBjbGllbnQgbWVz c2FnZXMsIHBsZWFzZSBzZWUgKFNJRy0wMDkgaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdHMpLCBp ZiBhIERPVFMgY2xpZW50IGhhcyB1c2VkIHRoZSBzYW1lIGFsaWFzIG5hbWUgcHJldmlvdXNseSBj b252ZXllZCBieSBhbm90aGVyIGNsaWVudCB0aGVuIHMxIG11c3QgcmVqZWN0IHRoZSByZXF1ZXN0 LiBJZiBjb25mbGljdGluZyByZXF1ZXN0cyBhcmUgcmVzb2x2ZWQgYnkgczEgdGhlbiBhbnkgcmVz cG9uc2UgbWVzc2FnZSBzZW50IGJ5IHMzIHdpbGwgYmUgZm9yd2FyZGVkIGJ5IHMxIHRvIHRoZSBy aWdodCBET1RTIGNsaWVudC4NCg0KLVRpcnUNCg0KRnJvbTogSm9uIFNoYWxsb3cgW21haWx0bzpz dXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMCwgMjAx NyA4OjQ3IFBNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVl LmNvbT4+OyBrYW5hbWUgbmlzaGl6dWthIDxrYW5hbWVAbnR0djYuanA8bWFpbHRvOmthbmFtZUBu dHR2Ni5qcD4+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47 IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9y Lm5ldD4+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpI aSBUaXJ1LA0KDQpUaGVuIHRoYXQgYnJlYWtzIGEgc2lnbmFsIEdFVCBmb3IgbWl0aWdhdGlvbiBz dGF0dXMgZnJvbSAoYzEpIChtaXRpZ2F0aW9uIHJlcXVlc3QgdXNlcyBhbGlhcy1uYW1lKSDigJMg d2hhdCBnZXRzIHNlbnQgYmFjayBpbiB0aGUgYWxpYXMtbmFtZSBmaWVsZCB3aGVuIHRoZSByZXNw b25zZSB0aGF0IGlzIHNlbnQgYnkgKHMzKSB3aGVuIGl0IGdldHMgdG8gKGMxKT8NCg0KSSB0aG91 Z2h0IHdlIGhhZCBhZ3JlZWQgdG8gbGVhdmUgdGhlIGFsaWFzIG5hbWUg4oCTIGFzIGlzIOKAkyAo bm90IHN1YnN0aXR1dGVkKSBpbiB3aGF0IGlzIHNlbnQgYmFjayB0byAoYzEpIGZyb20gKHMxKS4N Cg0KKGMxKSBpcyBub3QgcGFydGljdWxhcmx5IGludGVyZXN0ZWQgaW4gaG93IChjMTEpIGlzIGdl dHRpbmcgbWl0aWdhdGVkIGFuZCBwcm9iYWJseSBkb2VzIG5vdCB3YW50IChjMTEpIHN0YXRzIGFk ZGVkIGludG8gaGlzIOKAkyAoczMpIG5lZWQgdG8ga25vdyBob3cgdG8gZGlmZmVyZW50aWF0ZSBi ZXR3ZWVuIChjMSkgYW5kIChjMTEpIOKAkyB3aGljaCBpcyBlYXNpbHkgZG9uZSBpZiAoYzEpIChv ciAoYzExKSBpbmZvcm1hdGlvbiBpcyBwYXNzZWQgdXAgdG8gKHMzKSwgc3RhcnRpbmcgd2l0aCAo czEpLg0KDQpUaGlzIHdob2xlIHRoaW5nIG5lZWRzIHRvIGJlIHNjYWxhYmxlLCBhbmQgSSBhbSBz dHJ1Z2dsaW5nIHdpdGggaG93IHRvIGFjdHVhbGx5IGltcGxlbWVudCB5b3VyIHByb3Bvc2FsLiAg QWxsb3dpbmcgZWFjaCBET1RTIEdXIHRvIGxlYXJuIGFuZCBwYXNzIG9uIHNvbWV0aGluZyBleHRy YSB0aGF0IGRpZmZlcmVudGlhdGVzIHRoZSBET1RTIEdXIGltbWVkaWF0ZSBjbGllbnRzIG1ha2Vz IHRoZSBpbXBsZW1lbnRhdGlvbiByZWxhdGl2ZWx5IGVhc3kuICBUaGVyZSBpcyBubyBuZWVkIGZv ciBhIERPVFMgR1cgdG8gYWRkIGluIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaWYgZXh0cmEgaW5m b3JtYXRpb24gaXMgYWxyZWFkeSBlbWJlZGRlZCDigJMgdW5sZXNzIGhlIHNlZXMgYSBuYW1lIGNs YXNoIGZyb20gMiBvciBtb3JlIG9mIGhpcyB1bmlxdWVseSBpZGVudGlmaWVkIERPVFMgY2xpZW50 cyDigJMgd2hpY2ggd2lsbCBiZSBkaWZmZXJlbnQgZW50aXRpZXMgYW55d2F5Lg0KDQpSZWdhcmRz DQoNCkpvbg0KDQpGcm9tOiBEb3RzIFttYWlsdG86IGRvdHMtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86ZG90cy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHkNClNlbnQ6IDEwIE9jdG9iZXIgMjAxNyAxNTo1Mg0KVG86IEpvbiBTaGFsbG93OyBr YW5hbWUgbmlzaGl6dWthOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRm Lm9yZz47IFJvbGFuZCBEb2JiaW5zDQpTdWJqZWN0OiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMg Q2hhbGxlbmdlcw0KDQpUaGUgY29uZmxpY3RpbmcgYWxpYXMtbmFtZXMgZnJvbSBET1RTIGNsaWVu dCAoYzEpIGFuZCBhbm90aGVyIGNsaWVudCAobGV04oCZIGNhbGwgKGMxMSkpIGJlaGluZCAoczEp IHNob3VsZCBiZSByZXNvbHZlZCBieSBzMSBpdHNlbGYsIGl0IGlzIGFsc28gdGhlIHJlc3BvbnNp YmlsaXR5IG9mIChzMSkgdG8gcmVzb2x2ZSBjb25mbGljdGluZyBtaXRpZ2F0aW9uIHJlcXVlc3Rz IGZyb20gKGMxKSBhbmQgKGMxMSksIGFnZ3JlZ2F0ZSB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0cyBm cm9tIHRoZSBET1RTIGNsaWVudHMgKGMxIGFuZCBjMTEpIGFuZCBzZW5kIHRoZSB1cGRhdGVkIG1p dGlnYXRpb24gcmVxdWVzdCAoYzIpLg0KDQotVGlydQ0KDQpGcm9tOiBKb24gU2hhbGxvdyBbbWFp bHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDEw LCAyMDE3IDg6MTEgUE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBN Y0FmZWUuY29tPj47IGthbmFtZSBuaXNoaXp1a2EgPGthbmFtZUBudHR2Ni5qcDxtYWlsdG86a2Fu YW1lQG50dHY2LmpwPj47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYu b3JnPjsgUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNA YXJib3IubmV0Pj4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2Vz DQoNCkhpIFRpcnUsDQoNCkkgYWdyZWUgaW4gcGFydCwgYnV0IHdlIG5lZWQgdG8gbG9vayBhdCB0 aGUgZW5kIChjMSkgdG8gZW5kIChzMykgcG90ZW50aWFsIGlzc3Vlcy4gIFdoYXQgeW91IGFyZSBw cm9wb3Npbmcgd29ya3MgZmluZSBmb3IgKHMyKSB0byAoczMpLg0KDQooYzEpIHJlcXVlc3RzIG1p dGlnYXRpb24gd2l0aCBhbiBhbGlhcy1uYW1lIOKAnGFsaWFzLTHigJ0uICBJZiAoczEpIGRvZXMg bm90IHBhc3MgYW55dGhpbmcgZXh0cmEgdG8gKGMyKSBmb3Igb253YXJkIHRyYW5zbWlzc2lvbiwg KHMyKSBzZWVzIGEgc2luZ2xlIGNsaWVudCAoYzIpIHJlcXVlc3RpbmcgbWl0aWdhdGlvbiB3aXRo IGFsaWFzLW5hbWUg4oCcYWxpYXMtMeKAnS4gIEZpbmUsIHRoYXQgd29ya3MuDQpJZiB0aGVyZSB3 YXMgYW5vdGhlciBET1RTIGNsaWVudCBpbiB0aGUgc2FtZSBsb2NhdGlvbiBhcyAoYzEpKGkuZS4g YzFkaWZmKSwgYm90aCB1c2luZyAoczEpIHdobyBhbHNvIGRlY2lkZWQgdG8gdXNlIGFsaWFzLW5h bWUg4oCcYWxpYXMtMeKAnSB3aG8gdGhlbiByZXF1ZXN0cyBtaXRpZ2F0aW9uLCAoczIpIGhhcyBu byBpZGVhIHRoYXQgdGhlcmUgYXJlIGRpZmZlcmVudCDigJxhbGlhcy0x4oCdIGRlZmluaXRpb25z IGlmIChjMikgZG9lcyBub3Qgc2VuZCBhbHNvIGFuIGV4dHJhIGRpZmZlcmVudGlhdG9yLg0KDQpT bywgYW55IERPVFMgR1cgaW4gdGhlIGNoYWluIHNob3VsZCBiZSBwYXNzaW5nIG9uIGEg4oCcdW5p cXVlLWV4dHJh4oCdIHBpZWNlIG9mIGluZm9ybWF0aW9uLg0KDQpSZWdhcmRzDQoNCkpvbg0KDQpG cm9tOiBEb3RzIFttYWlsdG86IGRvdHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNClNl bnQ6IDEwIE9jdG9iZXIgMjAxNyAxNToxNQ0KVG86IEpvbiBTaGFsbG93OyBrYW5hbWUgbmlzaGl6 dWthOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFu ZCBEb2JiaW5zDQpTdWJqZWN0OiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0K DQpBZ3JlZSB3aXRoIHlvdXIgcmVzcG9uc2UsIGNvbnNpZGVyIGEgZGVwbG95bWVudCB3aGljaCBo YXMgdGhlIGZvbGxvd2luZyBET1RTIGFnZW50cy4NCg0KRE9UUyBjbGllbnRzIChjMSkgPC0tLS0t LS0tLS0tLS0tLS0tLS0tPiAoczEpIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSAoYzIpIDwtLS0t LS0tLS0tLS0tLS0tPiAoczIpIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSAoYzMpIDwtLS0tLS0t LS0tLS0tLT4gKHMzKSBET1RTIHNlcnZlcg0KDQpNeSBwb2ludCBpcywgKGMyKSBuZWVkIG5vdCBj b252ZXkgdGhlIOKAnGMxIGlkZW50aXR54oCdIHRvIChzMikgYnV0IChzMikgbmVlZHMgdG8gY29u dmV5IHRoZSDigJxjMiBpZGVudGl0eeKAnSB0byAoYzMpIGFuZCAoYzMpIGluLXR1cm4gcHJvcGFn YXRlcyB0aGUg4oCcYzIgaWRlbnRpdHnigJ0gdG8gKHMzKS4NCg0KLVRpcnUNCg0KRnJvbTogSm9u IFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KU2VudDogVHVlc2Rh eSwgT2N0b2JlciAxMCwgMjAxNyA2OjE1IFBNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRk eSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2Fy UmVkZHlfS29uZGFATWNBZmVlLmNvbT4+OyBrYW5hbWUgbmlzaGl6dWthIDxrYW5hbWVAbnR0djYu anA8bWFpbHRvOmthbmFtZUBudHR2Ni5qcD4+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWls dG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFp bHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgR2F0ZXdh eXMgQ2hhbGxlbmdlcw0KDQpIaSBUaXJ1LA0KDQpBZ3JlZWQgdGhhdCBvbmx5IGEgRE9UUyBHVyBz ZXJ2ZXIgZmFjaW5nIG5lZWRzIHRvIHNlbmQgaW5mb3JtYXRpb24gdG8gdGhlIHVwc3RyZWFtIERP VFMgU2VydmVyIOKAkyB3aGljaCBjb3VsZCBhbHNvIGJlIGEgRE9UUyBHVy4NCiAgICAgICAgICAg ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgIHwgRCB8ICAgIHwNCiAgICAgICAgICstLS0tKyAgICAgICAgICB8ICAgIHwgTyB8ICAgIHwg ICAgICAgICArLS0tLSsNCiAgICAgICAgIHwgYzEgfC0tLS0tLS0tLS18IHMxIHwgVCB8IGMyIHwt LS0tLS0tLS18IHMyIHwNCiAgICAgICAgICstLS0tKyAgICAgICAgICB8ICAgIHwgUyB8ICAgIHwg ICAgICAgICArLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwgRyB8ICAgIHwN CiAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsNCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtYXJjaGl0ZWN0dXJlLTA0I3NlY3Rpb24tMi4y LjMNCg0KSG93ZXZlciwgdGhlIERPVFMgR1cgY2xpZW50IGZhY2luZyAoczEpIGlzIHRoZSBvbmUg d2l0aCBrbm93bGVkZ2Ugb2YgdGhlIGluZGl2aWR1YWwgY2xpZW50cyB0aGF0IGFyZSBjdXJyZW50 bHkgdXNpbmcgIHRoZSBET1RTIHNlcnZlciBydW5uaW5nIG9uIHRoZSBET1RTIEdXLiAgVGhpcyBp bmZvcm1hdGlvbiBoYXMgdG8gc29tZWhvdyBiZSBwYXNzZWQgb3ZlciB0byB0aGUgRE9UUyBHVyBz ZXJ2ZXIgZmFjaW5nIChjMiksIGJ1dCBzZXBhcmF0ZSBET1RTIHN0YWNrcyBhcmUgYmVpbmcgcnVu IGZvciAoczEpIGFuZCAoYzIpIGFzIHBlciBhcmNoaXRlY3R1cmUgc3BlYyAyLjIuMy4gIEkgd2Fz IHJlZmVycmluZyB0byB3aGF0IChzMSkgbWF5IG5lZWQgdG8gcGFzcyBvbiB0byAoYzIpIGluIG15 IGVtYWlsIHJlc3BvbnNlIHRvIEthbmFtZSwgbm90IHdoYXQgaXMgc2VudCBieSAoYzEpLg0KDQpS ZWdhcmRzDQoNCkpvbg0KDQpGcm9tOiBEb3RzIFttYWlsdG86IGRvdHMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkNClNlbnQ6IDEwIE9jdG9iZXIgMjAxNyAxMzoxNg0KVG86IEpvbiBTaGFs bG93OyAna2FuYW1lIG5pc2hpenVrYSc7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpk b3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMNClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBH YXRld2F5cyBDaGFsbGVuZ2VzDQoNCkkgdGhvdWdodCB3ZSBhZ3JlZWQgdGhhdCBiYXNlZCBvbiB0 aGUgY3VycmVudCBET1RTIHJlcXVpcmVtZW50cyBvbmx5IHRoZSBzZXJ2ZXItc2lkZSBET1RTIEdX IG5lZWRzIHRvIGNvbnZleSB0aGUgRE9UUyBjbGllbnQgKG9yIGNsaWVudC1zaWRlIERPVFMgV0cp IGlkZW50aXR5IHRvIHRoZSBET1RTIHNlcnZlci4NCg0KLVRpcnUNCg0KRnJvbTogSm9uIFNoYWxs b3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KU2VudDogVHVlc2RheSwgT2N0 b2JlciAxMCwgMjAxNyAyOjUzIFBNDQpUbzogJ2thbmFtZSBuaXNoaXp1a2EnIDxrYW5hbWVAbnR0 djYuanA8bWFpbHRvOmthbmFtZUBudHR2Ni5qcD4+OyBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5 IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tPj47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpk b3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86 cmRvYmJpbnNAYXJib3IubmV0Pj4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBD aGFsbGVuZ2VzDQoNCkhpIEthbmFtZSwNCg0KSSBkbyBub3QgdGhpbmsgdGhhdCBpbmZvcm1hdGlv biBuZWNlc3NhcmlseSBuZWVkcyB0byBiZSB0aGUgb3JpZ2luYWwgY2xpZW50IGlkZW50aXR5LiAg VGhlIEdXIENsaWVudCBzaWRlIHdpbGwgaGF2ZSBpdHMgb3duIGlkZW50aXR5IHdoaWNoIHRoZSBE T1RTIFNlcnZlciBjYW4gdXNlIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBET1RTIChHVykgQ2xp ZW50cy4NCg0KU28sIHllcywgYSBoYXNoZWQgc2V0IG9mIG5hbWVzIGNhbiBiZSB1c2VkIOKAkyBp dCBpcyB1cCB0byB0aGUgRE9UUyBHVyBDbGllbnQgc2lkZSB0byBtYWtlIHN1cmUgdGhhdCB0aGVy ZSBhcmUgbm8gaGFzaCBjb2xsaXNpb25zLiAgT3IgaXQgY291bGQgYmUgYSBzaW1wbGUgbGlzdCBz dWNoIGFzIEMxLCBDMiDigKZDbi4NCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFp bHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBrYW5hbWUgbmlzaGl6dWthDQpTZW50OiAxMCBPY3RvYmVyIDIwMTcgMDQ6 MTkNClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5OyBKb24gU2hhbGxvdzsgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47 IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucw0KU3Vi amVjdDogUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGksDQoNCj4gSSBh Z3JlZSB0aGUgYmVsb3cgcHJvYmxlbXMgYXJlIGFwcGxpY2FibGUgZm9yIHNlcnZlci1zaWRlIERP VFMgZ2F0ZXdheSwgaXQgbXVzdCBjb252ZXkgdGhlIOKAnGNsaWVudCBpZGVudGl0eeKAnSB0byB0 aGUgRE9UUyBzZXJ2ZXIuDQpJIGFncmVlIHdpdGggdGhpcyBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3 YXkgY2FzZS4NCkF0IHRoZSBzYW1lIHRpbWUsIEkgYWdyZWUgd2l0aCBiZWxvdzoNCj4gSSBhZ3Jl ZSB0aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5m b3JtYXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLA0KDQpUaGVuLCBzaG91bGQg RE9UUyBHVyBzZW5kIOKAnGNsaWVudCBpZGVudGl0eeKAnSAoaS5lLiBjZXJ0aWZpY2F0ZXMgb2Yg RE9UUyBjbGllbnRzKSBpdHNlbGYgb3IgaGFzaGVkKOKAnGNsaWVudCBpZGVudGl0eeKAnSkgdG8g RE9UUyBzZXJ2ZXI/DQpJZiBsYXRlciwgaG93IGNhbiBET1RTIHNlcnZlciByZWFjdCB0byB0aGUg YW1iaWd1b3VzIGluZm9ybWF0aW9uIG9mIHRoZSBoYXNoZWQo4oCcY2xpZW50IGlkZW50aXR54oCd KS4NCg0KcmVnYXJkcywNCkthbmFtZQ0KT24gMjAxNy8xMC8wOSAyMjozNCwgS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeSB3cm90ZToNCkhpIEpvbiwNCg0KSSBhZ3JlZSB0aGUgYmVsb3cgcHJvYmxl bXMgYXJlIGFwcGxpY2FibGUgZm9yIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgbXVzdCBj b252ZXkgdGhlIOKAnGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIEJ1dCBm b3IgdGhlIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgc2hvdWxkIHJlc29sdmUgY29uZmxp Y3RpbmcgcnVsZXMgYi93IERPVFMgY2xpZW50cyAoZS5nLiBvbmUgY2xpZW50IGluc3RhbGxpbmcg YmxhY2stbGlzdCBBQ0wgZm9yIGFuIElQIGFkZHJlc3MgYnV0IHRoZSBvdGhlciBjbGllbnQgaW5z dGFsbHMgd2hpdGUtbGlzdCBBQ0wgZm9yIHRoZSBzYW1lIElQIGFkZHJlc3MsIHNhbWUgYWxpYXMt bmFtZXMgZm9yIGRpZmZlcmVudCBtaXRpZ2F0aW9uIHNjb3BlcykuIEkgZG9u4oCZdCBzZWUgdGhl IG5lZWQgZm9yIGEgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcY2xp ZW50IGlkZW50aXR54oCdIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgb3IgRE9UUyBz ZXJ2ZXIuDQoNCi1UaXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZA anBzaGFsbG93LmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDcsIDIwMTcgMjowNyBQTQ0K VG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1j QWZlZS5jb20+PG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsgbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlu cyA8cmRvYmJpbnNAYXJib3IubmV0PjxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pg0KU3ViamVj dDogUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KVGhp cyBkaXNjdXNzaW9uIGdvZXMgYmV5b25kIGp1c3QgdGhlIG1pdGlnYXRpb24gcmVxdWVzdC4gIFdl IG5lZWQgdG8gY29uc2lkZXIgd2hhdCBoYXBwZW5zIHdpdGggYm90aCBhbGlhcy1uYW1lIGFuZCBh Y2wtbmFtZSAoZGF0YSBjaGFubmVsKQ0KDQpUaGUgc2ltcGxlIGNhc2Ugb2YgYSBtaXRpZ2F0aW9u IHJlcXVlc3Qgd2l0aCBubyBhbGlhcy1uYW1lIGRvZXMgbm90IHJlcXVpcmUgYW55IGtub3dsZWRn ZSBvZiB0aGUgb3JpZ2luYWwgY2xpZW50Lg0KDQpIb3dldmVyLCBpZiB0aGUgbWl0aWdhdGlvbiBy ZXF1ZXN0IHVzZXMgYWxpYXMtbmFtZSwgdGhlbiB0aGVyZSBhcmUgMyB3YXlzIG9mIGhhbmRsaW5n IHRoaXMNCg0KYSkgICAgICAgVGhlIERPVFMgR1cgcmVwbGFjZXMgdGhlIGFsaWFzLW5hbWUgd2l0 aCBpdHMgYWN0dWFsIGRlZmluaXRpb24gKHRhcmdldC1pcHMgZXRjLiBtZXJnZWQgYXMgYXBwcm9w cmlhdGUpLCBzbyBhbGlhcy1uYW1lIGlzIG5vdCBmb3J3YXJkZWQgb24gdG8gU2VydmVyIOKAkyBq dXN0IHRoZSBleHBhbmRlZCBtaXRpZ2F0aW9uIHJlcXVlc3QgaXMgZm9yd2FyZGVkDQoNCmIpICAg ICAgVGhlIERPVFMgR1cgdXBkYXRlcyB0aGUgYWxpYXMtbmFtZSB3aXRoIGEgdW5pcXVlIGFsaWFz LW5hbWUgdGhhdCBpcyBmb3J3YXJkZWQgKGFuZCBoYXMgdG8gZG8gdGhlIHNhbWUgdGhpbmcgd2hl biB0aGUgYWxpYXMtbmFtZSBpcyBjb25maWd1cmVkIG9uIHRoZSBkYXRhIGNoYW5uZWwpIOKAkyB0 byBoYW5kbGUgMiBvciBtb3JlIGNsaWVudHMgZGVmaW5pbmcgdGhlIHNhbWUgYWxpYXMtbmFtZSB3 aGljaCBoYXZlIGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3MNCg0KYykgICAgICAgVGhlIERPVFMg R1cgcmVjb2duaXNlcyB0aGF0IGFsaWFzLW5hbWUgaXMgbm90IHVuaXF1ZSBhbmQgYWRkcyBpbiDi gJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdIChJIHRoaW5rIEkgcHJlZmVyIHRoaXMg4oCcLWlu Zm/igJ0gbmFtZSB0byBjbGllbnQtaWQgb3Igb3JpZ2luYWwtY2xpZW50LWlkIGFzIOKAnC1pZOKA nSBpcyB0b28gY2xvc2VseSAgYXNzb2NpYXRlZCB3aXRoIENsaWVudCBJZGVudGl0eSBkZXJpdmVk IGZyb20gdGhlIERPVFMgR1cgQ2xpZW50IGNlcnRpZmljYXRlKQ0KV2UgaGF2ZSBhZ3JlZWQgdGhh dCB3aGVuIGEgY2xpZW50IHJlcXVlc3RzIG1pdGlnYXRpb24gc3RhdHVzLCB0aGUg4oCcYWxpYXMt bmFtZeKAnSBzaG91bGQgYmUgcmV0dXJuZWQgYXMg4oCcYWxpYXMtbmFtZeKAnSBhbmQgbm90IHRo ZSBzdWJzdGl0dXRlZCBhbGlhcy1uYW1lIGNvbmZpZ3VyYXRpb24gKHRoaXMgZG9lcyBuZWVkIHRv IGJlIHN0YXRlZCBpbiB0aGUgc3BlYyBmb3IgY2xhcml0eSkuICBUaGlzIG1ha2VzIChhKSBkaWZm aWN1bHQgdG8gYmUgaGFuZGxlZCBieSBET1RTIEdXIHdoaWNoIHRoZW4gcmFpc2VzIHRoZSBxdWVz dGlvbiDigJMgZG8gd2UgcmVhbGx5IG5lZWQgYWxpYXMtbmFtZT8NCg0KVGhlIGRlZmluaXRpb24g YW5kIGFzc29jaWF0aW9uIG9mIEFDTHMvRmlsdGVycyBvZiB0aGUgZGF0YSBjaGFubmVsIGlzIG1v cmUgZGlmZmljdWx0IOKAkyB0aGUgU2VydmVyIG11c3QgaW5zdGFsbCAvIGFwcGx5IHRoZSBhcHBy b3ByaWF0ZSBBQ0xzIG9uIGEgcGVyIChPcmlnaW5hbCkgQ2xpZW50IGJhc2lzIHdoZW4gbWl0aWdh dGlvbiBpcyBpbnZva2VkLg0KQ2xpZW50IDHigJlzIGNvbmNlcHQgb2YgYSBXaGl0ZWxpc3QgSVAg Y291bGQgYmUgQ2xpZW50IDLigJlzIGNvbmNlcHQgb2YgYSBCbGFja2xpc3QgSVAuICBUaGUgU2Vy dmVyIG5lZWRzIHRvIGtub3cgd2hpY2ggY2xpZW50IGlzIHJlcXVlc3RpbmcgdGhlIG1pdGlnYXRp b24gYW5kIGluc3RhbGwgdGhlIGNvcnJlY3QgQUNMcyDigJMgaWYgdGhlcmUgd2FzIG5vIOKAnWFk ZGl0aW9uYWwtY2xpZW50LWluZm/igJ0sIHRoZSBTZXJ2ZXIgb25seSBrbm93cyB0aGF0IGhlIGhh cyB0byBpbnN0YWxsIEFMTCBvZiB0aGUgQUNMcyAoaS5lLiBib3RoIHRoZSBCbGFjayBhbmQgV2hp dGUgbGlzdCBvZiB0aGUgc2FtZSBJUCBhcyBkZWZpbmVkIGJ5IENsaWVudCAxIGFuZCBDbGllbnQg MikgYXMgZGVmaW5lZCBieSBoaXMgY2xpZW50IChET1RTIEdXKSB3aGVuIGhpcyBjbGllbnQgcmVx dWVzdHMgYSBtaXRpZ2F0aW9uLiAgSGVyZSwgSSB0aGluayB0aGF0IGlmIHRoZXJlIGlzIG1vcmUg dGhhbiBvbmUgY2xpZW50IGZvciB0aGUgRE9UUyBHVywg4oCdYWRkaXRpb25hbC1jbGllbnQtaW5m b+KAnSBpcyByZXF1aXJlZC4NCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFpbHRv OiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9u IEJlaGFsZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAwNyBPY3RvYmVyIDIw MTcgMDQ6MjgNClRvOiBKb24gU2hhbGxvdzsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRv OmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucw0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RT IEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSW4gY2FzZSBvZiBjbGllbnQtc2lkZSBET1RTIGdhdGV3 YXksIHdoeSBkb2VzIHRoZSBET1RTIHNlcnZlciBuZWVkIHRvIGtub3cgd2hpY2gg4oCcRE9UUyBj bGllbnTigJ0gaGFzIGNvbnZleWVkIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgPw0KRm9yIGV4YW1w bGUsIHRoZSBET1RTIGNsaWVudCBjb3VsZCBiZSBhIEREb1MgZGV0ZWN0b3Igb3IgYW4gQXBwbGlj YXRpb24gc2VydmVyLCBhbmQgdGhlIGNsaWVudC1zaWRlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHJl c29sdmUgdGhlIGNvbmZsaWN0aW5nIG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBj bGllbnRzLCBhZ2dyZWdhdGUgdGhlIG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBj bGllbnQgYW5kIHNlbmQgdGhlIHVwZGF0ZWQgbWl0aWdhdGlvbiByZXF1ZXN0IHRvIHRoZSBET1RT IHNlcnZlci4NCg0KLVRpcnUNCg0KRnJvbTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0 ZkBqcHNoYWxsb3cuY29tXQ0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDYsIDIwMTcgNzo0MiBQTQ0K VG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1j QWZlZS5jb208bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PjsgbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlu cyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0KU3ViamVj dDogUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KVW5s ZXNzIEkgYW0gbWlzc2luZyBzb21ldGhpbmcsIGhvdyBkb2VzIHRoZSBDbGllbnQgc2lkZSBvZiBE T1RTIEdXIGNvbnZleSB0byB0aGUgdXBzdHJlYW0gc2VydmVyIGEgdW5pcXVlIOKAnGNsaWVudC1p ZOKAnSB3aGljaCBpcyBkaWZmZXJlbnQgdG8gdGhlIGltcGxpZWQgY2xpZW50IGlkIGFzIGRlcml2 ZWQgZnJvbSB0aGUgUEtJIGNlcnRpZmljYXRlIHRoYXQgdGhlIERPVFMgR1figJlDbGllbnQgdXNl cy9wcmVzZW50cyB3aGVuIGNvbW11bmljYXRpbmcgdG8gdGhlIHNlcnZlcj8NClRvIG1lLCB0aGVy ZSBuZWVkcyB0byBiZSBhbiBvcHRpb24gc3VjaCBhcyDigJxvcmlnaW5hbC1jbGllbnQtaWTigJ0g b3Ig4oCcY2xpZW50LWlk4oCdICh3aGljaCBpcyBjb25mdXNpbmcgd2hlbiBhbHNvIHJlZmVycmlu ZyB0byB0aGUgY2xpZW50IGlkZW50aXR5IGFzIGRlcml2ZWQgZnJvbSB0aGUgKERPVFMgR1cpIENs aWVudOKAmXMgUEtJIGNlcnRpZmljYXRlKSBhcyBhIHBhcnQgb2YgdGhlIHByb3RvY29sLg0KDQpJ IGFncmVlIHRoYXQgdGhlIERPVFMgR1cgY2FuIGdlbmVyYXRlIGl0cyBvd24gdW5pcXVlIGNsaWVu dC1pZCB0byBzdG9wIG11bHRpcGxlIGVudHJpZXMgYmVpbmcgbmVlZGVkLg0KDQpJIGFncmVlIHRo YXQgaXMgbm90IGEgZ29vZCB0aGluZyB0byDigJxsZWFr4oCdIG91dCBpbnRlcm5hbCBpbmZvcm1h dGlvbiB3aGVuIHBhc3NpbmcgdGhyb3VnaCBhIERPVFMgR1csIHNvIG15IFJFUVVJUkVEIGRvZXMg bm90IG1ha2Ugc2Vuc2UuDQoNClJlZ2FyZHMNCg0KSm9uDQpQUyDigJMgSSBhbSBoYXZpbmcgdG8g ZGVhbCB3aXRoIG90aGVyIHN0dWZmIGF0IHByZXNlbnQg4oCTIEkgd2lsbCBnZXQgYmFjayBsYXRl ciBvbiB0aGUgb3RoZXIgaXNzdWVzIHVuZGVyIGRpc2N1c3Npb24NCg0KRnJvbTogS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeSBbbWFpbHRvOiBUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUu Y29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPl0NClNlbnQ6IDA2 IE9jdG9iZXIgMjAxNyAxNDo1OA0KVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBKb24gU2hhbGxvdzsgJ0RvYmJpbnMs IFJvbGFuZCc7IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS RTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpJIGRvbuKAmXQgc2VlIGEgbmVl ZCBmb3IgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcRE9UUyBjbGll bnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiDigJxET1RTIGNsaWVudCBpZGVudGl0 eeKAnSBsb29rcyByZXF1aXJlZCBvbmx5IGZvciB0aGUgc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5 cy4gSW4gY2FzZSBvZiBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IGNhbiBjb252ZXkgdGhl IGNsaWVudC1pZCBnZW5lcmF0ZWQgZnJvbSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0g dG8gdGhlIERPVFMgc2VydmVyLiBUaGUgRE9UUyBnYXRld2F5IGNhbiBnZW5lcmF0ZSBhIHVuaXF1 ZSBjbGllbnQtaWQgYW5kIGRvZXMgbm90IGhhdmUgdG8gc2VuZCBhbiBhcnJheSBvZiBjbGllbnQt aWRzIHRvIHRoZSBET1RTIHNlcnZlciB0byByZXNvbHZlIGNsYXNoZXMuDQoNCi1UaXJ1DQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRG90cyBt YWlsaW5nIGxpc3QNCg0KRG90c0BpZXRmLm9yZzxtYWlsdG86RG90c0BpZXRmLm9yZz4NCg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoNCg== --_000_DM5PR16MB17881D83FE54C764512676ACEA4A0DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQg MiAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNl cmlmOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFj azt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpi bGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBVSSIsc2Fu cy1zZXJpZjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRl IGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30N CnAuVGV4dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxsZXMNCgl7 bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRl IGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1h bDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVt YWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMzUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUzNg0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUzOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTQwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlNDENCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5IaSBKb24sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5QbGVhc2Ugc2VlIGlubGluZQ0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxF bmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRD b21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBPY3RvYmVyIDExLCAyMDE3IDEyOjQ0 IEFNPGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDtUaXJ1bWFs ZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tJmd0Ozsga2FuYW1lIG5pc2hpenVrYSAmbHQ7a2Fu YW1lQG50dHY2LmpwJmd0OzsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgZG90c0BpZXRm Lm9yZzsgUm9sYW5kIERvYmJpbnMgJmx0O3Jkb2JiaW5zQGFyYm9yLm5ldCZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhh dCBhbnkgY29uZmxpY3RpbmcgcmVxdWVzdCBuZWVkIHRvIGJlIHNvcnRlZCBvdXQgYnkgdGhlIHJl c3BlY3RpdmUgRE9UUyBzZXJ2ZXIgY29tcG9uZW50IOKAkyBTSUctMDA5IC0gZXNwZWNpYWxseSBp ZiB0aGVyZSBhcmUgY29uZmxpY3RzDQogb3ZlciBJUCBhZGRyZXNzZXMgaW4gdGhlIG1pdGlnYXRp b24gcmVxdWVzdHMuIElmIChjMSkgYW5kIChjMTEpIHdoZXRoZXIgdXNpbmcgYWxpYXMtbmFtZSBv ciBub3QgZG8gYSBtaXRpZ2F0aW9uIHJlcXVlc3QgYW5kIHRoaXMgY3JlYXRlIGEgbWl0aWdhdGlv biBjb25mbGljdCwgdGhlbiAoczEpIG5lZWRzIHRvIHNvcnQgaXQgb3V0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I b3dldmVyIGFsaWFzZXMgYXJlIHNldCB1cCBieSB0aGUgZGF0YSBjaGFubmVsIGFuZCBwb3RlbnRp YWxseSB1c2VkIGJ5IHRoZSBzaWduYWwgY2hhbm5lbCBhdCBhIGxhdGVyIHRpbWUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlNvLCBpZiAoYzEpIGFuZCAoYzExKSBoYXZlIGRpZmZlcmVudCBjbGllbnQgaWRlbnRpdGll cywgdGhlbiBpbiBteSB0aGlua2luZyAocGVyaGFwcyBuYWl2ZWx5KSB0aGF0IGEgc2V0dXAgb2Yg 4oCcYWxpYXMtMeKAnSBieSAoYzEpIGZvbGxvd2VkIGxhdGVyIGJ5DQogKGMxMSkgYWxzbyBkZWZp bmluZyB0aGUgaWRlbnRpY2FsIGFsaWFzLW5hbWUg4oCcYWxpYXMtMeKAnSB0aGVuIHRoZSBhbGlh cy1uYW1lcyBhcmUgdHJlYXRlZCBkaWZmZXJlbnRseSBieSAoczEpIGFzIGl0IGNhbiBzZXBhcmF0 ZWx5IGFzc29jaWF0ZSDigJxhbGlhcy0x4oCdIHdpdGggdGhlIGNvcnJlY3QgKGMxKSBvciAoYzEx KS4mbmJzcDsgQXMgKGMxbikgY291bGQgYmUgYSBsYXJnZSBudW1iZXIgd2hlbiBzY2FsaW5nIG91 dCwgdGhlcmUgaXMgYW4gaW5jcmVhc2VkIGNoYW5jZQ0KIG9mIDIgb3IgbW9yZSBvZiB0aGUgY2xp ZW50cyBhdCB0aGUgKGMxKSBsZXZlbCBjaG9vc2luZyB0aGUgc2FtZSBhbGlhcy1uYW1lLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij5bVFJdIEkgZG9u4oCZdCB0aGluayB0aGVyZSB3aWxsIGJlIGEgbGFyZ2Ug bnVtYmVyIG9mIERPVFMgY2xpZW50cyBpbiBhIGRvbWFpbiwgdHlwaWNhbGx5IGEgRERvUyBtaXRp Z2F0aW9uIHN5c3RlbSBvciBERG9TIGRldGVjdG9yIGluIGEgZG9tYWluIHdpbGwNCiBhY3QgYXMg RE9UUyBjbGllbnRzIChhbmQgaW4gZnV0dXJlIGNvbnRlbnQgc2VydmVycyB3aXRoIEREb1MgZGV0 ZWN0aW9uIGNhcGFiaWxpdHkgY2FuIGFsc28gYWN0IGFzIERPVFMgY2xpZW50cykuICZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij5XaHkgZG8geW91IHRoaW5rIHRoZXJlIHdpbGwgYmUgbGFyZ2UgbnVt YmVyIG9mIERPVFMgY2xpZW50cyBpbiBhIGRvbWFpbiA/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltXaGVuIHRoZSBt aXRpZ2F0aW9uIHJlcXVlc3RzIGNvbWUgaW4gZnJvbSAoYzEpIGFuZCAoYzExKSwgdXNpbmcgdGhl aXIgYXBwcm9wcmlhdGUgYWxpYXMtbmFtZSBhbmQgdGhlcmUgaXMgYSBjb25mbGljdCB3aGVuIHRo ZSBtaXRpZ2F0aW9uIHJlcXVlc3QNCiBpcyBleHBhbmRlZCBvdXQg4oCTIHRoaXMgaGFzIHRvIGJl IHNvcnRlZCBvdXQgYnkgKHMxKS4mbmJzcDsgSG93ZXZlciwgSSBhbSBhc3N1bWluZyB0aGVyZSBp cyBub3QgYSBjb25mbGljdCBpbiB0aGUgZXhwYW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0XTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4oczEpIGNhbiBoYW5kbGUgdGhpcyBieSB0aGUgYXNzb2NpYXRpb24gb2YgdGhlIGFs aWFzLW5hbWVzIHdpdGggdGhlIGFwcHJvcHJpYXRlIChjMW4pIGlkZW50aXR5LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5PciBhcmUgeW91IHNheWluZyB0aGF0IChzMSkgaGFzIHRvIHJlamVjdCBhbGwgZHVwbGljYXRl IGFsaWFzLW5hbWVzIOKAkyBldmVuIHRob3VnaCB0aGV5IGFyZSBjb21pbmcgZnJvbSBkaWZmZXJl bnQgKGMxbikgZW50aXRpZXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tIHRoaXMg ZG9lcyBub3Qgc2NhbGUgZm9yIG1lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tIChj MTEpIOKAkyBnb2VzIEh1aD8hPyDigJMgSSBoYXZlIG5vdCBwcmV2aW91c2x5IGRlZmluZWQgdGhp cy4gV2hhdCBpcyBicm9rZW4gaGVyZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5bVFJdIGMxMSBoYXMgdG8gcmUtdHJ5 IHdpdGggYSBkaWZmZXJlbnQgYWxpYXMgbmFtZSwgUkVTVENPTkYgKGFuZCBORVRDT05GKSBkZWFs cyB3aXRoIHRoaXMgcHJvYmxlbSBieSByZXR1cm5pbmcg4oCcZGF0YS1leGlzdHPigJ0gZXJyb3Ig cmVzcG9uc2UgKDQwOQ0KIHJlc3BvbnNlIGNvZGUpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXNzdW1pbmcg bXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0IHRoYXQgdGhlIChzMSkmbmJzcDsgY2FuIGRpZmZl cmVudGlhdGUgYmV0d2VlbiBhbGlhcy1uYW1lcyB1c2VkIGJ5IGRpZmZlcmVudCAoYzFuKSBjbGll bnRzLCB3aGVuIChjMikgcGFzc2VzIHRoZSDigJxhbGlhcy0x4oCdDQogbmFtZSB1cHN0cmVhbSB3 aXRob3V0IGFueSDigJxleHRyYSAoYzFuIGluZm8p4oCdIGluZm9ybWF0aW9uIHRvIChzMiksIChz Mikgd2lsbCByZWplY3QgdGhlIGR1cGxpY2F0ZSAoKGMyKSBoYXMgcGFzc2VkIG9uIHRoZSBkYXRh IGNoYW5uZWwgcmVxdWVzdCBmcm9tIChjMSkgYW5kIChjMTEpKSB3aGljaCAoYzIpIHRoZW4gc2Vl cyBhbmQgdGhlbiBoYXMgdG8gdGVsbCAoYzExKSDigJhZb3VyIHJlcXVlc3QgdG8gZGVmaW5lIOKA nGFsaWFzLTHigJ0gZmFpbGVkIGFzIGl0DQogaXMgYWxyZWFkeSBkZWZpbmVk4oCZLiAmbmJzcDtT byBhZ2FpbiwgKGMxMSkg4oCTIGdvZXMgSHVoPyE/IOKAkyBJIGhhdmUgbm90IHByZXZpb3VzbHkg ZGVmaW5lZCB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J4oCZbSBtaXNzaW5nIHRoZSBwb2ludCBhcyB0byB3 aHkgeW91IGFyZSBjb25jZXJuZWQgYWJvdXQgYWRkaW5nIGluIHRoaXMgZXh0cmEgaW5mb3JtYXRp b24gYmV0d2VlbiAoYzIpIGFuZCAoczIpIOKAkyB3ZSBoYXZlIHBsZW50eSBvZiBzcGFjZSBpbiB0 aGUgVURQDQogcGFja2V0IOKAkyBDQk9SIG1hcHBpbmcgaGFzIGRvbmUgYSBnb29kIGRhdGEgcmVk dWN0aW9uIGpvYi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+W1RSXSBTcGFjZSBpcyBub3QgYSBwcm9ibGVt IGZvciBhZGRpbmcgdGhlIGV4dHJhIGluZm9ybWF0aW9uLCBteSBjb25jZXJuIGlzIHRoZSBuZWVk IHRvIGNvbnZleSB0aGUgZXh0cmEgaW5mb3JtYXRpb24gYW5kIERPVFMgZ2F0ZXdheSBub3QgYXNz aXN0aW5nDQogdG8gcmVzb2x2ZSB0aGUgc2FtZSBhbGlhcy1uYW1lIGZyb20gZGlmZmVyZW50IERP VFMgY2xpZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJk czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5Kb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IERvdHMgW21h aWx0bzoNCjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNl c0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZg0KPC9iPktvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHk8YnI+DQo8Yj5TZW50OjwvYj4gMTAgT2N0b2JlciAyMDE3IDE2OjU5PGJyPg0KPGI+VG86 PC9iPiBKb24gU2hhbGxvdzsga2FuYW1lIG5pc2hpenVrYTsgPGEgaHJlZj0ibWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwv YT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsgUm9s YW5kIERvYmJpbnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlz IENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij5IaSBKb24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij5UaGUgcm9sZSBvZiBzMSBpcyBtdWNoIG1vcmUgdGhhbiBqdXN0IGZvcndhcmRpbmcgdGhl IERPVFMgY2xpZW50IG1lc3NhZ2VzLCBwbGVhc2Ugc2VlIChTSUctMDA5IGluIHRoZSByZXF1aXJl bWVudHMgZHJhZnRzKSwgaWYgYSBET1RTIGNsaWVudCBoYXMgdXNlZCB0aGUgc2FtZQ0KIGFsaWFz IG5hbWUgcHJldmlvdXNseSBjb252ZXllZCBieSBhbm90aGVyIGNsaWVudCB0aGVuIHMxIG11c3Qg cmVqZWN0IHRoZSByZXF1ZXN0LiBJZiBjb25mbGljdGluZyByZXF1ZXN0cyBhcmUgcmVzb2x2ZWQg YnkgczEgdGhlbiBhbnkgcmVzcG9uc2UgbWVzc2FnZSBzZW50IGJ5IHMzIHdpbGwgYmUgZm9yd2Fy ZGVkIGJ5IHMxIHRvIHRoZSByaWdodCBET1RTIGNsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEpvbiBTaGFsbG93IFs8YSBocmVmPSJtYWlsdG86c3Vw anBzLWlldGZAanBzaGFsbG93LmNvbSI+bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgODo0NyBQ TTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0i bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJl ZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+Jmd0Ozsga2FuYW1lIG5pc2hpenVrYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmthbmFtZUBudHR2Ni5qcCI+a2FuYW1lQG50dHY2LmpwPC9hPiZndDs7DQo8YSBo cmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj4NCmRvdHNA aWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5z QGFyYm9yLm5ldCI+cmRvYmJpbnNAYXJib3IubmV0PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZW4gdGhhdCBicmVha3MgYSBz aWduYWwgR0VUIGZvciBtaXRpZ2F0aW9uIHN0YXR1cyBmcm9tIChjMSkgKG1pdGlnYXRpb24gcmVx dWVzdCB1c2VzIGFsaWFzLW5hbWUpIOKAkyB3aGF0IGdldHMgc2VudCBiYWNrIGluIHRoZSBhbGlh cy1uYW1lIGZpZWxkDQogd2hlbiB0aGUgcmVzcG9uc2UgdGhhdCBpcyBzZW50IGJ5IChzMykgd2hl biBpdCBnZXRzIHRvIChjMSk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhvdWdodCB3ZSBoYWQgYWdyZWVkIHRv IGxlYXZlIHRoZSBhbGlhcyBuYW1lIOKAkyBhcyBpcyDigJMgKG5vdCBzdWJzdGl0dXRlZCkgaW4g d2hhdCBpcyBzZW50IGJhY2sgdG8gKGMxKSBmcm9tIChzMSkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPihjMSkgaXMg bm90IHBhcnRpY3VsYXJseSBpbnRlcmVzdGVkIGluIGhvdyAoYzExKSBpcyBnZXR0aW5nIG1pdGln YXRlZCBhbmQgcHJvYmFibHkgZG9lcyBub3Qgd2FudCAoYzExKSBzdGF0cyBhZGRlZCBpbnRvIGhp cyDigJMgKHMzKSBuZWVkIHRvIGtub3cgaG93DQogdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIChj MSkgYW5kIChjMTEpIOKAkyB3aGljaCBpcyBlYXNpbHkgZG9uZSBpZiAoYzEpIChvciAoYzExKSBp bmZvcm1hdGlvbiBpcyBwYXNzZWQgdXAgdG8gKHMzKSwgc3RhcnRpbmcgd2l0aCAoczEpLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaGlzIHdob2xlIHRoaW5nIG5lZWRzIHRvIGJlIHNjYWxhYmxlLCBhbmQgSSBhbSBz dHJ1Z2dsaW5nIHdpdGggaG93IHRvIGFjdHVhbGx5IGltcGxlbWVudCB5b3VyIHByb3Bvc2FsLiZu YnNwOyBBbGxvd2luZyBlYWNoIERPVFMgR1cgdG8gbGVhcm4gYW5kIHBhc3MNCiBvbiBzb21ldGhp bmcgZXh0cmEgdGhhdCBkaWZmZXJlbnRpYXRlcyB0aGUgRE9UUyBHVyBpbW1lZGlhdGUgY2xpZW50 cyBtYWtlcyB0aGUgaW1wbGVtZW50YXRpb24gcmVsYXRpdmVseSBlYXN5LiZuYnNwOyBUaGVyZSBp cyBubyBuZWVkIGZvciBhIERPVFMgR1cgdG8gYWRkIGluIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24g aWYgZXh0cmEgaW5mb3JtYXRpb24gaXMgYWxyZWFkeSBlbWJlZGRlZCDigJMgdW5sZXNzIGhlIHNl ZXMgYSBuYW1lIGNsYXNoIGZyb20gMiBvcg0KIG1vcmUgb2YgaGlzIHVuaXF1ZWx5IGlkZW50aWZp ZWQgRE9UUyBjbGllbnRzIOKAkyB3aGljaCB3aWxsIGJlIGRpZmZlcmVudCBlbnRpdGllcyBhbnl3 YXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPiBEb3RzIFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2Vz QGlldGYub3JnIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YNCjwv Yj5Lb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5PGJyPg0KPGI+U2VudDo8L2I+IDEwIE9jdG9iZXIg MjAxNyAxNTo1Mjxicj4NCjxiPlRvOjwvYj4gSm9uIFNoYWxsb3c7IGthbmFtZSBuaXNoaXp1a2E7 IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4NCm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ ZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+VGhlIGNvbmZsaWN0aW5nIGFsaWFzLW5hbWVzIGZy b20gRE9UUyBjbGllbnQgKGMxKSBhbmQgYW5vdGhlciBjbGllbnQgKGxldOKAmSBjYWxsIChjMTEp KSBiZWhpbmQgKHMxKSBzaG91bGQgYmUgcmVzb2x2ZWQgYnkgczEgaXRzZWxmLCBpdCBpcyBhbHNv IHRoZSByZXNwb25zaWJpbGl0eQ0KIG9mIChzMSkgdG8gcmVzb2x2ZSBjb25mbGljdGluZyBtaXRp Z2F0aW9uIHJlcXVlc3RzIGZyb20gKGMxKSBhbmQgKGMxMSksIDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPmFnZ3JlZ2F0ZSB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIHRoZSBET1RTIGNsaWVu dHMgKGMxIGFuZCBjMTEpIGFuZCBzZW5kIHRoZSB1cGRhdGVkIG1pdGlnYXRpb24gcmVxdWVzdCAo YzIpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4tVGlydTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ IEpvbiBTaGFsbG93IFs8YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+ bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgODoxMSBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEs IFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5 X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+ Jmd0Ozsga2FuYW1lIG5pc2hpenVrYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthbmFtZUBudHR2Ni5q cCI+a2FuYW1lQG50dHY2LmpwPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhy ZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj4NCmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9i YmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+cmRvYmJpbnNAYXJi b3IubmV0PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3 YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkkgYWdyZWUgaW4gcGFydCwgYnV0IHdlIG5lZWQgdG8gbG9vayBhdCB0aGUg ZW5kIChjMSkgdG8gZW5kIChzMykgcG90ZW50aWFsIGlzc3Vlcy4mbmJzcDsgV2hhdCB5b3UgYXJl IHByb3Bvc2luZyB3b3JrcyBmaW5lIGZvciAoczIpIHRvIChzMykuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPihjMSkg cmVxdWVzdHMgbWl0aWdhdGlvbiB3aXRoIGFuIGFsaWFzLW5hbWUg4oCcYWxpYXMtMeKAnS4mbmJz cDsgSWYgKHMxKSBkb2VzIG5vdCBwYXNzIGFueXRoaW5nIGV4dHJhIHRvIChjMikgZm9yIG9ud2Fy ZCB0cmFuc21pc3Npb24sIChzMikgc2VlcyBhIHNpbmdsZQ0KIGNsaWVudCAoYzIpIHJlcXVlc3Rp bmcgbWl0aWdhdGlvbiB3aXRoIGFsaWFzLW5hbWUg4oCcYWxpYXMtMeKAnS4mbmJzcDsgRmluZSwg dGhhdCB3b3Jrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoZXJlIHdhcyBh bm90aGVyIERPVFMgY2xpZW50IGluIHRoZSBzYW1lIGxvY2F0aW9uIGFzIChjMSkoaS5lLiBjMWRp ZmYpLCBib3RoIHVzaW5nIChzMSkgd2hvIGFsc28gZGVjaWRlZCB0byB1c2UgYWxpYXMtbmFtZSDi gJxhbGlhcy0x4oCdIHdobyB0aGVuDQogcmVxdWVzdHMgbWl0aWdhdGlvbiwgKHMyKSBoYXMgbm8g aWRlYSB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQg4oCcYWxpYXMtMeKAnSBkZWZpbml0aW9ucyBp ZiAoYzIpIGRvZXMgbm90IHNlbmQgYWxzbyBhbiBleHRyYSBkaWZmZXJlbnRpYXRvci4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5TbywgYW55IERPVFMgR1cgaW4gdGhlIGNoYWluIHNob3VsZCBiZSBwYXNzaW5nIG9u IGEg4oCcdW5pcXVlLWV4dHJh4oCdIHBpZWNlIG9mIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5S ZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkpvbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBE b3RzIFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5kb3Rz LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Lb25kYSwgVGlydW1h bGVzd2FyIFJlZGR5PGJyPg0KPGI+U2VudDo8L2I+IDEwIE9jdG9iZXIgMjAxNyAxNToxNTxicj4N CjxiPlRvOjwvYj4gSm9uIFNoYWxsb3c7IGthbmFtZSBuaXNoaXp1a2E7IDxhIGhyZWY9Im1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4NCm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwv YT47IFJvbGFuZCBEb2JiaW5zPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10gRE9UUyBH YXRld2F5cyBDaGFsbGVuZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+QWdyZWUgd2l0aCB5b3VyIHJlc3BvbnNlLCBjb25zaWRlciBhIGRlcGxveW1l bnQgd2hpY2ggaGFzIHRoZSBmb2xsb3dpbmcgRE9UUyBhZ2VudHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5ET1RTIGNsaWVudHMgKGMxKQ0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xv cjp3aW5kb3d0ZXh0Ij7Dnzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ LS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+w6A8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPg0KIChzMSkgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IChj MikgPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+w588L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPi0tLS0tLS0tLS0tLTwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOndpbmRvd3Rl eHQiPsOgPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPihzMikgc2VydmVyLXNp ZGUgRE9UUyBnYXRld2F5IChjMykNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+w588L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPi0tLS0tLS0tLS08L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOndpbmRvd3RleHQi PsOgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4NCiAoczMpIERPVFMg c2VydmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5N eSBwb2ludCBpcywgKGMyKSBuZWVkIG5vdCBjb252ZXkgdGhlIOKAnGMxIGlkZW50aXR54oCdIHRv IChzMikgYnV0IChzMikgbmVlZHMgdG8gY29udmV5IHRoZSDigJxjMiBpZGVudGl0eeKAnSB0byAo YzMpIGFuZCAoYzMpIGluLXR1cm4gcHJvcGFnYXRlcyB0aGUg4oCcYzIgaWRlbnRpdHnigJ0NCiB0 byAoczMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gSm9u IFNoYWxsb3cgWzxhIGhyZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tIj5tYWls dG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgT2N0b2JlciAxMCwgMjAxNyA2OjE1IFBNPGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGly dW1hbGVzd2FyIFJlZGR5ICZsdDs8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29u ZGFATWNBZmVlLmNvbSI+VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTwvYT4mZ3Q7 OyBrYW5hbWUgbmlzaGl6dWthICZsdDs8YSBocmVmPSJtYWlsdG86a2FuYW1lQG50dHY2LmpwIj5r YW5hbWVAbnR0djYuanA8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0i bWFpbHRvOmRvdHNAaWV0Zi5vcmciPg0KZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5z ICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5u ZXQ8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMg Q2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgVGlydSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+QWdyZWVkIHRoYXQgb25seSBhIERPVFMgR1cgc2VydmVyIGZhY2luZyBuZWVkcyB0 byBzZW5kIGluZm9ybWF0aW9uIHRvIHRoZSB1cHN0cmVhbSBET1RTIFNlcnZlciDigJMgd2hpY2gg Y291bGQgYWxzbyBiZSBhIERPVFMgR1cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLS0tLS0tLS0t LS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRCB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t LS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgTyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tJiM0Mzs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IGMxIHwtLS0tLS0tLS0tfCBzMSB8 IFQgfCBjMiB8LS0tLS0tLS0tfCBzMiB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJiM0MzstLS0tJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyB8IFMgfCZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyB8IEcgfCZuYnNw OyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tJiM0Mzs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtYXJjaGl0ZWN0dXJlLTA0I3NlY3Rpb24tMi4yLjMi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtYXJjaGl0ZWN0dXJl LTA0I3NlY3Rpb24tMi4yLjM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIHRoZSBET1RTIEdXIGNs aWVudCBmYWNpbmcgKHMxKSBpcyB0aGUgb25lIHdpdGgga25vd2xlZGdlIG9mIHRoZSBpbmRpdmlk dWFsIGNsaWVudHMgdGhhdCBhcmUgY3VycmVudGx5IHVzaW5nICZuYnNwO3RoZSBET1RTIHNlcnZl ciBydW5uaW5nIG9uDQogdGhlIERPVFMgR1cuJm5ic3A7IFRoaXMgaW5mb3JtYXRpb24gaGFzIHRv IHNvbWVob3cgYmUgcGFzc2VkIG92ZXIgdG8gdGhlIERPVFMgR1cgc2VydmVyIGZhY2luZyAoYzIp LCBidXQgc2VwYXJhdGUgRE9UUyBzdGFja3MgYXJlIGJlaW5nIHJ1biBmb3IgKHMxKSBhbmQgKGMy KSBhcyBwZXIgYXJjaGl0ZWN0dXJlIHNwZWMgMi4yLjMuJm5ic3A7IEkgd2FzIHJlZmVycmluZyB0 byB3aGF0IChzMSkgbWF5IG5lZWQgdG8gcGFzcyBvbiB0byAoYzIpIGluIG15IGVtYWlsIHJlc3Bv bnNlDQogdG8gS2FuYW1lLCBub3Qgd2hhdCBpcyBzZW50IGJ5IChjMSkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJl Z2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Sm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBEb3Rz IFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5kb3RzLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Lb25kYSwgVGlydW1hbGVz d2FyIFJlZGR5PGJyPg0KPGI+U2VudDo8L2I+IDEwIE9jdG9iZXIgMjAxNyAxMzoxNjxicj4NCjxi PlRvOjwvYj4gSm9uIFNoYWxsb3c7ICdrYW5hbWUgbmlzaGl6dWthJzsgPGEgaHJlZj0ibWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9h PjsgUm9sYW5kIERvYmJpbnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdh dGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3 aW5kb3d0ZXh0Ij5JIHRob3VnaHQgd2UgYWdyZWVkIHRoYXQgYmFzZWQgb24gdGhlIGN1cnJlbnQg RE9UUyByZXF1aXJlbWVudHMgb25seSB0aGUgc2VydmVyLXNpZGUgRE9UUyBHVyBuZWVkcyB0byBj b252ZXkgdGhlIERPVFMgY2xpZW50IChvciBjbGllbnQtc2lkZSBET1RTIFdHKSBpZGVudGl0eQ0K IHRvIHRoZSBET1RTIHNlcnZlci4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPiBKb24gU2hhbGxvdyBbPGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hh bGxvdy5jb20iPm1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDEwLCAyMDE3IDI6NTMgUE08YnI+DQo8Yj5Ubzo8 L2I+ICdrYW5hbWUgbmlzaGl6dWthJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthbmFtZUBudHR2Ni5q cCI+a2FuYW1lQG50dHY2LmpwPC9hPiZndDs7IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0 OzxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj5UaXJ1 bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTwvYT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj4NCmRvdHNAaWV0Zi5vcmc8L2E+ OyBSb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+ cmRvYmJpbnNAYXJib3IubmV0PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEb3Rz XSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkhpIEthbmFtZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkbyBub3QgdGhpbmsgdGhhdCBpbmZvcm1hdGlv biBuZWNlc3NhcmlseSBuZWVkcyB0byBiZSB0aGUgb3JpZ2luYWwgY2xpZW50IGlkZW50aXR5LiZu YnNwOyBUaGUgR1cgQ2xpZW50IHNpZGUgd2lsbCBoYXZlIGl0cyBvd24gaWRlbnRpdHkgd2hpY2gg dGhlIERPVFMNCiBTZXJ2ZXIgY2FuIHVzZSB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gRE9UUyAo R1cpIENsaWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvLCB5ZXMsIGEgaGFzaGVkIHNldCBvZiBuYW1lcyBj YW4gYmUgdXNlZCDigJMgaXQgaXMgdXAgdG8gdGhlIERPVFMgR1cgQ2xpZW50IHNpZGUgdG8gbWFr ZSBzdXJlIHRoYXQgdGhlcmUgYXJlIG5vIGhhc2ggY29sbGlzaW9ucy4mbmJzcDsgT3IgaXQgY291 bGQgYmUNCiBhIHNpbXBsZSBsaXN0IHN1Y2ggYXMgQzEsIEMyIOKApkNuLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5S ZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gRG90 cyBbbWFpbHRvOg0KPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+ZG90cy1i b3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mDQo8L2I+a2FuYW1lIG5pc2hpenVr YTxicj4NCjxiPlNlbnQ6PC9iPiAxMCBPY3RvYmVyIDIwMTcgMDQ6MTk8YnI+DQo8Yj5Ubzo8L2I+ IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk7IEpvbiBTaGFsbG93OyA8YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+ OyBSb2xhbmQgRG9iYmluczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNdIERPVFMgR2F0 ZXdheXMgQ2hhbGxlbmdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+SGksPGJyPg0KPGJyPg0KJmd0OyBJIGFncmVlIHRoZSBi ZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJsZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5 LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNl cnZlci4NCjxicj4NCkkgYWdyZWUgd2l0aCB0aGlzIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSBj YXNlLjxicj4NCkF0IHRoZSBzYW1lIHRpbWUsIEkgYWdyZWUgd2l0aCBiZWxvdzo8YnI+DQomZ3Q7 IEkgYWdyZWUgdGhhdCBpcyBub3QgYSBnb29kIHRoaW5nIHRvIOKAnGxlYWvigJ0gb3V0IGludGVy bmFsIGluZm9ybWF0aW9uIHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9UUyBHVywNCjxicj4NCjxi cj4NClRoZW4sIHNob3VsZCBET1RTIEdXIHNlbmQg4oCcY2xpZW50IGlkZW50aXR54oCdIChpLmUu IGNlcnRpZmljYXRlcyBvZiBET1RTIGNsaWVudHMpIGl0c2VsZiBvciBoYXNoZWQo4oCcY2xpZW50 IGlkZW50aXR54oCdKSB0byBET1RTIHNlcnZlcj88YnI+DQpJZiBsYXRlciwgaG93IGNhbiBET1RT IHNlcnZlciByZWFjdCB0byB0aGUgYW1iaWd1b3VzIGluZm9ybWF0aW9uIG9mIHRoZSBoYXNoZWQo 4oCcY2xpZW50IGlkZW50aXR54oCdKS48YnI+DQo8YnI+DQpyZWdhcmRzLDxicj4NCkthbmFtZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+T24gMjAxNy8xMC8wOSAyMjozNCwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRk eSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgSm9uLDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBw bGljYWJsZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg 4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gQnV0IGZvciB0aGUgY2xp ZW50LXNpZGUgRE9UUyBnYXRld2F5LA0KIGl0IHNob3VsZCByZXNvbHZlIGNvbmZsaWN0aW5nIHJ1 bGVzIGIvdyBET1RTIGNsaWVudHMgKGUuZy4gb25lIGNsaWVudCBpbnN0YWxsaW5nIGJsYWNrLWxp c3QgQUNMIGZvciBhbiBJUCBhZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xpZW50IGluc3RhbGxzIHdo aXRlLWxpc3QgQUNMIGZvciB0aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1lIGFsaWFzLW5hbWVzIGZv ciBkaWZmZXJlbnQgbWl0aWdhdGlvbiBzY29wZXMpLiBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkDQog Zm9yIGEgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcY2xpZW50IGlk ZW50aXR54oCdIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgb3IgRE9UUyBzZXJ2ZXIu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi1UaXJ1PC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBKb24gU2hhbGxvdyBbPGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRm QGpwc2hhbGxvdy5jb20iPm1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPC9hPl0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3IDI6MDcgUE08YnI+DQo8 Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPGEgaHJlZj0ibWFpbHRvOlRpcnVt YWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPg0KJmx0O1RpcnVtYWxlc3dhclJlZGR5X0tv bmRhQE1jQWZlZS5jb20mZ3Q7PC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9 Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnMN CjxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiPiZsdDtyZG9iYmluc0BhcmJvci5u ZXQmZ3Q7PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMg Q2hhbGxlbmdlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U aGlzIGRpc2N1c3Npb24gZ29lcyBiZXlvbmQganVzdCB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0LiZu YnNwOyBXZSBuZWVkIHRvIGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3aXRoIGJvdGggYWxpYXMtbmFt ZSBhbmQgYWNsLW5hbWUgKGRhdGEgY2hhbm5lbCk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBzaW1wbGUgY2FzZSBvZiBh IG1pdGlnYXRpb24gcmVxdWVzdCB3aXRoIG5vIGFsaWFzLW5hbWUgZG9lcyBub3QgcmVxdWlyZSBh bnkga25vd2xlZGdlIG9mIHRoZSBvcmlnaW5hbCBjbGllbnQuJm5ic3A7DQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhvd2V2 ZXIsIGlmIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgdXNlcyBhbGlhcy1uYW1lLCB0aGVuIHRoZXJl IGFyZSAzIHdheXMgb2YgaGFuZGxpbmcgdGhpczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+YSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgRE9UUyBH VyByZXBsYWNlcyB0aGUgYWxpYXMtbmFtZSB3aXRoIGl0cyBhY3R1YWwgZGVmaW5pdGlvbiAodGFy Z2V0LWlwcyBldGMuIG1lcmdlZCBhcyBhcHByb3ByaWF0ZSksIHNvIGFsaWFzLW5hbWUgaXMgbm90 IGZvcndhcmRlZCBvbiB0byBTZXJ2ZXIg4oCTIGp1c3QgdGhlDQogZXhwYW5kZWQgbWl0aWdhdGlv biByZXF1ZXN0IGlzIGZvcndhcmRlZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Yik8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgRE9UUyBHVyB1cGRhdGVzIHRo ZSBhbGlhcy1uYW1lIHdpdGggYSB1bmlxdWUgYWxpYXMtbmFtZSB0aGF0IGlzIGZvcndhcmRlZCAo YW5kIGhhcyB0byBkbyB0aGUgc2FtZSB0aGluZyB3aGVuIHRoZSBhbGlhcy1uYW1lIGlzIGNvbmZp Z3VyZWQgb24gdGhlIGRhdGEgY2hhbm5lbCkNCiDigJMgdG8gaGFuZGxlIDIgb3IgbW9yZSBjbGll bnRzIGRlZmluaW5nIHRoZSBzYW1lIGFsaWFzLW5hbWUgd2hpY2ggaGF2ZSBkaWZmZXJlbnQgY2hh cmFjdGVyaXN0aWNzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVp biI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5jKTwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RTIEdXIHJlY29nbmlzZXMgdGhh dCBhbGlhcy1uYW1lIGlzIG5vdCB1bmlxdWUgYW5kIGFkZHMgaW4g4oCdYWRkaXRpb25hbC1jbGll bnQtaW5mb+KAnSAoSSB0aGluayBJIHByZWZlciB0aGlzIOKAnC1pbmZv4oCdIG5hbWUgdG8gY2xp ZW50LWlkIG9yIG9yaWdpbmFsLWNsaWVudC1pZA0KIGFzIOKAnC1pZOKAnSBpcyB0b28gY2xvc2Vs eSAmbmJzcDthc3NvY2lhdGVkIHdpdGggQ2xpZW50IElkZW50aXR5IGRlcml2ZWQgZnJvbSB0aGUg RE9UUyBHVyBDbGllbnQgY2VydGlmaWNhdGUpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIGhhdmUgYWdyZWVkIHRoYXQgd2hlbiBhIGNs aWVudCByZXF1ZXN0cyBtaXRpZ2F0aW9uIHN0YXR1cywgdGhlIOKAnGFsaWFzLW5hbWXigJ0gc2hv dWxkIGJlIHJldHVybmVkIGFzIOKAnGFsaWFzLW5hbWXigJ0gYW5kIG5vdCB0aGUgc3Vic3RpdHV0 ZWQgYWxpYXMtbmFtZQ0KIGNvbmZpZ3VyYXRpb24gKHRoaXMgZG9lcyBuZWVkIHRvIGJlIHN0YXRl ZCBpbiB0aGUgc3BlYyBmb3IgY2xhcml0eSkuJm5ic3A7IFRoaXMgbWFrZXMgKGEpIGRpZmZpY3Vs dCB0byBiZSBoYW5kbGVkIGJ5IERPVFMgR1cgd2hpY2ggdGhlbiByYWlzZXMgdGhlIHF1ZXN0aW9u IOKAkyBkbyB3ZSByZWFsbHkgbmVlZCBhbGlhcy1uYW1lPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGRlZmluaXRpb24g YW5kIGFzc29jaWF0aW9uIG9mIEFDTHMvRmlsdGVycyBvZiB0aGUgZGF0YSBjaGFubmVsIGlzIG1v cmUgZGlmZmljdWx0IOKAkyB0aGUgU2VydmVyIG11c3QgaW5zdGFsbCAvIGFwcGx5IHRoZSBhcHBy b3ByaWF0ZSBBQ0xzIG9uIGENCiBwZXIgKE9yaWdpbmFsKSBDbGllbnQgYmFzaXMgd2hlbiBtaXRp Z2F0aW9uIGlzIGludm9rZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkNsaWVudCAx4oCZcyBjb25jZXB0IG9mIGEgV2hpdGVsaXN0IElQ IGNvdWxkIGJlIENsaWVudCAy4oCZcyBjb25jZXB0IG9mIGEgQmxhY2tsaXN0IElQLiZuYnNwOyBU aGUgU2VydmVyIG5lZWRzIHRvIGtub3cgd2hpY2ggY2xpZW50IGlzIHJlcXVlc3RpbmcgdGhlIG1p dGlnYXRpb24NCiBhbmQgaW5zdGFsbCB0aGUgY29ycmVjdCBBQ0xzIOKAkyBpZiB0aGVyZSB3YXMg bm8g4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSwgdGhlIFNlcnZlciBvbmx5IGtub3dzIHRo YXQgaGUgaGFzIHRvIGluc3RhbGwgQUxMIG9mIHRoZSBBQ0xzIChpLmUuIGJvdGggdGhlIEJsYWNr IGFuZCBXaGl0ZSBsaXN0IG9mIHRoZSBzYW1lIElQIGFzIGRlZmluZWQgYnkgQ2xpZW50IDEgYW5k IENsaWVudCAyKSBhcyBkZWZpbmVkIGJ5IGhpcyBjbGllbnQgKERPVFMgR1cpDQogd2hlbiBoaXMg Y2xpZW50IHJlcXVlc3RzIGEgbWl0aWdhdGlvbi4mbmJzcDsgSGVyZSwgSSB0aGluayB0aGF0IGlm IHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgY2xpZW50IGZvciB0aGUgRE9UUyBHVywg4oCdYWRkaXRp b25hbC1jbGllbnQtaW5mb+KAnSBpcyByZXF1aXJlZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpv bjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWYiPiBEb3RzIFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYg T2YNCjwvYj5Lb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5PGJyPg0KPGI+U2VudDo8L2I+IDA3IE9j dG9iZXIgMjAxNyAwNDoyODxicj4NCjxiPlRvOjwvYj4gSm9uIFNoYWxsb3c7IDxhIGhyZWY9Im1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3Jn PC9hPjsgUm9sYW5kIERvYmJpbnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RT IEdhdGV3YXlzIENoYWxsZW5nZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SW4gY2FzZSBvZiBjbGllbnQtc2lk ZSBET1RTIGdhdGV3YXksIHdoeSBkb2VzIHRoZSBET1RTIHNlcnZlciBuZWVkIHRvIGtub3cgd2hp Y2gg4oCcRE9UUyBjbGllbnTigJ0gaGFzIGNvbnZleWVkIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3Qg Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Rm9yIGV4YW1wbGUs IHRoZSBET1RTIGNsaWVudCBjb3VsZCBiZSBhIEREb1MgZGV0ZWN0b3Igb3IgYW4gQXBwbGljYXRp b24gc2VydmVyLCBhbmQgdGhlIGNsaWVudC1zaWRlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHJlc29s dmUgdGhlIGNvbmZsaWN0aW5nIG1pdGlnYXRpb24gcmVxdWVzdHMNCiBmcm9tIHRoZSBET1RTIGNs aWVudHMsIGFnZ3JlZ2F0ZSB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIHRoZSBET1RTIGNs aWVudCBhbmQgc2VuZCB0aGUgdXBkYXRlZCBtaXRpZ2F0aW9uIHJlcXVlc3QgdG8gdGhlIERPVFMg c2VydmVyLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tVGlydTwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSm9uIFNoYWxsb3cgWzxhIGhyZWY9Im1haWx0bzpzdXBq cHMtaWV0ZkBqcHNoYWxsb3cuY29tIj5tYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDYsIDIwMTcgNzo0MiBQTTxi cj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFp bHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5 X0tvbmRhQE1jQWZlZS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPg0KZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2Ji aW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJv ci5uZXQ8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdh eXMgQ2hhbGxlbmdlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRpcnUsPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5Vbmxlc3MgSSBhbSBtaXNzaW5nIHNvbWV0aGluZywgaG93IGRvZXMgdGhlIENsaWVudCBzaWRl IG9mIERPVFMgR1cgY29udmV5IHRvIHRoZSB1cHN0cmVhbSBzZXJ2ZXIgYSB1bmlxdWUg4oCcY2xp ZW50LWlk4oCdIHdoaWNoIGlzIGRpZmZlcmVudCB0byB0aGUgaW1wbGllZA0KIGNsaWVudCBpZCBh cyBkZXJpdmVkIGZyb20gdGhlIFBLSSBjZXJ0aWZpY2F0ZSB0aGF0IHRoZSBET1RTIEdX4oCZQ2xp ZW50IHVzZXMvcHJlc2VudHMgd2hlbiBjb21tdW5pY2F0aW5nIHRvIHRoZSBzZXJ2ZXI/PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvIG1l LCB0aGVyZSBuZWVkcyB0byBiZSBhbiBvcHRpb24gc3VjaCBhcyDigJxvcmlnaW5hbC1jbGllbnQt aWTigJ0gb3Ig4oCcY2xpZW50LWlk4oCdICh3aGljaCBpcyBjb25mdXNpbmcgd2hlbiBhbHNvIHJl ZmVycmluZyB0byB0aGUgY2xpZW50IGlkZW50aXR5IGFzDQogZGVyaXZlZCBmcm9tIHRoZSAoRE9U UyBHVykgQ2xpZW504oCZcyBQS0kgY2VydGlmaWNhdGUpIGFzIGEgcGFydCBvZiB0aGUgcHJvdG9j b2wuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JIGFncmVlIHRoYXQgdGhlIERPVFMgR1cgY2FuIGdlbmVyYXRlIGl0cyBvd24g dW5pcXVlIGNsaWVudC1pZCB0byBzdG9wIG11bHRpcGxlIGVudHJpZXMgYmVpbmcgbmVlZGVkLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SSBhZ3JlZSB0aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KAnSBvdXQg aW50ZXJuYWwgaW5mb3JtYXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdXLCBzbyBt eSBSRVFVSVJFRCBkb2VzIG5vdCBtYWtlIHNlbnNlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9u PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlBTIOKAkyBJIGFtIGhhdmluZyB0byBkZWFsIHdpdGggb3RoZXIgc3R1ZmYgYXQgcHJlc2VudCDi gJMgSSB3aWxsIGdldCBiYWNrIGxhdGVyIG9uIHRoZSBvdGhlciBpc3N1ZXMgdW5kZXIgZGlzY3Vz c2lvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IFttYWlsdG86 DQo8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbSI+VGly dW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g MDYgT2N0b2JlciAyMDE3IDE0OjU4PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwv YT47IEpvbiBTaGFsbG93OyAnRG9iYmlucywgUm9sYW5kJzsNCjxhIGhyZWY9Im1haWx0bzpkb3Rz QGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0Rv dHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGRvbuKAmXQgc2Vl IGEgbmVlZCBmb3IgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0aGUg4oCcRE9U UyBjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiDigJxET1RTIGNsaWVudCBp ZGVudGl0eeKAnSBsb29rcyByZXF1aXJlZCBvbmx5IGZvciB0aGUgc2VydmVyLXNpZGUNCiBET1RT IGdhdGV3YXlzLiBJbiBjYXNlIG9mIHNlcnZlci1zaWRlIERPVFMgZ2F0ZXdheSwgaXQgY2FuIGNv bnZleSB0aGUgY2xpZW50LWlkIGdlbmVyYXRlZCBmcm9tIHRoZSDigJxET1RTIGNsaWVudCBpZGVu dGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIFRoZSBET1RTIGdhdGV3YXkgY2FuIGdlbmVyYXRl IGEgdW5pcXVlIGNsaWVudC1pZCBhbmQgZG9lcyBub3QgaGF2ZSB0byBzZW5kIGFuIGFycmF5IG9m IGNsaWVudC1pZHMgdG8gdGhlIERPVFMgc2VydmVyDQogdG8gcmVzb2x2ZSBjbGFzaGVzLiA8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LVRpcnU8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+RG90cyBtYWlsaW5nIGxpc3Q8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPjxhIGhyZWY9 Im1haWx0bzpEb3RzQGlldGYub3JnIj5Eb3RzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RvdHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB17881D83FE54C764512676ACEA4A0DM5PR16MB1788namp_-- From nobody Wed Oct 11 02:46:45 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E6A13307E for ; Wed, 11 Oct 2017 02:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9ze52Ue_uzo for ; Wed, 11 Oct 2017 02:46:40 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7361331C2 for ; Wed, 11 Oct 2017 02:46:38 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id E9A4025F68D; Wed, 11 Oct 2017 18:46:36 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 8932075900A; Wed, 11 Oct 2017 18:46:35 +0900 (JST) To: "Konda, Tirumaleswar Reddy" , Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" , Roland Dobbins References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> <0df701d341d5$cfd88770$6f89 9650$@jpshallow.com> <0e3501d341da$cf9e4b50$6edae1f0$@jpshallow.com> <0e7b01d341fb$ea576870$bf063950$@jpshallow.com> From: kaname nishizuka Message-ID: Date: Wed, 11 Oct 2017 18:46:35 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------875529C010D0A8059FAFF402" Content-Language: en-US Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 09:46:44 -0000 This is a multi-part message in MIME format. --------------875529C010D0A8059FAFF402 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jon, Tiru, > (c1) requests mitigation with an alias-name “alias-1”.  If (s1) does not pass anything extra to (c2) for onward transmission, (s2) sees a single client (c2) requesting mitigation with alias-name “alias-1”.  Fine, that works. > If there was another DOTS client in the same location as (c1)(i.e. c1diff), both using (s1) who also decided to use alias-name “alias-1” who then requests mitigation, (s2) has no idea that there are different “alias-1” definitions if (c2) does not send also an extra differentiator. From the viewpoint of s2, if there is a differentiator of request from c1 and c1diff, it will assist some situation. For example, a retrieval request of existing mitigation list from c2 will get all of the data from s2 if there is no differentiator in the request, however if there is, s2 can return only the related information of specific one. But, I don't think such kind of differentiator is required between c1 and s1, because s1 should identify c1 based on “client identity” which will be certificate of c1 if the mutual authentication is PKI-based. Keeping the binding of “client identity”  and (original)-client-id in signal message is a little bit complicated implementation of s1. Regarding the data-channel, there is a possibility of collision in alias-name among c1, c1diff,,,, so should we need to describe how to bind a data-channel and signal-channel for various mutual authentication patterns like PKI, SPKI, TLS-PKI etc,.. in the draft? regards, Kaname On 2017/10/11 13:38, Konda, Tirumaleswar Reddy wrote: > > Hi Jon, > > Please see inline > > *From:*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Sent:* Wednesday, October 11, 2017 12:44 AM > *To:* Konda, Tirumaleswar Reddy ; kaname nishizuka ; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins > *Subject:* RE: [Dots] DOTS Gateways Challenges > > Hi Tiru, > > I agree that any conflicting request need to be sorted out by the respective DOTS server component – SIG-009 - especially if there are conflicts over IP addresses in the mitigation requests. If (c1) and (c11) whether using alias-name or not do a mitigation request and this create a mitigation conflict, then (s1) needs to sort it out. > > However aliases are set up by the data channel and potentially used by the signal channel at a later time. > > So, if (c1) and (c11) have different client identities, then in my thinking (perhaps naively) that a setup of “alias-1” by (c1) followed later by (c11) also defining the identical alias-name “alias-1” then the alias-names are treated differently by (s1) as it can separately associate “alias-1” with the correct (c1) or (c11).  As (c1n) could be a large number when scaling out, there is an increased chance of 2 or more of the clients at the (c1) level choosing the same alias-name. > > [TR] I don’t think there will be a large number of DOTS clients in a domain, typically a DDoS mitigation system or DDoS detector in a domain will act as DOTS clients (and in future content servers with DDoS detection capability can also act as DOTS clients). > > Why do you think there will be large number of DOTS clients in a domain ? > > [When the mitigation requests come in from (c1) and (c11), using their appropriate alias-name and there is a conflict when the mitigation request is expanded out – this has to be sorted out by (s1). However, I am assuming there is not a conflict in the expanded mitigation request] > > (s1) can handle this by the association of the alias-names with the appropriate (c1n) identity. > > Or are you saying that (s1) has to reject all duplicate alias-names – even though they are coming from different (c1n) entities? > > - this does not scale for me > > - (c11) – goes Huh?!? – I have not previously defined this. What is broken here? > > [TR] c11 has to re-try with a different alias name, RESTCONF (and NETCONF) deals with this problem by returning “data-exists” error response (409 response code). > > Assuming my understanding is correct that the (s1)  can differentiate between alias-names used by different (c1n) clients, when (c2) passes the “alias-1” name upstream without any “extra (c1n info)” information to (s2), (s2) will reject the duplicate ((c2) has passed on the data channel request from (c1) and (c11)) which (c2) then sees and then has to tell (c11) ‘Your request to define “alias-1” failed as it is already defined’.  So again, (c11) – goes Huh?!? – I have not previously defined this. > > I’m missing the point as to why you are concerned about adding in this extra information between (c2) and (s2) – we have plenty of space in the UDP packet – CBOR mapping has done a good data reduction job. > > [TR] Space is not a problem for adding the extra information, my concern is the need to convey the extra information and DOTS gateway not assisting to resolve the same alias-name from different DOTS clients. > > -Tiru > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org ] *On Behalf Of *Konda, Tirumaleswar Reddy > *Sent:* 10 October 2017 16:59 > *To:* Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > *Subject:* Re: [Dots] DOTS Gateways Challenges > > Hi Jon, > > The role of s1 is much more than just forwarding the DOTS client messages, please see (SIG-009 in the requirements drafts), if a DOTS client has used the same alias name previously conveyed by another client then s1 must reject the request. If conflicting requests are resolved by s1 then any response message sent by s3 will be forwarded by s1 to the right DOTS client. > > -Tiru > > *From:*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Sent:* Tuesday, October 10, 2017 8:47 PM > *To:* Konda, Tirumaleswar Reddy >; kaname nishizuka >; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > > *Subject:* RE: [Dots] DOTS Gateways Challenges > > Hi Tiru, > > Then that breaks a signal GET for mitigation status from (c1) (mitigation request uses alias-name) – what gets sent back in the alias-name field when the response that is sent by (s3) when it gets to (c1)? > > I thought we had agreed to leave the alias name – as is – (not substituted) in what is sent back to (c1) from (s1). > > (c1) is not particularly interested in how (c11) is getting mitigated and probably does not want (c11) stats added into his – (s3) need to know how to differentiate between (c1) and (c11) – which is easily done if (c1) (or (c11) information is passed up to (s3), starting with (s1). > > This whole thing needs to be scalable, and I am struggling with how to actually implement your proposal.  Allowing each DOTS GW to learn and pass on something extra that differentiates the DOTS GW immediate clients makes the implementation relatively easy.  There is no need for a DOTS GW to add in additional information if extra information is already embedded – unless he sees a name clash from 2 or more of his uniquely identified DOTS clients – which will be different entities anyway. > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org ] *On Behalf Of *Konda, Tirumaleswar Reddy > *Sent:* 10 October 2017 15:52 > *To:* Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > *Subject:* Re: [Dots] DOTS Gateways Challenges > > The conflicting alias-names from DOTS client (c1) and another client (let’ call (c11)) behind (s1) should be resolved by s1 itself, it is also the responsibility of (s1) to resolve conflicting mitigation requests from (c1) and (c11), aggregate the mitigation requests from the DOTS clients (c1 and c11) and send the updated mitigation request (c2). > > -Tiru > > *From:*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Sent:* Tuesday, October 10, 2017 8:11 PM > *To:* Konda, Tirumaleswar Reddy >; kaname nishizuka >; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > > *Subject:* RE: [Dots] DOTS Gateways Challenges > > Hi Tiru, > > I agree in part, but we need to look at the end (c1) to end (s3) potential issues.  What you are proposing works fine for (s2) to (s3). > > (c1) requests mitigation with an alias-name “alias-1”.  If (s1) does not pass anything extra to (c2) for onward transmission, (s2) sees a single client (c2) requesting mitigation with alias-name “alias-1”.  Fine, that works. > > If there was another DOTS client in the same location as (c1)(i.e. c1diff), both using (s1) who also decided to use alias-name “alias-1” who then requests mitigation, (s2) has no idea that there are different “alias-1” definitions if (c2) does not send also an extra differentiator. > > So, any DOTS GW in the chain should be passing on a “unique-extra” piece of information. > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org ] *On Behalf Of *Konda, Tirumaleswar Reddy > *Sent:* 10 October 2017 15:15 > *To:* Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > *Subject:* Re: [Dots] DOTS Gateways Challenges > > Agree with your response, consider a deployment which has the following DOTS agents. > > DOTS clients (c1) ß----------------à(s1) client-side DOTS gateway (c2) ß------------à(s2) server-side DOTS gateway (c3) ß----------à(s3) DOTS server > > My point is, (c2) need not convey the “c1 identity” to (s2) but (s2) needs to convey the “c2 identity” to (c3) and (c3) in-turn propagates the “c2 identity” to (s3). > > -Tiru > > *From:*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Sent:* Tuesday, October 10, 2017 6:15 PM > *To:* Konda, Tirumaleswar Reddy >; kaname nishizuka >; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > > *Subject:* RE: [Dots] DOTS Gateways Challenges > > Hi Tiru, > > Agreed that only a DOTS GW server facing needs to send information to the upstream DOTS Server – which could also be a DOTS GW. > >                        +-------------+ > > |    | D |    | > >          +----+ |    | O |    |         +----+ > >          | c1 |----------| s1 | T | c2 |---------| s2 | > >          +----+      |    | S |    |         +----+ > > |    | G |    | > > +-------------+ > > https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-2.2.3 > > However, the DOTS GW client facing (s1) is the one with knowledge of the individual clients that are currently using  the DOTS server running on the DOTS GW.  This information has to somehow be passed over to the DOTS GW server facing (c2), but separate DOTS stacks are being run for (s1) and (c2) as per architecture spec 2.2.3.  I was referring to what (s1) may need to pass on to (c2) in my email response to Kaname, not what is sent by (c1). > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org ] *On Behalf Of *Konda, Tirumaleswar Reddy > *Sent:* 10 October 2017 13:16 > *To:* Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > *Subject:* Re: [Dots] DOTS Gateways Challenges > > I thought we agreed that based on the current DOTS requirements only the server-side DOTS GW needs to convey the DOTS client (or client-side DOTS WG) identity to the DOTS server. > > -Tiru > > *From:*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Sent:* Tuesday, October 10, 2017 2:53 PM > *To:* 'kaname nishizuka' >; Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > > *Subject:* RE: [Dots] DOTS Gateways Challenges > > Hi Kaname, > > I do not think that information necessarily needs to be the original client identity.  The GW Client side will have its own identity which the DOTS Server can use to differentiate between DOTS (GW) Clients. > > So, yes, a hashed set of names can be used – it is up to the DOTS GW Client side to make sure that there are no hash collisions.  Or it could be a simple list such as C1, C2 …Cn. > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org ] *On Behalf Of *kaname nishizuka > *Sent:* 10 October 2017 04:19 > *To:* Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > *Subject:* Re: [Dots] DOTS Gateways Challenges > > Hi, > > > I agree the below problems are applicable for server-side DOTS gateway, it must convey the “client identity” to the DOTS server. > I agree with this server-side DOTS gateway case. > At the same time, I agree with below: > > I agree that is not a good thing to “leak” out internal information when passing through a DOTS GW, > > Then, should DOTS GW send “client identity” (i.e. certificates of DOTS clients) itself or hashed(“client identity”) to DOTS server? > If later, how can DOTS server react to the ambiguous information of the hashed(“client identity”). > > regards, > Kaname > > On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote: > > Hi Jon, > > I agree the below problems are applicable for server-side DOTS gateway, it must convey the “client identity” to the DOTS server. But for the client-side DOTS gateway, it should resolve conflicting rules b/w DOTS clients (e.g. one client installing black-list ACL for an IP address but the other client installs white-list ACL for the same IP address, same alias-names for different mitigation scopes). I don’t see the need for a client-side DOTS gateway to convey the “client identity” to the server-side DOTS gateway or DOTS server. > > -Tiru > > *From:*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Sent:* Saturday, October 7, 2017 2:07 PM > *To:* Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > *Subject:* RE: [Dots] DOTS Gateways Challenges > > Hi Tiru, > > This discussion goes beyond just the mitigation request.  We need to consider what happens with both alias-name and acl-name (data channel) > > The simple case of a mitigation request with no alias-name does not require any knowledge of the original client. > > However, if the mitigation request uses alias-name, then there are 3 ways of handling this > > a)The DOTS GW replaces the alias-name with its actual definition (target-ips etc. merged as appropriate), so alias-name is not forwarded on to Server – just the expanded mitigation request is forwarded > > b)The DOTS GW updates the alias-name with a unique alias-name that is forwarded (and has to do the same thing when the alias-name is configured on the data channel) – to handle 2 or more clients defining the same alias-name which have different characteristics > > c)The DOTS GW recognises that alias-name is not unique and adds in ”additional-client-info” (I think I prefer this “-info” name to client-id or original-client-id as “-id” is too closely  associated with Client Identity derived from the DOTS GW Client certificate) > > We have agreed that when a client requests mitigation status, the “alias-name” should be returned as “alias-name” and not the substituted alias-name configuration (this does need to be stated in the spec for clarity).  This makes (a) difficult to be handled by DOTS GW which then raises the question – do we really need alias-name? > > The definition and association of ACLs/Filters of the data channel is more difficult – the Server must install / apply the appropriate ACLs on a per (Original) Client basis when mitigation is invoked. > > Client 1’s concept of a Whitelist IP could be Client 2’s concept of a Blacklist IP.  The Server needs to know which client is requesting the mitigation and install the correct ACLs – if there was no ”additional-client-info”, the Server only knows that he has to install ALL of the ACLs (i.e. both the Black and White list of the same IP as defined by Client 1 and Client 2) as defined by his client (DOTS GW) when his client requests a mitigation.  Here, I think that if there is more than one client for the DOTS GW, ”additional-client-info” is required. > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org ] *On Behalf Of *Konda, Tirumaleswar Reddy > *Sent:* 07 October 2017 04:28 > *To:* Jon Shallow; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > *Subject:* Re: [Dots] DOTS Gateways Challenges > > In case of client-side DOTS gateway, why does the DOTS server need to know which “DOTS client” has conveyed the mitigation request ? > > For example, the DOTS client could be a DDoS detector or an Application server, and the client-side gateway will have to resolve the conflicting mitigation requests from the DOTS clients, aggregate the mitigation requests from the DOTS client and send the updated mitigation request to the DOTS server. > > -Tiru > > *From:*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Sent:* Friday, October 6, 2017 7:42 PM > *To:* Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com ; dots@ietf.org ; Roland Dobbins > > *Subject:* RE: [Dots] DOTS Gateways Challenges > > Hi Tiru, > > Unless I am missing something, how does the Client side of DOTS GW convey to the upstream server a unique “client-id” which is different to the implied client id as derived from the PKI certificate that the DOTS GW’Client uses/presents when communicating to the server? > > To me, there needs to be an option such as “original-client-id” or “client-id” (which is confusing when also referring to the client identity as derived from the (DOTS GW) Client’s PKI certificate) as a part of the protocol. > > I agree that the DOTS GW can generate its own unique client-id to stop multiple entries being needed. > > I agree that is not a good thing to “leak” out internal information when passing through a DOTS GW, so my REQUIRED does not make sense. > > Regards > > Jon > > PS – I am having to deal with other stuff at present – I will get back later on the other issues under discussion > > *From:*Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com ] > *Sent:* 06 October 2017 14:58 > *To:* mohamed.boucadair@orange.com ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org > *Subject:* RE: [Dots] DOTS Gateways Challenges > > I don’t see a need for client-side DOTS gateway to convey the “DOTS client identity” to the DOTS server. “DOTS client identity” looks required only for the server-side DOTS gateways. In case of server-side DOTS gateway, it can convey the client-id generated from the “DOTS client identity” to the DOTS server. The DOTS gateway can generate a unique client-id and does not have to send an array of client-ids to the DOTS server to resolve clashes. > > -Tiru > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------875529C010D0A8059FAFF402 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Jon, Tiru,

> (c1) requests mitigation with an alias-name “alias-1”.  If (s1) does not pass anything extra to (c2) for onward transmission, (s2) sees a single client (c2) requesting mitigation with alias-name “alias-1”.  Fine, that works.
> If there was another DOTS client in the same location as (c1)(i.e. c1diff), both using (s1) who also decided to use alias-name “alias-1” who then requests mitigation, (s2) has no idea that there are different “alias-1” definitions if (c2) does not send also an extra differentiator.

From the viewpoint of s2, if there is a differentiator of request from c1 and c1diff, it will assist some situation. For example, a retrieval request of existing mitigation list from c2 will get all of the data from s2 if there is no differentiator in the request, however if there is, s2 can return only the related information of specific one.
But, I don't think such kind of differentiator is required between c1 and s1, because s1 should identify c1 based on “client identity” which will be certificate of c1 if the mutual authentication is PKI-based. Keeping the binding of “client identity”  and (original)-client-id in signal message is a little bit complicated implementation of s1.

Regarding the data-channel, there is a possibility of collision in alias-name among c1, c1diff,,,, so should we need to describe how to bind a data-channel and signal-channel for various mutual authentication patterns like PKI, SPKI, TLS-PKI etc,.. in the draft?

regards,
Kaname


On 2017/10/11 13:38, Konda, Tirumaleswar Reddy wrote:

Hi Jon,

 

Please see inline

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Wednesday, October 11, 2017 12:44 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins <rdobbins@arbor.net>
Subject: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

I agree that any conflicting request need to be sorted out by the respective DOTS server component – SIG-009 - especially if there are conflicts over IP addresses in the mitigation requests. If (c1) and (c11) whether using alias-name or not do a mitigation request and this create a mitigation conflict, then (s1) needs to sort it out.

 

However aliases are set up by the data channel and potentially used by the signal channel at a later time.

 

So, if (c1) and (c11) have different client identities, then in my thinking (perhaps naively) that a setup of “alias-1” by (c1) followed later by (c11) also defining the identical alias-name “alias-1” then the alias-names are treated differently by (s1) as it can separately associate “alias-1” with the correct (c1) or (c11).  As (c1n) could be a large number when scaling out, there is an increased chance of 2 or more of the clients at the (c1) level choosing the same alias-name.

 

[TR] I don’t think there will be a large number of DOTS clients in a domain, typically a DDoS mitigation system or DDoS detector in a domain will act as DOTS clients (and in future content servers with DDoS detection capability can also act as DOTS clients).  

 

Why do you think there will be large number of DOTS clients in a domain ?

 

[When the mitigation requests come in from (c1) and (c11), using their appropriate alias-name and there is a conflict when the mitigation request is expanded out – this has to be sorted out by (s1).  However, I am assuming there is not a conflict in the expanded mitigation request]

 

(s1) can handle this by the association of the alias-names with the appropriate (c1n) identity.

 

Or are you saying that (s1) has to reject all duplicate alias-names – even though they are coming from different (c1n) entities?

- this does not scale for me

- (c11) – goes Huh?!? – I have not previously defined this. What is broken here ?

 

[TR] c11 has to re-try with a different alias name, RESTCONF (and NETCONF) deals with this problem by returning “data-exists” error response (409 response code).

 

Assuming my understanding is correct that the (s1)  can differentiate between alias-names used by different (c1n) clients, when (c2) passes the “alias-1” name upstream without any “extra (c1n info)” information to (s2), (s2) will reject the duplicate ((c2) has passed on the data channel request from (c1) and (c11)) which (c2) then sees and then has to tell (c11) ‘Your request to define “alias-1” failed as it is already defined’.  So again, (c11) – goes Huh?!? – I have not previously defined this.

 

I’m missing the point as to why you are concerned about adding in this extra information between (c2) and (s2) – we have plenty of space in the UDP packet – CBOR mapping has done a good data reduction job.

 

[TR] Space is not a problem for adding the extra information, my concern is the need to convey the extra information and DOTS gateway not assisting to resolve the same alias-name from different DOTS clients.

 

-Tiru

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 16:59
To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

 

Hi Jon,

 

The role of s1 is much more than just forwarding the DOTS client messages, please see (SIG-009 in the requirements drafts), if a DOTS client has used the same alias name previously conveyed by another client then s1 must reject the request. If conflicting requests are resolved by s1 then any response message sent by s3 will be forwarded by s1 to the right DOTS client.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, October 10, 2017 8:47 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins <rdobbins@arbor.net>
Subject: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

Then that breaks a signal GET for mitigation status from (c1) (mitigation request uses alias-name) – what gets sent back in the alias-name field when the response that is sent by (s3) when it gets to (c1)?

 

I thought we had agreed to leave the alias name – as is – (not substituted) in what is sent back to (c1) from (s1).

 

(c1) is not particularly interested in how (c11) is getting mitigated and probably does not want (c11) stats added into his – (s3) need to know how to differentiate between (c1) and (c11) – which is easily done if (c1) (or (c11) information is passed up to (s3), starting with (s1).

 

This whole thing needs to be scalable, and I am struggling with how to actually implement your proposal.  Allowing each DOTS GW to learn and pass on something extra that differentiates the DOTS GW immediate clients makes the implementation relatively easy.  There is no need for a DOTS GW to add in additional information if extra information is already embedded – unless he sees a name clash from 2 or more of his uniquely identified DOTS clients – which will be different entities anyway.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 15:52
To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

 

The conflicting alias-names from DOTS client (c1) and another client (let’ call (c11)) behind (s1) should be resolved by s1 itself, it is also the responsibility of (s1) to resolve conflicting mitigation requests from (c1) and (c11), aggregate the mitigation requests from the DOTS clients (c1 and c11) and send the updated mitigation request (c2).

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, October 10, 2017 8:11 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins <rdobbins@arbor.net>
Subject: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

I agree in part, but we need to look at the end (c1) to end (s3) potential issues.  What you are proposing works fine for (s2) to (s3).

 

(c1) requests mitigation with an alias-name “alias-1”.  If (s1) does not pass anything extra to (c2) for onward transmission, (s2) sees a single client (c2) requesting mitigation with alias-name “alias-1”.  Fine, that works.

If there was another DOTS client in the same location as (c1)(i.e. c1diff), both using (s1) who also decided to use alias-name “alias-1” who then requests mitigation, (s2) has no idea that there are different “alias-1” definitions if (c2) does not send also an extra differentiator.

 

So, any DOTS GW in the chain should be passing on a “unique-extra” piece of information.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 15:15
To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

 

Agree with your response, consider a deployment which has the following DOTS agents.

 

DOTS clients (c1) ß----------------à (s1) client-side DOTS gateway (c2) ß------------à (s2) server-side DOTS gateway (c3) ß----------à (s3) DOTS server

 

My point is, (c2) need not convey the “c1 identity” to (s2) but (s2) needs to convey the “c2 identity” to (c3) and (c3) in-turn propagates the “c2 identity” to (s3).

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, October 10, 2017 6:15 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins <rdobbins@arbor.net>
Subject: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

Agreed that only a DOTS GW server facing needs to send information to the upstream DOTS Server – which could also be a DOTS GW.

                         +-------------+

                         |    | D |    |

         +----+          |    | O |    |         +----+

         | c1 |----------| s1 | T | c2 |---------| s2 |

         +----+          |    | S |    |         +----+

                         |    | G |    |

                         +-------------+

https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-2.2.3

 

However, the DOTS GW client facing (s1) is the one with knowledge of the individual clients that are currently using  the DOTS server running on the DOTS GW.  This information has to somehow be passed over to the DOTS GW server facing (c2), but separate DOTS stacks are being run for (s1) and (c2) as per architecture spec 2.2.3.  I was referring to what (s1) may need to pass on to (c2) in my email response to Kaname, not what is sent by (c1).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 13:16
To: Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

 

I thought we agreed that based on the current DOTS requirements only the server-side DOTS GW needs to convey the DOTS client (or client-side DOTS WG) identity to the DOTS server.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, October 10, 2017 2:53 PM
To: 'kaname nishizuka' <kaname@nttv6.jp>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins <rdobbins@arbor.net>
Subject: RE: [Dots] DOTS Gateways Challenges

 

Hi Kaname,

 

I do not think that information necessarily needs to be the original client identity.  The GW Client side will have its own identity which the DOTS Server can use to differentiate between DOTS (GW) Clients.

 

So, yes, a hashed set of names can be used – it is up to the DOTS GW Client side to make sure that there are no hash collisions.  Or it could be a simple list such as C1, C2 …Cn.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka
Sent: 10 October 2017 04:19
To: Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

 

Hi,

> I agree the below problems are applicable for server-side DOTS gateway, it must convey the “client identity” to the DOTS server.
I agree with this server-side DOTS gateway case.
At the same time, I agree with below:
> I agree that is not a good thing to “leak” out internal information when passing through a DOTS GW,

Then, should DOTS GW send “client identity” (i.e. certificates of DOTS clients) itself or hashed(“client identity”) to DOTS server?
If later, how can DOTS server react to the ambiguous information of the hashed(“client identity”).

regards,
Kaname

On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote:

Hi Jon,

 

I agree the below problems are applicable for server-side DOTS gateway, it must convey the “client identity” to the DOTS server. But for the client-side DOTS gateway, it should resolve conflicting rules b/w DOTS clients (e.g. one client installing black-list ACL for an IP address but the other client installs white-list ACL for the same IP address, same alias-names for different mitigation scopes). I don’t see the need for a client-side DOTS gateway to convey the “client identity” to the server-side DOTS gateway or DOTS server.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Saturday, October 7, 2017 2:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins <rdobbins@arbor.net>
Subject: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We need to consider what happens with both alias-name and acl-name (data channel)

 

The simple case of a mitigation request with no alias-name does not require any knowledge of the original client. 

 

However, if the mitigation request uses alias-name, then there are 3 ways of handling this

a)       The DOTS GW replaces the alias-name with its actual definition (target-ips etc. merged as appropriate), so alias-name is not forwarded on to Server – just the expanded mitigation request is forwarded

b)      The DOTS GW updates the alias-name with a unique alias-name that is forwarded (and has to do the same thing when the alias-name is configured on the data channel) – to handle 2 or more clients defining the same alias-name which have different characteristics

c)       The DOTS GW recognises that alias-name is not unique and adds in ”additional-client-info” (I think I prefer this “-info” name to client-id or original-client-id as “-id” is too closely  associated with Client Identity derived from the DOTS GW Client certificate)

We have agreed that when a client requests mitigation status, the “alias-name” should be returned as “alias-name” and not the substituted alias-name configuration (this does need to be stated in the spec for clarity).  This makes (a) difficult to be handled by DOTS GW which then raises the question – do we really need alias-name?

 

The definition and association of ACLs/Filters of the data channel is more difficult – the Server must install / apply the appropriate ACLs on a per (Original) Client basis when mitigation is invoked.

Client 1’s concept of a Whitelist IP could be Client 2’s concept of a Blacklist IP.  The Server needs to know which client is requesting the mitigation and install the correct ACLs – if there was no ”additional-client-info”, the Server only knows that he has to install ALL of the ACLs (i.e. both the Black and White list of the same IP as defined by Client 1 and Client 2) as defined by his client (DOTS GW) when his client requests a mitigation.  Here, I think that if there is more than one client for the DOTS GW, ”additional-client-info” is required.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 04:28
To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS Gateways Challenges

 

In case of client-side DOTS gateway, why does the DOTS server need to know which “DOTS client” has conveyed the mitigation request ?

For example, the DOTS client could be a DDoS detector or an Application server, and the client-side gateway will have to resolve the conflicting mitigation requests from the DOTS clients, aggregate the mitigation requests from the DOTS client and send the updated mitigation request to the DOTS server.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, October 6, 2017 7:42 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins <rdobbins@arbor.net>
Subject: RE: [Dots] DOTS Gateways Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW convey to the upstream server a unique “client-id” which is different to the implied client id as derived from the PKI certificate that the DOTS GW’Client uses/presents when communicating to the server?

To me, there needs to be an option such as “original-client-id” or “client-id” (which is confusing when also referring to the client identity as derived from the (DOTS GW) Client’s PKI certificate) as a part of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to stop multiple entries being needed.

 

I agree that is not a good thing to “leak” out internal information when passing through a DOTS GW, so my REQUIRED does not make sense.

 

Regards

 

Jon

PS – I am having to deal with other stuff at present – I will get back later on the other issues under discussion

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 06 October 2017 14:58
To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: [Dots] DOTS Gateways Challenges

 

I don’t see a need for client-side DOTS gateway to convey the “DOTS client identity” to the DOTS server. “DOTS client identity” looks required only for the server-side DOTS gateways. In case of server-side DOTS gateway, it can convey the client-id generated from the “DOTS client identity” to the DOTS server. The DOTS gateway can generate a unique client-id and does not have to send an array of client-ids to the DOTS server to resolve clashes.

 

-Tiru

 

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

 



_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--------------875529C010D0A8059FAFF402-- From nobody Wed Oct 11 04:08:15 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5413F13331E for ; Wed, 11 Oct 2017 04:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pewGY_6jsQp8 for ; Wed, 11 Oct 2017 04:08:10 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 B6A54133347 for ; Wed, 11 Oct 2017 04:08:09 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e2Ert-00041A-DG; Wed, 11 Oct 2017 12:08:05 +0100 From: "Jon Shallow" To: "'kaname nishizuka'" , "Konda, Tirumaleswar Reddy" , , , "Roland Dobbins" References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> <0df701d341d5$cfd88770$6f89 9650$@jpshallow.com> <0e3501d341da$cf9e4b50$6edae1f0$@jpshallow.com> <0e7b01d341fb$ea576870$bf063950$@jpshallow.com> In-Reply-To: Date: Wed, 11 Oct 2017 12:08:06 +0100 Message-ID: <006901d34281$371abd30$a5503790$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01D34289.98E3E020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgzl8+nHMNWZrqCTpjFVzkmKHEFgEkXvV/Aa4u2RoDGJQaWgKHunMTAVXPogkCkQedmgENZkAbAoGS4ccDYjzDEAGmdkEfAfX8xD8CH/sSFwJKp7IeAe4dfiUBhQIspqJNM4yg Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 11:08:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006A_01D34289.98E3E020 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kaname / Tiru, =20 See inline =E2=80=93 [Jon1] 3 in Kanama=E2=80=99s response and 3 in = Tiru=E2=80=99s response. =20 Regards =20 Jon =20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 11 October 2017 10:47 To: Konda, Tirumaleswar Reddy; Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi Jon, Tiru, > (c1) requests mitigation with an alias-name =E2=80=9Calias-1=E2=80=9D. = If (s1) does not pass anything extra to (c2) for onward transmission, = (s2) sees a single client (c2) requesting mitigation with alias-name = =E2=80=9Calias-1=E2=80=9D. Fine, that works. > If there was another DOTS client in the same location as (c1)(i.e. = c1diff), both using (s1) who also decided to use alias-name = =E2=80=9Calias-1=E2=80=9D who then requests mitigation, (s2) has no idea = that there are different =E2=80=9Calias-1=E2=80=9D definitions if (c2) = does not send also an extra differentiator.=20 >From the viewpoint of s2, if there is a differentiator of request from = c1 and c1diff, it will assist some situation. For example, a retrieval = request of existing mitigation list from c2 will get all of the data = from s2 if there is no differentiator in the request, however if there = is, s2 can return only the related information of specific one. [Jon1] Agreed. But, I don't think such kind of differentiator is required between c1 = and s1, because s1 should identify c1 based on =E2=80=9Cclient = identity=E2=80=9D which will be certificate of c1 if the mutual = authentication is PKI-based. Keeping the binding of =E2=80=9Cclient = identity=E2=80=9D and (original)-client-id in signal message is a = little bit complicated implementation of s1. [Jon1] Agreed =E2=80=93 but (s2) and (s3) will have to do this. Regarding the data-channel, there is a possibility of collision in = alias-name among c1, c1diff,,,, so should we need to describe how to = bind a data-channel and signal-channel for various mutual authentication = patterns like PKI, SPKI, TLS-PKI etc,.. in the draft?=20 [Jon1] In my current implementation, alias-name (whether data or signal = channel) is associated with a client-id (and possibly = =E2=80=9Cextra-client-info=E2=80=9D (not yet coded)). The decision here = is whether we have a single pool of alias-names (and ACLs) on a DOTS = server, or each DOTS server (standalone or in a GW) maintains separate = lists =E2=80=93 one per client-id. And this should be stated in the = specs for clarity. regards, Kaname On 2017/10/11 13:38, Konda, Tirumaleswar Reddy wrote: Hi Jon, =20 Please see inline=20 =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Wednesday, October 11, 2017 12:44 AM To: Konda, Tirumaleswar Reddy = = ; kaname nishizuka = ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 I agree that any conflicting request need to be sorted out by the = respective DOTS server component =E2=80=93 SIG-009 - especially if there = are conflicts over IP addresses in the mitigation requests. If (c1) and = (c11) whether using alias-name or not do a mitigation request and this = create a mitigation conflict, then (s1) needs to sort it out. =20 However aliases are set up by the data channel and potentially used by = the signal channel at a later time. =20 So, if (c1) and (c11) have different client identities, then in my = thinking (perhaps naively) that a setup of =E2=80=9Calias-1=E2=80=9D by = (c1) followed later by (c11) also defining the identical alias-name = =E2=80=9Calias-1=E2=80=9D then the alias-names are treated differently = by (s1) as it can separately associate =E2=80=9Calias-1=E2=80=9D with = the correct (c1) or (c11). As (c1n) could be a large number when = scaling out, there is an increased chance of 2 or more of the clients at = the (c1) level choosing the same alias-name. =20 [TR] I don=E2=80=99t think there will be a large number of DOTS clients = in a domain, typically a DDoS mitigation system or DDoS detector in a = domain will act as DOTS clients (and in future content servers with DDoS = detection capability can also act as DOTS clients). =20 =20 Why do you think there will be large number of DOTS clients in a domain = ? [Jon1] One of my customers has over 100 of his customers that are = separately protected and each of these customers would be considered a = (c1) instance. Expand this out to a broadband network of home routers = and the numbers get very large. See 3.1.8 and 3.2.2 in dots use cases = spec. =20 [When the mitigation requests come in from (c1) and (c11), using their = appropriate alias-name and there is a conflict when the mitigation = request is expanded out =E2=80=93 this has to be sorted out by (s1). = However, I am assuming there is not a conflict in the expanded = mitigation request] =20 (s1) can handle this by the association of the alias-names with the = appropriate (c1n) identity. =20 Or are you saying that (s1) has to reject all duplicate alias-names = =E2=80=93 even though they are coming from different (c1n) entities? - this does not scale for me - (c11) =E2=80=93 goes Huh?!? =E2=80=93 I have not previously defined = this. What is broken here ? =20 [TR] c11 has to re-try with a different alias name, RESTCONF (and = NETCONF) deals with this problem by returning = =E2=80=9Cdata-exists=E2=80=9D error response (409 response code).=20 =20 Assuming my understanding is correct that the (s1) can differentiate = between alias-names used by different (c1n) clients, when (c2) passes = the =E2=80=9Calias-1=E2=80=9D name upstream without any =E2=80=9Cextra = (c1n info)=E2=80=9D information to (s2), (s2) will reject the duplicate = ((c2) has passed on the data channel request from (c1) and (c11)) which = (c2) then sees and then has to tell (c11) =E2=80=98Your request to = define =E2=80=9Calias-1=E2=80=9D failed as it is already = defined=E2=80=99. So again, (c11) =E2=80=93 goes Huh?!? =E2=80=93 I = have not previously defined this. =20 I=E2=80=99m missing the point as to why you are concerned about adding = in this extra information between (c2) and (s2) =E2=80=93 we have plenty = of space in the UDP packet =E2=80=93 CBOR mapping has done a good data = reduction job. =20 [TR] Space is not a problem for adding the extra information, my concern = is the need to convey the extra information and DOTS gateway not = assisting to resolve the same alias-name from different DOTS clients. [Jon1] I think we need this (optional) extra information that any DOTS = GW server side can send upstream. Allowing (c3) to do this, but not = (c2) makes no sense to me. To me, it is a requirement that DOTS GW = resolves conflicts, does data reduction etc. whenever it can to reduce = upstream traffic. =20 [Jon1] I still believe that (s3) has to maintain separation of (c1) and = (c11) information (alias-names, ACLs and mitigation requests). So, when = (c11) askes for his mitigation status, he gets only data relevant to = him. =20 -Tiru =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 16:59 To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi Jon, =20 The role of s1 is much more than just forwarding the DOTS client = messages, please see (SIG-009 in the requirements drafts), if a DOTS = client has used the same alias name previously conveyed by another = client then s1 must reject the request. If conflicting requests are = resolved by s1 then any response message sent by s3 will be forwarded by = s1 to the right DOTS client. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 8:47 PM To: Konda, Tirumaleswar Reddy ; = kaname nishizuka ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Then that breaks a signal GET for mitigation status from (c1) = (mitigation request uses alias-name) =E2=80=93 what gets sent back in = the alias-name field when the response that is sent by (s3) when it gets = to (c1)? =20 I thought we had agreed to leave the alias name =E2=80=93 as is = =E2=80=93 (not substituted) in what is sent back to (c1) from (s1). =20 (c1) is not particularly interested in how (c11) is getting mitigated = and probably does not want (c11) stats added into his =E2=80=93 (s3) = need to know how to differentiate between (c1) and (c11) =E2=80=93 which = is easily done if (c1) (or (c11) information is passed up to (s3), = starting with (s1). =20 This whole thing needs to be scalable, and I am struggling with how to = actually implement your proposal. Allowing each DOTS GW to learn and = pass on something extra that differentiates the DOTS GW immediate = clients makes the implementation relatively easy. There is no need for = a DOTS GW to add in additional information if extra information is = already embedded =E2=80=93 unless he sees a name clash from 2 or more of = his uniquely identified DOTS clients =E2=80=93 which will be different = entities anyway. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 15:52 To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 The conflicting alias-names from DOTS client (c1) and another client = (let=E2=80=99 call (c11)) behind (s1) should be resolved by s1 itself, = it is also the responsibility of (s1) to resolve conflicting mitigation = requests from (c1) and (c11), aggregate the mitigation requests from the = DOTS clients (c1 and c11) and send the updated mitigation request (c2). =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 8:11 PM To: Konda, Tirumaleswar Reddy ; = kaname nishizuka ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 I agree in part, but we need to look at the end (c1) to end (s3) = potential issues. What you are proposing works fine for (s2) to (s3). =20 (c1) requests mitigation with an alias-name =E2=80=9Calias-1=E2=80=9D. = If (s1) does not pass anything extra to (c2) for onward transmission, = (s2) sees a single client (c2) requesting mitigation with alias-name = =E2=80=9Calias-1=E2=80=9D. Fine, that works. If there was another DOTS client in the same location as (c1)(i.e. = c1diff), both using (s1) who also decided to use alias-name = =E2=80=9Calias-1=E2=80=9D who then requests mitigation, (s2) has no idea = that there are different =E2=80=9Calias-1=E2=80=9D definitions if (c2) = does not send also an extra differentiator.=20 =20 So, any DOTS GW in the chain should be passing on a = =E2=80=9Cunique-extra=E2=80=9D piece of information. =20 Regards =20 Jon=20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 15:15 To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Agree with your response, consider a deployment which has the following = DOTS agents. =20 DOTS clients (c1) =C3=9F----------------=C3=A0 (s1) client-side DOTS = gateway (c2) =C3=9F------------=C3=A0 (s2) server-side DOTS gateway (c3) = =C3=9F----------=C3=A0 (s3) DOTS server =20 My point is, (c2) need not convey the =E2=80=9Cc1 identity=E2=80=9D to = (s2) but (s2) needs to convey the =E2=80=9Cc2 identity=E2=80=9D to (c3) = and (c3) in-turn propagates the =E2=80=9Cc2 identity=E2=80=9D to (s3). =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 6:15 PM To: Konda, Tirumaleswar Reddy ; = kaname nishizuka ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Agreed that only a DOTS GW server facing needs to send information to = the upstream DOTS Server =E2=80=93 which could also be a DOTS GW. +-------------+ | | D | | +----+ | | O | | +----+ | c1 |----------| s1 | T | c2 |---------| s2 | +----+ | | S | | +----+ | | G | | +-------------+ https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-2.2.3= =20 However, the DOTS GW client facing (s1) is the one with knowledge of the = individual clients that are currently using the DOTS server running on = the DOTS GW. This information has to somehow be passed over to the DOTS = GW server facing (c2), but separate DOTS stacks are being run for (s1) = and (c2) as per architecture spec 2.2.3. I was referring to what (s1) = may need to pass on to (c2) in my email response to Kaname, not what is = sent by (c1). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 13:16 To: Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 I thought we agreed that based on the current DOTS requirements only the = server-side DOTS GW needs to convey the DOTS client (or client-side DOTS = WG) identity to the DOTS server.=20 =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, October 10, 2017 2:53 PM To: 'kaname nishizuka' ; Konda, Tirumaleswar Reddy = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Kaname, =20 I do not think that information necessarily needs to be the original = client identity. The GW Client side will have its own identity which = the DOTS Server can use to differentiate between DOTS (GW) Clients. =20 So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash collisions. Or = it could be a simple list such as C1, C2 =E2=80=A6Cn. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 10 October 2017 04:19 To: Konda, Tirumaleswar Reddy; Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 Hi, > I agree the below problems are applicable for server-side DOTS = gateway, it must convey the =E2=80=9Cclient identity=E2=80=9D to the = DOTS server.=20 I agree with this server-side DOTS gateway case. At the same time, I agree with below: > I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW,=20 Then, should DOTS GW send =E2=80=9Cclient identity=E2=80=9D (i.e. = certificates of DOTS clients) itself or hashed(=E2=80=9Cclient = identity=E2=80=9D) to DOTS server? If later, how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient identity=E2=80=9D). regards, Kaname On 2017/10/09 22:34, Konda, Tirumaleswar Reddy wrote: Hi Jon, =20 I agree the below problems are applicable for server-side DOTS gateway, = it must convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. = But for the client-side DOTS gateway, it should resolve conflicting = rules b/w DOTS clients (e.g. one client installing black-list ACL for an = IP address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Saturday, October 7, 2017 2:07 PM To: Konda, Tirumaleswar Reddy = = ; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 This discussion goes beyond just the mitigation request. We need to = consider what happens with both alias-name and acl-name (data channel) =20 The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client. =20 =20 However, if the mitigation request uses alias-name, then there are 3 = ways of handling this a) The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is forwarded b) The DOTS GW updates the alias-name with a unique alias-name that = is forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different characteristics c) The DOTS GW recognises that alias-name is not unique and adds = in =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely associated with Client Identity = derived from the DOTS GW Client certificate) We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for clarity). = This makes (a) difficult to be handled by DOTS GW which then raises the = question =E2=80=93 do we really need alias-name? =20 The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is invoked. Client 1=E2=80=99s concept of a Whitelist IP could be Client 2=E2=80=99s = concept of a Blacklist IP. The Server needs to know which client is = requesting the mitigation and install the correct ACLs =E2=80=93 if = there was no =E2=80=9Dadditional-client-info=E2=80=9D, the Server only = knows that he has to install ALL of the ACLs (i.e. both the Black and = White list of the same IP as defined by Client 1 and Client 2) as = defined by his client (DOTS GW) when his client requests a mitigation. = Here, I think that if there is more than one client for the DOTS GW, = =E2=80=9Dadditional-client-info=E2=80=9D is required. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 07 October 2017 04:28 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: Re: [Dots] DOTS Gateways Challenges =20 In case of client-side DOTS gateway, why does the DOTS server need to = know which =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation = request ? For example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 6, 2017 7:42 PM To: Konda, Tirumaleswar Reddy ; = mohamed.boucadair@orange.com; dots@ietf.org; Roland Dobbins = Subject: RE: [Dots] DOTS Gateways Challenges =20 Hi Tiru, =20 Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server? To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol. =20 I agree that the DOTS GW can generate its own unique client-id to stop = multiple entries being needed. =20 I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out internal = information when passing through a DOTS GW, so my REQUIRED does not make = sense. =20 Regards =20 Jon PS =E2=80=93 I am having to deal with other stuff at present =E2=80=93 I = will get back later on the other issues under discussion =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]=20 Sent: 06 October 2017 14:58 To: mohamed.boucadair@orange.com; Jon Shallow; 'Dobbins, Roland'; = dots@ietf.org Subject: RE: [Dots] DOTS Gateways Challenges =20 I don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.=20 =20 -Tiru =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_006A_01D34289.98E3E020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Kaname / Tiru,

 

See inline =E2=80=93 [Jon1] 3 in Kanama=E2=80=99s response and 3 in = Tiru=E2=80=99s response.

 

Regards

 

Jon

 

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname = nishizuka
Sent: 11 October 2017 10:47
To: Konda, = Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org; Roland Dobbins
Subject: Re: [Dots] DOTS = Gateways Challenges

 

Hi Jon, Tiru,

> (c1) requests = mitigation with an alias-name =E2=80=9Calias-1=E2=80=9D.  If (s1) = does not pass anything extra to (c2) for onward transmission, (s2) sees = a single client (c2) requesting mitigation with alias-name = =E2=80=9Calias-1=E2=80=9D.  Fine, that works.
> If there was = another DOTS client in the same location as (c1)(i.e. c1diff), both = using (s1) who also decided to use alias-name =E2=80=9Calias-1=E2=80=9D = who then requests mitigation, (s2) has no idea that there are different = =E2=80=9Calias-1=E2=80=9D definitions if (c2) does not send also an = extra differentiator.

From the viewpoint of s2, if there is a = differentiator of request from c1 and c1diff, it will assist some = situation. For example, a retrieval request of existing mitigation list = from c2 will get all of the data from s2 if there is no differentiator = in the request, however if there is, s2 can return only the related = information of specific one.

[Jon1] Agreed.


But, I don't think such kind of = differentiator is required between c1 and s1, because s1 should identify = c1 based on =E2=80=9Cclient identity=E2=80=9D which will be certificate = of c1 if the mutual authentication is PKI-based. Keeping the binding of = =E2=80=9Cclient identity=E2=80=9D  and (original)-client-id in = signal message is a little bit complicated implementation of s1.

[Jon1] Agreed =E2=80=93 but (s2) and (s3) will have to do = this.


Regarding the data-channel, there is = a possibility of collision in alias-name among c1, c1diff,,,, so should = we need to describe how to bind a data-channel and signal-channel for = various mutual authentication patterns like PKI, SPKI, TLS-PKI etc,.. in = the draft?

[Jon1] In my current implementation, alias-name (whether data or = signal channel) is associated with a client-id (and possibly = =E2=80=9Cextra-client-info=E2=80=9D (not yet coded)).=C2=A0 The decision = here is whether we have a single pool of alias-names (and ACLs) on a = DOTS server, or each DOTS server (standalone or in a GW) maintains = separate lists =E2=80=93 one per client-id.=C2=A0 And this should be = stated in the specs for = clarity.

regards,
Kaname

On 2017/10/11 13:38, = Konda, Tirumaleswar Reddy wrote:

Hi Jon,

 

Please see inline

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Wednesday, October 11, 2017 12:44 = AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_= Konda@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
S= ubject: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

I agree that any conflicting request need to be sorted out by the = respective DOTS server component =E2=80=93 SIG-009 - especially if there = are conflicts over IP addresses in the mitigation requests. If (c1) and = (c11) whether using alias-name or not do a mitigation request and this = create a mitigation conflict, then (s1) needs to sort it = out.

 

However aliases are set up by the data channel and potentially used = by the signal channel at a later time.

 

So, if (c1) and (c11) have different client identities, then in my = thinking (perhaps naively) that a setup of =E2=80=9Calias-1=E2=80=9D by = (c1) followed later by (c11) also defining the identical alias-name = =E2=80=9Calias-1=E2=80=9D then the alias-names are treated differently = by (s1) as it can separately associate =E2=80=9Calias-1=E2=80=9D with = the correct (c1) or (c11).  As (c1n) could be a large number when = scaling out, there is an increased chance of 2 or more of the clients at = the (c1) level choosing the same alias-name.

 

[TR] I don=E2=80=99t think there will be a large number of DOTS = clients in a domain, typically a DDoS mitigation system or DDoS detector = in a domain will act as DOTS clients (and in future content servers with = DDoS detection capability can also act as DOTS clients). =  

 

Why do you think there will be large number of DOTS clients in a = domain ?=

[Jon1] =C2=A0One of my customers has over 100 of his customers that = are separately protected and each of these customers would be considered = a (c1) instance.=C2=A0 Expand this out to a broadband network of home = routers and the numbers get very large.=C2=A0 See 3.1.8 and 3.2.2 in = dots use cases spec.

 

[When the mitigation requests come in from (c1) and (c11), using = their appropriate alias-name and there is a conflict when the mitigation = request is expanded out =E2=80=93 this has to be sorted out by = (s1).  However, I am assuming there is not a conflict in the = expanded mitigation request]

 

(s1) can handle this by the association of the alias-names with the = appropriate (c1n) identity.

 

Or are you saying that (s1) has to reject all duplicate alias-names = =E2=80=93 even though they are coming from different (c1n) = entities?

- this does not scale for me

- (c11) =E2=80=93 goes Huh?!? =E2=80=93 I have not previously defined = this. What is broken here ?

 

[TR] c11 has to re-try with a different alias name, RESTCONF (and = NETCONF) deals with this problem by returning = =E2=80=9Cdata-exists=E2=80=9D error response (409 response code). =

 

Assuming my understanding is correct that the (s1)  can = differentiate between alias-names used by different (c1n) clients, when = (c2) passes the =E2=80=9Calias-1=E2=80=9D name upstream without any = =E2=80=9Cextra (c1n info)=E2=80=9D information to (s2), (s2) will reject = the duplicate ((c2) has passed on the data channel request from (c1) and = (c11)) which (c2) then sees and then has to tell (c11) =E2=80=98Your = request to define =E2=80=9Calias-1=E2=80=9D failed as it is already = defined=E2=80=99.  So again, (c11) =E2=80=93 goes Huh?!? =E2=80=93 = I have not previously defined this.

 

I=E2=80=99m missing the point as to why you are concerned about = adding in this extra information between (c2) and (s2) =E2=80=93 we have = plenty of space in the UDP packet =E2=80=93 CBOR mapping has done a good = data reduction job.

 

[TR] Space is not a problem for adding the extra information, my = concern is the need to convey the extra information and DOTS gateway not = assisting to resolve the same alias-name from different DOTS = clients.=

[Jon1] I think we need this (optional) extra information that any = DOTS GW server side can send upstream.=C2=A0 Allowing (c3) to do this, = but not (c2) makes no sense to me.=C2=A0 To me, it is a requirement that = DOTS GW resolves conflicts, does data reduction etc. whenever it can to = reduce upstream traffic.

 

[Jon1] I still believe that (s3) has to maintain separation of (c1) = and (c11) information (alias-names, ACLs and mitigation requests).=C2=A0 = So, when (c11) askes for his mitigation status, he gets only data = relevant to him.

 

-Tiru

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 16:59
To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi Jon,

 

The role of s1 is much more than just forwarding the DOTS client = messages, please see (SIG-009 in the requirements drafts), if a DOTS = client has used the same alias name previously conveyed by another = client then s1 must reject the request. If conflicting requests are = resolved by s1 then any response message sent by s3 will be forwarded by = s1 to the right DOTS client.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 8:47 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Then that breaks a signal GET for mitigation status from (c1) = (mitigation request uses alias-name) =E2=80=93 what gets sent back in = the alias-name field when the response that is sent by (s3) when it gets = to (c1)?

 

I thought we had agreed to leave the alias name =E2=80=93 as is = =E2=80=93 (not substituted) in what is sent back to (c1) from = (s1).

 

(c1) is not particularly interested in how (c11) is getting mitigated = and probably does not want (c11) stats added into his =E2=80=93 (s3) = need to know how to differentiate between (c1) and (c11) =E2=80=93 which = is easily done if (c1) (or (c11) information is passed up to (s3), = starting with (s1).

 

This whole thing needs to be scalable, and I am struggling with how = to actually implement your proposal.  Allowing each DOTS GW to = learn and pass on something extra that differentiates the DOTS GW = immediate clients makes the implementation relatively easy.  There = is no need for a DOTS GW to add in additional information if extra = information is already embedded =E2=80=93 unless he sees a name clash = from 2 or more of his uniquely identified DOTS clients =E2=80=93 which = will be different entities anyway.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 15:52
To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

The conflicting alias-names from DOTS client (c1) and another = client (let=E2=80=99 call (c11)) behind (s1) should be resolved by s1 = itself, it is also the responsibility of (s1) to resolve conflicting = mitigation requests from (c1) and (c11), aggregate = the mitigation requests from the DOTS clients (c1 and c11) and send the = updated mitigation request (c2).

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 8:11 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

I agree in part, but we need to look at the end (c1) to end (s3) = potential issues.  What you are proposing works fine for (s2) to = (s3).

 

(c1) requests mitigation with an alias-name = =E2=80=9Calias-1=E2=80=9D.  If (s1) does not pass anything extra to = (c2) for onward transmission, (s2) sees a single client (c2) requesting = mitigation with alias-name =E2=80=9Calias-1=E2=80=9D.  Fine, that = works.

If there was another DOTS client in the same location as (c1)(i.e. = c1diff), both using (s1) who also decided to use alias-name = =E2=80=9Calias-1=E2=80=9D who then requests mitigation, (s2) has no idea = that there are different =E2=80=9Calias-1=E2=80=9D definitions if (c2) = does not send also an extra differentiator.

 

So, any DOTS GW in the chain should be passing on a = =E2=80=9Cunique-extra=E2=80=9D piece of = information.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 15:15
To: Jon Shallow; kaname nishizuka; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Agree with your response, consider a deployment which has the = following DOTS agents.

 

DOTS clients (c1) =C3=9F<= /span>----------------=C3=A0<= /span> (s1) client-side DOTS gateway (c2) =C3=9F<= /span>------------=C3=A0<= /span> (s2) server-side DOTS gateway (c3) =C3=9F<= /span>----------=C3=A0<= /span> (s3) DOTS server

 

My point is, (c2) need not convey the =E2=80=9Cc1 = identity=E2=80=9D to (s2) but (s2) needs to convey the =E2=80=9Cc2 = identity=E2=80=9D to (c3) and (c3) in-turn propagates the =E2=80=9Cc2 = identity=E2=80=9D to (s3).

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 6:15 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; kaname nishizuka <kaname@nttv6.jp>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Agreed that only a DOTS GW server facing needs to send information to = the upstream DOTS Server =E2=80=93 which could also be a DOTS = GW.

  =             &= nbsp;          +-------= ------+

          = ;            =    |    | D |    = |

         = +----+          = |    | O |    = |         = +----+

         | c1 = |----------| s1 | T | c2 |---------| s2 |

         = +----+     =      |    | S = |    |         = +----+

          = ;            =    |    | G |    = |

          = ;            =    +-------------+

https://tools.ietf.org/html/draft-ietf-dots-architecture-04#sec= tion-2.2.3

 

However, the DOTS GW client facing (s1) is the one with knowledge of = the individual clients that are currently using  the DOTS server = running on the DOTS GW.  This information has to somehow be passed = over to the DOTS GW server facing (c2), but separate DOTS stacks are = being run for (s1) and (c2) as per architecture spec 2.2.3.  I was = referring to what (s1) may need to pass on to (c2) in my email response = to Kaname, not what is sent by (c1).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 = 13:16
To: Jon Shallow; 'kaname nishizuka'; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

I thought we agreed that based on the current DOTS requirements = only the server-side DOTS GW needs to convey the DOTS client (or = client-side DOTS WG) identity to the DOTS server. =

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, October 10, 2017 2:53 PM
To: = 'kaname nishizuka' <kaname@nttv6.jp>; Konda, = Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Kaname,

 

I do not think that information necessarily needs to be the original = client identity.  The GW Client side will have its own identity = which the DOTS Server can use to differentiate between DOTS (GW) = Clients.

 

So, yes, a hashed set of names can be used =E2=80=93 it is up to the = DOTS GW Client side to make sure that there are no hash = collisions.  Or it could be a simple list such as C1, C2 = =E2=80=A6Cn.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of kaname nishizuka
Sent: 10 October 2017 = 04:19
To: Konda, Tirumaleswar Reddy; Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

Hi,

> I agree the below = problems are applicable for server-side DOTS gateway, it must convey the = =E2=80=9Cclient identity=E2=80=9D to the DOTS server.
I agree with = this server-side DOTS gateway case.
At the same time, I agree with = below:
> I agree that is not a good thing to = =E2=80=9Cleak=E2=80=9D out internal information when passing through a = DOTS GW,

Then, should DOTS GW send =E2=80=9Cclient = identity=E2=80=9D (i.e. certificates of DOTS clients) itself or = hashed(=E2=80=9Cclient identity=E2=80=9D) to DOTS server?
If later, = how can DOTS server react to the ambiguous information of the = hashed(=E2=80=9Cclient = identity=E2=80=9D).

regards,
Kaname

On 2017/10/09 22:34, Konda, Tirumaleswar Reddy = wrote:

Hi = Jon,

 

I agree = the below problems are applicable for server-side DOTS gateway, it must = convey the =E2=80=9Cclient identity=E2=80=9D to the DOTS server. But for = the client-side DOTS gateway, it should resolve conflicting rules b/w = DOTS clients (e.g. one client installing black-list ACL for an IP = address but the other client installs white-list ACL for the same IP = address, same alias-names for different mitigation scopes). I = don=E2=80=99t see the need for a client-side DOTS gateway to convey the = =E2=80=9Cclient identity=E2=80=9D to the server-side DOTS gateway or = DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, October 7, 2017 2:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_= Konda@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
S= ubject: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

This discussion goes beyond just the mitigation request.  We = need to consider what happens with both alias-name and acl-name (data = channel)

 

The simple case of a mitigation request with no alias-name does not = require any knowledge of the original client.  =

 

However, if the mitigation request uses alias-name, then there are 3 = ways of handling this

a)     &nb= sp; The DOTS GW replaces the alias-name with its actual definition = (target-ips etc. merged as appropriate), so alias-name is not forwarded = on to Server =E2=80=93 just the expanded mitigation request is = forwarded

b)      = The DOTS GW updates the alias-name with a unique alias-name that is = forwarded (and has to do the same thing when the alias-name is = configured on the data channel) =E2=80=93 to handle 2 or more clients = defining the same alias-name which have different = characteristics

c)     &nb= sp; The DOTS GW recognises that alias-name is not unique and adds in = =E2=80=9Dadditional-client-info=E2=80=9D (I think I prefer this = =E2=80=9C-info=E2=80=9D name to client-id or original-client-id as = =E2=80=9C-id=E2=80=9D is too closely  associated with Client = Identity derived from the DOTS GW Client = certificate)

We have agreed that when a client requests mitigation status, the = =E2=80=9Calias-name=E2=80=9D should be returned as = =E2=80=9Calias-name=E2=80=9D and not the substituted alias-name = configuration (this does need to be stated in the spec for = clarity).  This makes (a) difficult to be handled by DOTS GW which = then raises the question =E2=80=93 do we really need = alias-name?

 

The definition and association of ACLs/Filters of the data channel is = more difficult =E2=80=93 the Server must install / apply the appropriate = ACLs on a per (Original) Client basis when mitigation is = invoked.

Client 1=E2=80=99s concept of a Whitelist IP could be Client = 2=E2=80=99s concept of a Blacklist IP.  The Server needs to know = which client is requesting the mitigation and install the correct ACLs = =E2=80=93 if there was no =E2=80=9Dadditional-client-info=E2=80=9D, the = Server only knows that he has to install ALL of the ACLs (i.e. both the = Black and White list of the same IP as defined by Client 1 and Client 2) = as defined by his client (DOTS GW) when his client requests a = mitigation.  Here, I think that if there is more than one client = for the DOTS GW, =E2=80=9Dadditional-client-info=E2=80=9D is = required.

 

Regards

 

Jon

 

From:= = Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 07 October 2017 = 04:28
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland = Dobbins
Subject: Re: [Dots] DOTS Gateways = Challenges

 

In case of = client-side DOTS gateway, why does the DOTS server need to know which = =E2=80=9CDOTS client=E2=80=9D has conveyed the mitigation request = ?

For = example, the DOTS client could be a DDoS detector or an Application = server, and the client-side gateway will have to resolve the conflicting = mitigation requests from the DOTS clients, aggregate the mitigation = requests from the DOTS client and send the updated mitigation request to = the DOTS server.

 

-Tiru

 

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, October 6, 2017 7:42 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org; Roland Dobbins = <rdobbins@arbor.net>
Subje= ct: RE: [Dots] DOTS Gateways = Challenges

 

Hi Tiru,

 

Unless I am missing something, how does the Client side of DOTS GW = convey to the upstream server a unique =E2=80=9Cclient-id=E2=80=9D which = is different to the implied client id as derived from the PKI = certificate that the DOTS GW=E2=80=99Client uses/presents when = communicating to the server?

To me, there needs to be an option such as = =E2=80=9Coriginal-client-id=E2=80=9D or =E2=80=9Cclient-id=E2=80=9D = (which is confusing when also referring to the client identity as = derived from the (DOTS GW) Client=E2=80=99s PKI certificate) as a part = of the protocol.

 

I agree that the DOTS GW can generate its own unique client-id to = stop multiple entries being needed.

 

I agree that is not a good thing to =E2=80=9Cleak=E2=80=9D out = internal information when passing through a DOTS GW, so my REQUIRED does = not make sense.

 

Regards

 

Jon

PS =E2=80=93 I am having to deal with other stuff at present = =E2=80=93 I will get back later on the other issues under = discussion

 

From:= = Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 06 October 2017 14:58
To: = mohamed.boucadair@orange.com= ; Jon Shallow; 'Dobbins, Roland'; dots@ietf.org
Subject: RE: = [Dots] DOTS Gateways Challenges

 

I = don=E2=80=99t see a need for client-side DOTS gateway to convey the = =E2=80=9CDOTS client identity=E2=80=9D to the DOTS server. =E2=80=9CDOTS = client identity=E2=80=9D looks required only for the server-side DOTS = gateways. In case of server-side DOTS gateway, it can convey the = client-id generated from the =E2=80=9CDOTS client identity=E2=80=9D to = the DOTS server. The DOTS gateway can generate a unique client-id and = does not have to send an array of client-ids to the DOTS server to = resolve clashes.

 

-Tiru

 

________________=
_______________________________
Dots mailing =
list
Dots@ietf.org
https://www.ietf.org/=
mailman/listinfo/dots

 




_______________________=
________________________
Dots mailing =
list
Dots@ietf.org
https://www.ietf.org/=
mailman/listinfo/dots

 

------=_NextPart_000_006A_01D34289.98E3E020-- From nobody Wed Oct 11 05:29:04 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B071342F0 for ; Wed, 11 Oct 2017 05:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.99 X-Spam-Level: X-Spam-Status: No, score=-6.99 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_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 EMID1VS2SP_5 for ; Wed, 11 Oct 2017 05:28:58 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 55E6E1342D2 for ; Wed, 11 Oct 2017 05:28:57 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507724936; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=m L0TL+WaOSyQLsVaI5u3QM55tLtgmega6/C0i8CLKz M=; b=pnU3uuD7XdE36Z5kzPsJk+cTi4tKPax/IGeeIHbMny28 64I83D3zaStlIayzr94zl4yy7KdOfFP3SBAsgil4ajRXfO1MXd /7KTWKSWlIkuevRSEOKWrUQXMbuDlNTofbe5Nu9FBGsPFpreDN 7ZIEXK189WDeQ5imqOU/VwlxUr4= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 0843_b5bb_b57e7d59_ac68_4d33_99f2_a1b501c1bab9; Wed, 11 Oct 2017 07:28:54 -0500 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 11 Oct 2017 08:28:52 -0400 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 11 Oct 2017 08:28:51 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 11 Oct 2017 08:28:51 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 11 Oct 2017 08:28:50 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 11 Oct 2017 12:28:49 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.020; Wed, 11 Oct 2017 12:28:49 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , 'kaname nishizuka' , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Roland Dobbins" Thread-Topic: [Dots] DOTS Gateways Challenges Thread-Index: AdM9Vq95ZRESQ+lSTJiM74u4vL9x1wAAjvwAABWxhIAAA6FiAAAD9ImAACn2sgAADIL9oAABRecAABtiTEAACzkMAABuu0fgAB0EBwAADL1rgAAF4fWwAAEncgAAAJP24AADfJaAAAAklGAAARtaAAAA3fKAAAdoswAADm/p4AAQCn2AAALY0QAAAr2LYA== Date: Wed, 11 Oct 2017 12:28:48 +0000 Message-ID: References: <072401d33d56$b0e229d0$12a67d70$@jpshallow.com> <09ed01d33f47$7536f440$5fa4dcc0$@jpshallow.com> <3b24135c-e5ec-f602-9d5e-0a2d18ad347c@nttv6.jp> <0cd601d341a9$6868bf50$393a3df0$@jpshallow.com> <0d8901d341c5$8db63e10$a922ba30$@jpshallow.com> <0df701d341d5$cfd88770$6f89 9650$@jpshallow.com> <0e3501d341da$cf9e4b50$6edae1f0$@jpshallow.com> <0e7b01d341fb$ea576870$bf063950$@jpshallow.com> <006901d34281$371abd30$a5503790$@jpshallow.com> In-Reply-To: <006901d34281$371abd30$a5503790$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [161.69.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:XbRoMRRaQtnbXfOgVWlctvouBWgNZvV59Nc6Pig2r437abCD4ejHFk8ri+m7O51YMpH5lg0Xmc9yb31d6cCysBW6z8yTFu0S8dvG+57iCp5pw/uaBMm9xl+u8aeFZsS+1NEpqqt0Seas2NSqI93+Qz8SMlBZRxunyt4sNCMRdxJS8xpXYu6uU/FqWQt3H+Ui6nRgxPB6SirH4i4KV4yeRftVPTUvcOPJiAi9qtEXyzM+P0UBROTxMNaNAntk7HlJfNZxkvJd6Gs+HIg+9/3qbftop8Kf4Zp0XiXs6JbGCFG5jlhNOYYoMfqiZ/Jc9rdGP6dTO5bumN+EpHglpEBpNA==; 5:cwSClxUQn7iIqarfxqn48bMUfezYAmYfQxgJGSnYNyXc+i8gLjHhqr6wZu/3bDZle5VA4n7VDwJPgocpHqnn0Smpv1ME8W22SHy3InKPY8nXuZR/EAyXLzR/9/6Vz5MTwNJOeZMgXot1D/2ISkAbpg==; 24:k0Av8eU51LYu8WmzCt6urVyTNRaamGtxQ2PfFY8GCTNyECS8o6se93BNl+t9bseuyl8+pZOsTkVaXBDzgafjq4fzt1As0xa1KkDK1mQct5A=; 7:tI07rT6odIpT17Ko+8MDt4gvOhrHr6cyCiUswQYc7LJNwqqwC6g1e+pyDU55SzLP9z2sHgkc4WkcF1qP3iWelMlzjpOeZxAveRZsRKdLRlJoNwR+7Lkf7uE7VEOLFoZg5QUNZcmF4ukolhfku2liLZ1dlS1sXsjWCm1i911BOzMsf+ewxHgs5AUume5vhLH1qoD1jZQBege6r3I8lNTjKHKPbTI9AhJFKduNnvRA6Q0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 184ee9ca-c20f-4268-2058-08d510a3a022 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0457F11EAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(24454002)(51444003)(189002)(199003)(32952001)(377454003)(790700001)(3846002)(105586002)(50986999)(6116002)(102836003)(93886005)(229853002)(76176999)(66066001)(189998001)(54356999)(106356001)(86362001)(110136005)(101416001)(316002)(561944003)(68736007)(16200700003)(53946003)(2950100002)(6306002)(55016002)(97736004)(14454004)(9686003)(966005)(72206003)(53936002)(6246003)(7696004)(478600001)(53546010)(6506006)(3660700001)(99286003)(236005)(8676002)(81166006)(54896002)(606006)(77096006)(2201001)(33656002)(2900100001)(2501003)(5660300001)(80792005)(6436002)(81156014)(74316002)(7736002)(8936002)(25786009)(2906002)(3280700002)(85282002)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788774A0B6F0CFFA3B688C9EA4A0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2017 12:28:49.3066 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6134> : inlines <6122> : streams <1766787> : uri <2514785> Archived-At: Subject: Re: [Dots] DOTS Gateways Challenges X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 12:29:02 -0000 --_000_DM5PR16MB1788774A0B6F0CFFA3B688C9EA4A0DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEpvbiBmb3IgdGhlIGNsYXJpZmljYXRpb24sIEkgd2lsbCB1cGRhdGUgYm90aCBzaWdu YWwgYW5kIGRhdGEgY2hhbm5lbCBkcmFmdHMgdG8gYWRkcmVzcyB0aGUgY29tbWVudC4NCg0KLVRp cnUNCg0KRnJvbTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29t XQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDExLCAyMDE3IDQ6MzggUE0NClRvOiAna2FuYW1l IG5pc2hpenVrYScgPGthbmFtZUBudHR2Ni5qcD47IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkg PFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tOyBkb3RzQGlldGYub3JnOyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3Iu bmV0Pg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkg S2FuYW1lIC8gVGlydSwNCg0KU2VlIGlubGluZSDigJMgW0pvbjFdIDMgaW4gS2FuYW1h4oCZcyBy ZXNwb25zZSBhbmQgMyBpbiBUaXJ14oCZcyByZXNwb25zZS4NCg0KUmVnYXJkcw0KDQpKb24NCg0K DQpGcm9tOiBEb3RzIFttYWlsdG86IGRvdHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIGthbmFtZSBuaXNoaXp1a2ENClNlbnQ6IDEx IE9jdG9iZXIgMjAxNyAxMDo0Nw0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk7IEpvbiBT aGFsbG93OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJv bGFuZCBEb2JiaW5zDQpTdWJqZWN0OiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdl cw0KDQpIaSBKb24sIFRpcnUsDQoNCj4gKGMxKSByZXF1ZXN0cyBtaXRpZ2F0aW9uIHdpdGggYW4g YWxpYXMtbmFtZSDigJxhbGlhcy0x4oCdLiAgSWYgKHMxKSBkb2VzIG5vdCBwYXNzIGFueXRoaW5n IGV4dHJhIHRvIChjMikgZm9yIG9ud2FyZCB0cmFuc21pc3Npb24sIChzMikgc2VlcyBhIHNpbmds ZSBjbGllbnQgKGMyKSByZXF1ZXN0aW5nIG1pdGlnYXRpb24gd2l0aCBhbGlhcy1uYW1lIOKAnGFs aWFzLTHigJ0uICBGaW5lLCB0aGF0IHdvcmtzLg0KPiBJZiB0aGVyZSB3YXMgYW5vdGhlciBET1RT IGNsaWVudCBpbiB0aGUgc2FtZSBsb2NhdGlvbiBhcyAoYzEpKGkuZS4gYzFkaWZmKSwgYm90aCB1 c2luZyAoczEpIHdobyBhbHNvIGRlY2lkZWQgdG8gdXNlIGFsaWFzLW5hbWUg4oCcYWxpYXMtMeKA nSB3aG8gdGhlbiByZXF1ZXN0cyBtaXRpZ2F0aW9uLCAoczIpIGhhcyBubyBpZGVhIHRoYXQgdGhl cmUgYXJlIGRpZmZlcmVudCDigJxhbGlhcy0x4oCdIGRlZmluaXRpb25zIGlmIChjMikgZG9lcyBu b3Qgc2VuZCBhbHNvIGFuIGV4dHJhIGRpZmZlcmVudGlhdG9yLg0KDQpGcm9tIHRoZSB2aWV3cG9p bnQgb2YgczIsIGlmIHRoZXJlIGlzIGEgZGlmZmVyZW50aWF0b3Igb2YgcmVxdWVzdCBmcm9tIGMx IGFuZCBjMWRpZmYsIGl0IHdpbGwgYXNzaXN0IHNvbWUgc2l0dWF0aW9uLiBGb3IgZXhhbXBsZSwg YSByZXRyaWV2YWwgcmVxdWVzdCBvZiBleGlzdGluZyBtaXRpZ2F0aW9uIGxpc3QgZnJvbSBjMiB3 aWxsIGdldCBhbGwgb2YgdGhlIGRhdGEgZnJvbSBzMiBpZiB0aGVyZSBpcyBubyBkaWZmZXJlbnRp YXRvciBpbiB0aGUgcmVxdWVzdCwgaG93ZXZlciBpZiB0aGVyZSBpcywgczIgY2FuIHJldHVybiBv bmx5IHRoZSByZWxhdGVkIGluZm9ybWF0aW9uIG9mIHNwZWNpZmljIG9uZS4NCltKb24xXSBBZ3Jl ZWQuDQoNCkJ1dCwgSSBkb24ndCB0aGluayBzdWNoIGtpbmQgb2YgZGlmZmVyZW50aWF0b3IgaXMg cmVxdWlyZWQgYmV0d2VlbiBjMSBhbmQgczEsIGJlY2F1c2UgczEgc2hvdWxkIGlkZW50aWZ5IGMx IGJhc2VkIG9uIOKAnGNsaWVudCBpZGVudGl0eeKAnSB3aGljaCB3aWxsIGJlIGNlcnRpZmljYXRl IG9mIGMxIGlmIHRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24gaXMgUEtJLWJhc2VkLiBLZWVwaW5n IHRoZSBiaW5kaW5nIG9mIOKAnGNsaWVudCBpZGVudGl0eeKAnSAgYW5kIChvcmlnaW5hbCktY2xp ZW50LWlkIGluIHNpZ25hbCBtZXNzYWdlIGlzIGEgbGl0dGxlIGJpdCBjb21wbGljYXRlZCBpbXBs ZW1lbnRhdGlvbiBvZiBzMS4NCltKb24xXSBBZ3JlZWQg4oCTIGJ1dCAoczIpIGFuZCAoczMpIHdp bGwgaGF2ZSB0byBkbyB0aGlzLg0KDQpSZWdhcmRpbmcgdGhlIGRhdGEtY2hhbm5lbCwgdGhlcmUg aXMgYSBwb3NzaWJpbGl0eSBvZiBjb2xsaXNpb24gaW4gYWxpYXMtbmFtZSBhbW9uZyBjMSwgYzFk aWZmLCwsLCBzbyBzaG91bGQgd2UgbmVlZCB0byBkZXNjcmliZSBob3cgdG8gYmluZCBhIGRhdGEt Y2hhbm5lbCBhbmQgc2lnbmFsLWNoYW5uZWwgZm9yIHZhcmlvdXMgbXV0dWFsIGF1dGhlbnRpY2F0 aW9uIHBhdHRlcm5zIGxpa2UgUEtJLCBTUEtJLCBUTFMtUEtJIGV0YywuLiBpbiB0aGUgZHJhZnQ/ DQpbSm9uMV0gSW4gbXkgY3VycmVudCBpbXBsZW1lbnRhdGlvbiwgYWxpYXMtbmFtZSAod2hldGhl ciBkYXRhIG9yIHNpZ25hbCBjaGFubmVsKSBpcyBhc3NvY2lhdGVkIHdpdGggYSBjbGllbnQtaWQg KGFuZCBwb3NzaWJseSDigJxleHRyYS1jbGllbnQtaW5mb+KAnSAobm90IHlldCBjb2RlZCkpLiAg VGhlIGRlY2lzaW9uIGhlcmUgaXMgd2hldGhlciB3ZSBoYXZlIGEgc2luZ2xlIHBvb2wgb2YgYWxp YXMtbmFtZXMgKGFuZCBBQ0xzKSBvbiBhIERPVFMgc2VydmVyLCBvciBlYWNoIERPVFMgc2VydmVy IChzdGFuZGFsb25lIG9yIGluIGEgR1cpIG1haW50YWlucyBzZXBhcmF0ZSBsaXN0cyDigJMgb25l IHBlciBjbGllbnQtaWQuICBBbmQgdGhpcyBzaG91bGQgYmUgc3RhdGVkIGluIHRoZSBzcGVjcyBm b3IgY2xhcml0eS4NCg0KcmVnYXJkcywNCkthbmFtZQ0KT24gMjAxNy8xMC8xMSAxMzozOCwgS29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeSB3cm90ZToNCkhpIEpvbiwNCg0KUGxlYXNlIHNlZSBpbmxp bmUNCg0KRnJvbTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29t XQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDExLCAyMDE3IDEyOjQ0IEFNDQpUbzogS29uZGEs IFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT48 bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyBrYW5hbWUgbmlzaGl6 dWthIDxrYW5hbWVAbnR0djYuanA+PG1haWx0bzprYW5hbWVAbnR0djYuanA+OyBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsg ZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zIDxyZG9i Ymluc0BhcmJvci5uZXQ+PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+DQpTdWJqZWN0OiBSRTog W0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSBUaXJ1LA0KDQpJIGFncmVlIHRo YXQgYW55IGNvbmZsaWN0aW5nIHJlcXVlc3QgbmVlZCB0byBiZSBzb3J0ZWQgb3V0IGJ5IHRoZSBy ZXNwZWN0aXZlIERPVFMgc2VydmVyIGNvbXBvbmVudCDigJMgU0lHLTAwOSAtIGVzcGVjaWFsbHkg aWYgdGhlcmUgYXJlIGNvbmZsaWN0cyBvdmVyIElQIGFkZHJlc3NlcyBpbiB0aGUgbWl0aWdhdGlv biByZXF1ZXN0cy4gSWYgKGMxKSBhbmQgKGMxMSkgd2hldGhlciB1c2luZyBhbGlhcy1uYW1lIG9y IG5vdCBkbyBhIG1pdGlnYXRpb24gcmVxdWVzdCBhbmQgdGhpcyBjcmVhdGUgYSBtaXRpZ2F0aW9u IGNvbmZsaWN0LCB0aGVuIChzMSkgbmVlZHMgdG8gc29ydCBpdCBvdXQuDQoNCkhvd2V2ZXIgYWxp YXNlcyBhcmUgc2V0IHVwIGJ5IHRoZSBkYXRhIGNoYW5uZWwgYW5kIHBvdGVudGlhbGx5IHVzZWQg YnkgdGhlIHNpZ25hbCBjaGFubmVsIGF0IGEgbGF0ZXIgdGltZS4NCg0KU28sIGlmIChjMSkgYW5k IChjMTEpIGhhdmUgZGlmZmVyZW50IGNsaWVudCBpZGVudGl0aWVzLCB0aGVuIGluIG15IHRoaW5r aW5nIChwZXJoYXBzIG5haXZlbHkpIHRoYXQgYSBzZXR1cCBvZiDigJxhbGlhcy0x4oCdIGJ5IChj MSkgZm9sbG93ZWQgbGF0ZXIgYnkgKGMxMSkgYWxzbyBkZWZpbmluZyB0aGUgaWRlbnRpY2FsIGFs aWFzLW5hbWUg4oCcYWxpYXMtMeKAnSB0aGVuIHRoZSBhbGlhcy1uYW1lcyBhcmUgdHJlYXRlZCBk aWZmZXJlbnRseSBieSAoczEpIGFzIGl0IGNhbiBzZXBhcmF0ZWx5IGFzc29jaWF0ZSDigJxhbGlh cy0x4oCdIHdpdGggdGhlIGNvcnJlY3QgKGMxKSBvciAoYzExKS4gIEFzIChjMW4pIGNvdWxkIGJl IGEgbGFyZ2UgbnVtYmVyIHdoZW4gc2NhbGluZyBvdXQsIHRoZXJlIGlzIGFuIGluY3JlYXNlZCBj aGFuY2Ugb2YgMiBvciBtb3JlIG9mIHRoZSBjbGllbnRzIGF0IHRoZSAoYzEpIGxldmVsIGNob29z aW5nIHRoZSBzYW1lIGFsaWFzLW5hbWUuDQoNCltUUl0gSSBkb27igJl0IHRoaW5rIHRoZXJlIHdp bGwgYmUgYSBsYXJnZSBudW1iZXIgb2YgRE9UUyBjbGllbnRzIGluIGEgZG9tYWluLCB0eXBpY2Fs bHkgYSBERG9TIG1pdGlnYXRpb24gc3lzdGVtIG9yIEREb1MgZGV0ZWN0b3IgaW4gYSBkb21haW4g d2lsbCBhY3QgYXMgRE9UUyBjbGllbnRzIChhbmQgaW4gZnV0dXJlIGNvbnRlbnQgc2VydmVycyB3 aXRoIEREb1MgZGV0ZWN0aW9uIGNhcGFiaWxpdHkgY2FuIGFsc28gYWN0IGFzIERPVFMgY2xpZW50 cykuDQoNCldoeSBkbyB5b3UgdGhpbmsgdGhlcmUgd2lsbCBiZSBsYXJnZSBudW1iZXIgb2YgRE9U UyBjbGllbnRzIGluIGEgZG9tYWluID8NCltKb24xXSAgT25lIG9mIG15IGN1c3RvbWVycyBoYXMg b3ZlciAxMDAgb2YgaGlzIGN1c3RvbWVycyB0aGF0IGFyZSBzZXBhcmF0ZWx5IHByb3RlY3RlZCBh bmQgZWFjaCBvZiB0aGVzZSBjdXN0b21lcnMgd291bGQgYmUgY29uc2lkZXJlZCBhIChjMSkgaW5z dGFuY2UuICBFeHBhbmQgdGhpcyBvdXQgdG8gYSBicm9hZGJhbmQgbmV0d29yayBvZiBob21lIHJv dXRlcnMgYW5kIHRoZSBudW1iZXJzIGdldCB2ZXJ5IGxhcmdlLiAgU2VlIDMuMS44IGFuZCAzLjIu MiBpbiBkb3RzIHVzZSBjYXNlcyBzcGVjLg0KDQpbV2hlbiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0 cyBjb21lIGluIGZyb20gKGMxKSBhbmQgKGMxMSksIHVzaW5nIHRoZWlyIGFwcHJvcHJpYXRlIGFs aWFzLW5hbWUgYW5kIHRoZXJlIGlzIGEgY29uZmxpY3Qgd2hlbiB0aGUgbWl0aWdhdGlvbiByZXF1 ZXN0IGlzIGV4cGFuZGVkIG91dCDigJMgdGhpcyBoYXMgdG8gYmUgc29ydGVkIG91dCBieSAoczEp LiAgSG93ZXZlciwgSSBhbSBhc3N1bWluZyB0aGVyZSBpcyBub3QgYSBjb25mbGljdCBpbiB0aGUg ZXhwYW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0XQ0KDQooczEpIGNhbiBoYW5kbGUgdGhpcyBieSB0 aGUgYXNzb2NpYXRpb24gb2YgdGhlIGFsaWFzLW5hbWVzIHdpdGggdGhlIGFwcHJvcHJpYXRlIChj MW4pIGlkZW50aXR5Lg0KDQpPciBhcmUgeW91IHNheWluZyB0aGF0IChzMSkgaGFzIHRvIHJlamVj dCBhbGwgZHVwbGljYXRlIGFsaWFzLW5hbWVzIOKAkyBldmVuIHRob3VnaCB0aGV5IGFyZSBjb21p bmcgZnJvbSBkaWZmZXJlbnQgKGMxbikgZW50aXRpZXM/DQotIHRoaXMgZG9lcyBub3Qgc2NhbGUg Zm9yIG1lDQotIChjMTEpIOKAkyBnb2VzIEh1aD8hPyDigJMgSSBoYXZlIG5vdCBwcmV2aW91c2x5 IGRlZmluZWQgdGhpcy4gV2hhdCBpcyBicm9rZW4gaGVyZSA/DQoNCltUUl0gYzExIGhhcyB0byBy ZS10cnkgd2l0aCBhIGRpZmZlcmVudCBhbGlhcyBuYW1lLCBSRVNUQ09ORiAoYW5kIE5FVENPTkYp IGRlYWxzIHdpdGggdGhpcyBwcm9ibGVtIGJ5IHJldHVybmluZyDigJxkYXRhLWV4aXN0c+KAnSBl cnJvciByZXNwb25zZSAoNDA5IHJlc3BvbnNlIGNvZGUpLg0KDQpBc3N1bWluZyBteSB1bmRlcnN0 YW5kaW5nIGlzIGNvcnJlY3QgdGhhdCB0aGUgKHMxKSAgY2FuIGRpZmZlcmVudGlhdGUgYmV0d2Vl biBhbGlhcy1uYW1lcyB1c2VkIGJ5IGRpZmZlcmVudCAoYzFuKSBjbGllbnRzLCB3aGVuIChjMikg cGFzc2VzIHRoZSDigJxhbGlhcy0x4oCdIG5hbWUgdXBzdHJlYW0gd2l0aG91dCBhbnkg4oCcZXh0 cmEgKGMxbiBpbmZvKeKAnSBpbmZvcm1hdGlvbiB0byAoczIpLCAoczIpIHdpbGwgcmVqZWN0IHRo ZSBkdXBsaWNhdGUgKChjMikgaGFzIHBhc3NlZCBvbiB0aGUgZGF0YSBjaGFubmVsIHJlcXVlc3Qg ZnJvbSAoYzEpIGFuZCAoYzExKSkgd2hpY2ggKGMyKSB0aGVuIHNlZXMgYW5kIHRoZW4gaGFzIHRv IHRlbGwgKGMxMSkg4oCYWW91ciByZXF1ZXN0IHRvIGRlZmluZSDigJxhbGlhcy0x4oCdIGZhaWxl ZCBhcyBpdCBpcyBhbHJlYWR5IGRlZmluZWTigJkuICBTbyBhZ2FpbiwgKGMxMSkg4oCTIGdvZXMg SHVoPyE/IOKAkyBJIGhhdmUgbm90IHByZXZpb3VzbHkgZGVmaW5lZCB0aGlzLg0KDQpJ4oCZbSBt aXNzaW5nIHRoZSBwb2ludCBhcyB0byB3aHkgeW91IGFyZSBjb25jZXJuZWQgYWJvdXQgYWRkaW5n IGluIHRoaXMgZXh0cmEgaW5mb3JtYXRpb24gYmV0d2VlbiAoYzIpIGFuZCAoczIpIOKAkyB3ZSBo YXZlIHBsZW50eSBvZiBzcGFjZSBpbiB0aGUgVURQIHBhY2tldCDigJMgQ0JPUiBtYXBwaW5nIGhh cyBkb25lIGEgZ29vZCBkYXRhIHJlZHVjdGlvbiBqb2IuDQoNCltUUl0gU3BhY2UgaXMgbm90IGEg cHJvYmxlbSBmb3IgYWRkaW5nIHRoZSBleHRyYSBpbmZvcm1hdGlvbiwgbXkgY29uY2VybiBpcyB0 aGUgbmVlZCB0byBjb252ZXkgdGhlIGV4dHJhIGluZm9ybWF0aW9uIGFuZCBET1RTIGdhdGV3YXkg bm90IGFzc2lzdGluZyB0byByZXNvbHZlIHRoZSBzYW1lIGFsaWFzLW5hbWUgZnJvbSBkaWZmZXJl bnQgRE9UUyBjbGllbnRzLg0KW0pvbjFdIEkgdGhpbmsgd2UgbmVlZCB0aGlzIChvcHRpb25hbCkg ZXh0cmEgaW5mb3JtYXRpb24gdGhhdCBhbnkgRE9UUyBHVyBzZXJ2ZXIgc2lkZSBjYW4gc2VuZCB1 cHN0cmVhbS4gIEFsbG93aW5nIChjMykgdG8gZG8gdGhpcywgYnV0IG5vdCAoYzIpIG1ha2VzIG5v IHNlbnNlIHRvIG1lLiAgVG8gbWUsIGl0IGlzIGEgcmVxdWlyZW1lbnQgdGhhdCBET1RTIEdXIHJl c29sdmVzIGNvbmZsaWN0cywgZG9lcyBkYXRhIHJlZHVjdGlvbiBldGMuIHdoZW5ldmVyIGl0IGNh biB0byByZWR1Y2UgdXBzdHJlYW0gdHJhZmZpYy4NCg0KW0pvbjFdIEkgc3RpbGwgYmVsaWV2ZSB0 aGF0IChzMykgaGFzIHRvIG1haW50YWluIHNlcGFyYXRpb24gb2YgKGMxKSBhbmQgKGMxMSkgaW5m b3JtYXRpb24gKGFsaWFzLW5hbWVzLCBBQ0xzIGFuZCBtaXRpZ2F0aW9uIHJlcXVlc3RzKS4gIFNv LCB3aGVuIChjMTEpIGFza2VzIGZvciBoaXMgbWl0aWdhdGlvbiBzdGF0dXMsIGhlIGdldHMgb25s eSBkYXRhIHJlbGV2YW50IHRvIGhpbS4NCg0KLVRpcnUNCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJv bTogRG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNl c0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpTZW50 OiAxMCBPY3RvYmVyIDIwMTcgMTY6NTkNClRvOiBKb24gU2hhbGxvdzsga2FuYW1lIG5pc2hpenVr YTsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQg RG9iYmlucw0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0K SGkgSm9uLA0KDQpUaGUgcm9sZSBvZiBzMSBpcyBtdWNoIG1vcmUgdGhhbiBqdXN0IGZvcndhcmRp bmcgdGhlIERPVFMgY2xpZW50IG1lc3NhZ2VzLCBwbGVhc2Ugc2VlIChTSUctMDA5IGluIHRoZSBy ZXF1aXJlbWVudHMgZHJhZnRzKSwgaWYgYSBET1RTIGNsaWVudCBoYXMgdXNlZCB0aGUgc2FtZSBh bGlhcyBuYW1lIHByZXZpb3VzbHkgY29udmV5ZWQgYnkgYW5vdGhlciBjbGllbnQgdGhlbiBzMSBt dXN0IHJlamVjdCB0aGUgcmVxdWVzdC4gSWYgY29uZmxpY3RpbmcgcmVxdWVzdHMgYXJlIHJlc29s dmVkIGJ5IHMxIHRoZW4gYW55IHJlc3BvbnNlIG1lc3NhZ2Ugc2VudCBieSBzMyB3aWxsIGJlIGZv cndhcmRlZCBieSBzMSB0byB0aGUgcmlnaHQgRE9UUyBjbGllbnQuDQoNCi1UaXJ1DQoNCkZyb206 IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NClNlbnQ6IFR1 ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgODo0NyBQTQ0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+Pjsga2FuYW1lIG5pc2hpenVrYSA8a2FuYW1lQG50 dHY2LmpwPG1haWx0bzprYW5hbWVAbnR0djYuanA+PjsgbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8 bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0 PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTIEdh dGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KVGhlbiB0aGF0IGJyZWFrcyBhIHNpZ25h bCBHRVQgZm9yIG1pdGlnYXRpb24gc3RhdHVzIGZyb20gKGMxKSAobWl0aWdhdGlvbiByZXF1ZXN0 IHVzZXMgYWxpYXMtbmFtZSkg4oCTIHdoYXQgZ2V0cyBzZW50IGJhY2sgaW4gdGhlIGFsaWFzLW5h bWUgZmllbGQgd2hlbiB0aGUgcmVzcG9uc2UgdGhhdCBpcyBzZW50IGJ5IChzMykgd2hlbiBpdCBn ZXRzIHRvIChjMSk/DQoNCkkgdGhvdWdodCB3ZSBoYWQgYWdyZWVkIHRvIGxlYXZlIHRoZSBhbGlh cyBuYW1lIOKAkyBhcyBpcyDigJMgKG5vdCBzdWJzdGl0dXRlZCkgaW4gd2hhdCBpcyBzZW50IGJh Y2sgdG8gKGMxKSBmcm9tIChzMSkuDQoNCihjMSkgaXMgbm90IHBhcnRpY3VsYXJseSBpbnRlcmVz dGVkIGluIGhvdyAoYzExKSBpcyBnZXR0aW5nIG1pdGlnYXRlZCBhbmQgcHJvYmFibHkgZG9lcyBu b3Qgd2FudCAoYzExKSBzdGF0cyBhZGRlZCBpbnRvIGhpcyDigJMgKHMzKSBuZWVkIHRvIGtub3cg aG93IHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiAoYzEpIGFuZCAoYzExKSDigJMgd2hpY2ggaXMg ZWFzaWx5IGRvbmUgaWYgKGMxKSAob3IgKGMxMSkgaW5mb3JtYXRpb24gaXMgcGFzc2VkIHVwIHRv IChzMyksIHN0YXJ0aW5nIHdpdGggKHMxKS4NCg0KVGhpcyB3aG9sZSB0aGluZyBuZWVkcyB0byBi ZSBzY2FsYWJsZSwgYW5kIEkgYW0gc3RydWdnbGluZyB3aXRoIGhvdyB0byBhY3R1YWxseSBpbXBs ZW1lbnQgeW91ciBwcm9wb3NhbC4gIEFsbG93aW5nIGVhY2ggRE9UUyBHVyB0byBsZWFybiBhbmQg cGFzcyBvbiBzb21ldGhpbmcgZXh0cmEgdGhhdCBkaWZmZXJlbnRpYXRlcyB0aGUgRE9UUyBHVyBp bW1lZGlhdGUgY2xpZW50cyBtYWtlcyB0aGUgaW1wbGVtZW50YXRpb24gcmVsYXRpdmVseSBlYXN5 LiAgVGhlcmUgaXMgbm8gbmVlZCBmb3IgYSBET1RTIEdXIHRvIGFkZCBpbiBhZGRpdGlvbmFsIGlu Zm9ybWF0aW9uIGlmIGV4dHJhIGluZm9ybWF0aW9uIGlzIGFscmVhZHkgZW1iZWRkZWQg4oCTIHVu bGVzcyBoZSBzZWVzIGEgbmFtZSBjbGFzaCBmcm9tIDIgb3IgbW9yZSBvZiBoaXMgdW5pcXVlbHkg aWRlbnRpZmllZCBET1RTIGNsaWVudHMg4oCTIHdoaWNoIHdpbGwgYmUgZGlmZmVyZW50IGVudGl0 aWVzIGFueXdheS4NCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFpbHRvOiBkb3Rz LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAxMCBPY3RvYmVyIDIwMTcgMTU6 NTINClRvOiBKb24gU2hhbGxvdzsga2FuYW1lIG5pc2hpenVrYTsgbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0 Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucw0KU3ViamVjdDogUmU6 IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KVGhlIGNvbmZsaWN0aW5nIGFsaWFz LW5hbWVzIGZyb20gRE9UUyBjbGllbnQgKGMxKSBhbmQgYW5vdGhlciBjbGllbnQgKGxldOKAmSBj YWxsIChjMTEpKSBiZWhpbmQgKHMxKSBzaG91bGQgYmUgcmVzb2x2ZWQgYnkgczEgaXRzZWxmLCBp dCBpcyBhbHNvIHRoZSByZXNwb25zaWJpbGl0eSBvZiAoczEpIHRvIHJlc29sdmUgY29uZmxpY3Rp bmcgbWl0aWdhdGlvbiByZXF1ZXN0cyBmcm9tIChjMSkgYW5kIChjMTEpLCBhZ2dyZWdhdGUgdGhl IG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBjbGllbnRzIChjMSBhbmQgYzExKSBh bmQgc2VuZCB0aGUgdXBkYXRlZCBtaXRpZ2F0aW9uIHJlcXVlc3QgKGMyKS4NCg0KLVRpcnUNCg0K RnJvbTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KU2Vu dDogVHVlc2RheSwgT2N0b2JlciAxMCwgMjAxNyA4OjExIFBNDQpUbzogS29uZGEsIFRpcnVtYWxl c3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGly dW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4+OyBrYW5hbWUgbmlzaGl6dWthIDxrYW5h bWVAbnR0djYuanA8bWFpbHRvOmthbmFtZUBudHR2Ni5qcD4+OyBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZG90c0BpZXRm Lm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJv ci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERP VFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSBUaXJ1LA0KDQpJIGFncmVlIGluIHBhcnQsIGJ1 dCB3ZSBuZWVkIHRvIGxvb2sgYXQgdGhlIGVuZCAoYzEpIHRvIGVuZCAoczMpIHBvdGVudGlhbCBp c3N1ZXMuICBXaGF0IHlvdSBhcmUgcHJvcG9zaW5nIHdvcmtzIGZpbmUgZm9yIChzMikgdG8gKHMz KS4NCg0KKGMxKSByZXF1ZXN0cyBtaXRpZ2F0aW9uIHdpdGggYW4gYWxpYXMtbmFtZSDigJxhbGlh cy0x4oCdLiAgSWYgKHMxKSBkb2VzIG5vdCBwYXNzIGFueXRoaW5nIGV4dHJhIHRvIChjMikgZm9y IG9ud2FyZCB0cmFuc21pc3Npb24sIChzMikgc2VlcyBhIHNpbmdsZSBjbGllbnQgKGMyKSByZXF1 ZXN0aW5nIG1pdGlnYXRpb24gd2l0aCBhbGlhcy1uYW1lIOKAnGFsaWFzLTHigJ0uICBGaW5lLCB0 aGF0IHdvcmtzLg0KSWYgdGhlcmUgd2FzIGFub3RoZXIgRE9UUyBjbGllbnQgaW4gdGhlIHNhbWUg bG9jYXRpb24gYXMgKGMxKShpLmUuIGMxZGlmZiksIGJvdGggdXNpbmcgKHMxKSB3aG8gYWxzbyBk ZWNpZGVkIHRvIHVzZSBhbGlhcy1uYW1lIOKAnGFsaWFzLTHigJ0gd2hvIHRoZW4gcmVxdWVzdHMg bWl0aWdhdGlvbiwgKHMyKSBoYXMgbm8gaWRlYSB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQg4oCc YWxpYXMtMeKAnSBkZWZpbml0aW9ucyBpZiAoYzIpIGRvZXMgbm90IHNlbmQgYWxzbyBhbiBleHRy YSBkaWZmZXJlbnRpYXRvci4NCg0KU28sIGFueSBET1RTIEdXIGluIHRoZSBjaGFpbiBzaG91bGQg YmUgcGFzc2luZyBvbiBhIOKAnHVuaXF1ZS1leHRyYeKAnSBwaWVjZSBvZiBpbmZvcm1hdGlvbi4N Cg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBLb25kYSwg VGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAxMCBPY3RvYmVyIDIwMTcgMTU6MTUNClRvOiBKb24g U2hhbGxvdzsga2FuYW1lIG5pc2hpenVrYTsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRv OmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucw0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RT IEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KQWdyZWUgd2l0aCB5b3VyIHJlc3BvbnNlLCBjb25zaWRl ciBhIGRlcGxveW1lbnQgd2hpY2ggaGFzIHRoZSBmb2xsb3dpbmcgRE9UUyBhZ2VudHMuDQoNCkRP VFMgY2xpZW50cyAoYzEpIDwtLS0tLS0tLS0tLS0tLS0tLS0tLT4gKHMxKSBjbGllbnQtc2lkZSBE T1RTIGdhdGV3YXkgKGMyKSA8LS0tLS0tLS0tLS0tLS0tLT4gKHMyKSBzZXJ2ZXItc2lkZSBET1RT IGdhdGV3YXkgKGMzKSA8LS0tLS0tLS0tLS0tLS0+IChzMykgRE9UUyBzZXJ2ZXINCg0KTXkgcG9p bnQgaXMsIChjMikgbmVlZCBub3QgY29udmV5IHRoZSDigJxjMSBpZGVudGl0eeKAnSB0byAoczIp IGJ1dCAoczIpIG5lZWRzIHRvIGNvbnZleSB0aGUg4oCcYzIgaWRlbnRpdHnigJ0gdG8gKGMzKSBh bmQgKGMzKSBpbi10dXJuIHByb3BhZ2F0ZXMgdGhlIOKAnGMyIGlkZW50aXR54oCdIHRvIChzMyku DQoNCi1UaXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFs bG93LmNvbV0NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgNjoxNSBQTQ0KVG86IEtv bmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5j b208bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+Pjsga2FuYW1lIG5p c2hpenVrYSA8a2FuYW1lQG50dHY2LmpwPG1haWx0bzprYW5hbWVAbnR0djYuanA+PjsgbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT47IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+OyBSb2xhbmQgRG9iYmlucyA8 cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0KU3ViamVjdDog UkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMNCg0KSGkgVGlydSwNCg0KQWdyZWVk IHRoYXQgb25seSBhIERPVFMgR1cgc2VydmVyIGZhY2luZyBuZWVkcyB0byBzZW5kIGluZm9ybWF0 aW9uIHRvIHRoZSB1cHN0cmVhbSBET1RTIFNlcnZlciDigJMgd2hpY2ggY291bGQgYWxzbyBiZSBh IERPVFMgR1cuDQogICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQogICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICB8IEQgfCAgICB8DQogICAgICAgICArLS0tLSsgICAg ICAgICAgfCAgICB8IE8gfCAgICB8ICAgICAgICAgKy0tLS0rDQogICAgICAgICB8IGMxIHwtLS0t LS0tLS0tfCBzMSB8IFQgfCBjMiB8LS0tLS0tLS0tfCBzMiB8DQogICAgICAgICArLS0tLSsgICAg ICAgICAgfCAgICB8IFMgfCAgICB8ICAgICAgICAgKy0tLS0rDQogICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICB8IEcgfCAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0rDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLWFyY2hp dGVjdHVyZS0wNCNzZWN0aW9uLTIuMi4zDQoNCkhvd2V2ZXIsIHRoZSBET1RTIEdXIGNsaWVudCBm YWNpbmcgKHMxKSBpcyB0aGUgb25lIHdpdGgga25vd2xlZGdlIG9mIHRoZSBpbmRpdmlkdWFsIGNs aWVudHMgdGhhdCBhcmUgY3VycmVudGx5IHVzaW5nICB0aGUgRE9UUyBzZXJ2ZXIgcnVubmluZyBv biB0aGUgRE9UUyBHVy4gIFRoaXMgaW5mb3JtYXRpb24gaGFzIHRvIHNvbWVob3cgYmUgcGFzc2Vk IG92ZXIgdG8gdGhlIERPVFMgR1cgc2VydmVyIGZhY2luZyAoYzIpLCBidXQgc2VwYXJhdGUgRE9U UyBzdGFja3MgYXJlIGJlaW5nIHJ1biBmb3IgKHMxKSBhbmQgKGMyKSBhcyBwZXIgYXJjaGl0ZWN0 dXJlIHNwZWMgMi4yLjMuICBJIHdhcyByZWZlcnJpbmcgdG8gd2hhdCAoczEpIG1heSBuZWVkIHRv IHBhc3Mgb24gdG8gKGMyKSBpbiBteSBlbWFpbCByZXNwb25zZSB0byBLYW5hbWUsIG5vdCB3aGF0 IGlzIHNlbnQgYnkgKGMxKS4NCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBbbWFpbHRv OiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9u IEJlaGFsZiBPZiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpTZW50OiAxMCBPY3RvYmVyIDIw MTcgMTM6MTYNClRvOiBKb24gU2hhbGxvdzsgJ2thbmFtZSBuaXNoaXp1a2EnOyBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsg ZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zDQpTdWJq ZWN0OiBSZTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpJIHRob3VnaHQgd2Ug YWdyZWVkIHRoYXQgYmFzZWQgb24gdGhlIGN1cnJlbnQgRE9UUyByZXF1aXJlbWVudHMgb25seSB0 aGUgc2VydmVyLXNpZGUgRE9UUyBHVyBuZWVkcyB0byBjb252ZXkgdGhlIERPVFMgY2xpZW50IChv ciBjbGllbnQtc2lkZSBET1RTIFdHKSBpZGVudGl0eSB0byB0aGUgRE9UUyBzZXJ2ZXIuDQoNCi1U aXJ1DQoNCkZyb206IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNv bV0NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgMjo1MyBQTQ0KVG86ICdrYW5hbWUg bmlzaGl6dWthJyA8a2FuYW1lQG50dHY2LmpwPG1haWx0bzprYW5hbWVAbnR0djYuanA+PjsgS29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNv bTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4+OyBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsg ZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFuZCBEb2JiaW5zIDxyZG9i Ymluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQpTdWJqZWN0OiBSRTog W0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlcw0KDQpIaSBLYW5hbWUsDQoNCkkgZG8gbm90 IHRoaW5rIHRoYXQgaW5mb3JtYXRpb24gbmVjZXNzYXJpbHkgbmVlZHMgdG8gYmUgdGhlIG9yaWdp bmFsIGNsaWVudCBpZGVudGl0eS4gIFRoZSBHVyBDbGllbnQgc2lkZSB3aWxsIGhhdmUgaXRzIG93 biBpZGVudGl0eSB3aGljaCB0aGUgRE9UUyBTZXJ2ZXIgY2FuIHVzZSB0byBkaWZmZXJlbnRpYXRl IGJldHdlZW4gRE9UUyAoR1cpIENsaWVudHMuDQoNClNvLCB5ZXMsIGEgaGFzaGVkIHNldCBvZiBu YW1lcyBjYW4gYmUgdXNlZCDigJMgaXQgaXMgdXAgdG8gdGhlIERPVFMgR1cgQ2xpZW50IHNpZGUg dG8gbWFrZSBzdXJlIHRoYXQgdGhlcmUgYXJlIG5vIGhhc2ggY29sbGlzaW9ucy4gIE9yIGl0IGNv dWxkIGJlIGEgc2ltcGxlIGxpc3Qgc3VjaCBhcyBDMSwgQzIg4oCmQ24uDQoNClJlZ2FyZHMNCg0K Sm9uDQoNCkZyb206IERvdHMgW21haWx0bzogZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpk b3RzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yga2FuYW1lIG5pc2hpenVrYQ0KU2Vu dDogMTAgT2N0b2JlciAyMDE3IDA0OjE5DQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsg Sm9uIFNoYWxsb3c7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3Jn PjsgUm9sYW5kIERvYmJpbnMNClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFs bGVuZ2VzDQoNCkhpLA0KDQo+IEkgYWdyZWUgdGhlIGJlbG93IHByb2JsZW1zIGFyZSBhcHBsaWNh YmxlIGZvciBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXksIGl0IG11c3QgY29udmV5IHRoZSDigJxj bGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLg0KSSBhZ3JlZSB3aXRoIHRoaXMg c2VydmVyLXNpZGUgRE9UUyBnYXRld2F5IGNhc2UuDQpBdCB0aGUgc2FtZSB0aW1lLCBJIGFncmVl IHdpdGggYmVsb3c6DQo+IEkgYWdyZWUgdGhhdCBpcyBub3QgYSBnb29kIHRoaW5nIHRvIOKAnGxl YWvigJ0gb3V0IGludGVybmFsIGluZm9ybWF0aW9uIHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9U UyBHVywNCg0KVGhlbiwgc2hvdWxkIERPVFMgR1cgc2VuZCDigJxjbGllbnQgaWRlbnRpdHnigJ0g KGkuZS4gY2VydGlmaWNhdGVzIG9mIERPVFMgY2xpZW50cykgaXRzZWxmIG9yIGhhc2hlZCjigJxj bGllbnQgaWRlbnRpdHnigJ0pIHRvIERPVFMgc2VydmVyPw0KSWYgbGF0ZXIsIGhvdyBjYW4gRE9U UyBzZXJ2ZXIgcmVhY3QgdG8gdGhlIGFtYmlndW91cyBpbmZvcm1hdGlvbiBvZiB0aGUgaGFzaGVk KOKAnGNsaWVudCBpZGVudGl0eeKAnSkuDQoNCnJlZ2FyZHMsDQpLYW5hbWUNCk9uIDIwMTcvMTAv MDkgMjI6MzQsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgd3JvdGU6DQpIaSBKb24sDQoNCkkg YWdyZWUgdGhlIGJlbG93IHByb2JsZW1zIGFyZSBhcHBsaWNhYmxlIGZvciBzZXJ2ZXItc2lkZSBE T1RTIGdhdGV3YXksIGl0IG11c3QgY29udmV5IHRoZSDigJxjbGllbnQgaWRlbnRpdHnigJ0gdG8g dGhlIERPVFMgc2VydmVyLiBCdXQgZm9yIHRoZSBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksIGl0 IHNob3VsZCByZXNvbHZlIGNvbmZsaWN0aW5nIHJ1bGVzIGIvdyBET1RTIGNsaWVudHMgKGUuZy4g b25lIGNsaWVudCBpbnN0YWxsaW5nIGJsYWNrLWxpc3QgQUNMIGZvciBhbiBJUCBhZGRyZXNzIGJ1 dCB0aGUgb3RoZXIgY2xpZW50IGluc3RhbGxzIHdoaXRlLWxpc3QgQUNMIGZvciB0aGUgc2FtZSBJ UCBhZGRyZXNzLCBzYW1lIGFsaWFzLW5hbWVzIGZvciBkaWZmZXJlbnQgbWl0aWdhdGlvbiBzY29w ZXMpLiBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkIGZvciBhIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdh eSB0byBjb252ZXkgdGhlIOKAnGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgc2VydmVyLXNpZGUg RE9UUyBnYXRld2F5IG9yIERPVFMgc2VydmVyLg0KDQotVGlydQ0KDQpGcm9tOiBKb24gU2hhbGxv dyBbbWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQpTZW50OiBTYXR1cmRheSwgT2N0 b2JlciA3LCAyMDE3IDI6MDcgUE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1 bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlf S29uZGFATWNBZmVlLmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGll dGYub3JnPjsgUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD48bWFpbHRvOnJkb2Ji aW5zQGFyYm9yLm5ldD4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVu Z2VzDQoNCkhpIFRpcnUsDQoNClRoaXMgZGlzY3Vzc2lvbiBnb2VzIGJleW9uZCBqdXN0IHRoZSBt aXRpZ2F0aW9uIHJlcXVlc3QuICBXZSBuZWVkIHRvIGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3aXRo IGJvdGggYWxpYXMtbmFtZSBhbmQgYWNsLW5hbWUgKGRhdGEgY2hhbm5lbCkNCg0KVGhlIHNpbXBs ZSBjYXNlIG9mIGEgbWl0aWdhdGlvbiByZXF1ZXN0IHdpdGggbm8gYWxpYXMtbmFtZSBkb2VzIG5v dCByZXF1aXJlIGFueSBrbm93bGVkZ2Ugb2YgdGhlIG9yaWdpbmFsIGNsaWVudC4NCg0KSG93ZXZl ciwgaWYgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCB1c2VzIGFsaWFzLW5hbWUsIHRoZW4gdGhlcmUg YXJlIDMgd2F5cyBvZiBoYW5kbGluZyB0aGlzDQoNCmEpICAgICAgIFRoZSBET1RTIEdXIHJlcGxh Y2VzIHRoZSBhbGlhcy1uYW1lIHdpdGggaXRzIGFjdHVhbCBkZWZpbml0aW9uICh0YXJnZXQtaXBz IGV0Yy4gbWVyZ2VkIGFzIGFwcHJvcHJpYXRlKSwgc28gYWxpYXMtbmFtZSBpcyBub3QgZm9yd2Fy ZGVkIG9uIHRvIFNlcnZlciDigJMganVzdCB0aGUgZXhwYW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0 IGlzIGZvcndhcmRlZA0KDQpiKSAgICAgIFRoZSBET1RTIEdXIHVwZGF0ZXMgdGhlIGFsaWFzLW5h bWUgd2l0aCBhIHVuaXF1ZSBhbGlhcy1uYW1lIHRoYXQgaXMgZm9yd2FyZGVkIChhbmQgaGFzIHRv IGRvIHRoZSBzYW1lIHRoaW5nIHdoZW4gdGhlIGFsaWFzLW5hbWUgaXMgY29uZmlndXJlZCBvbiB0 aGUgZGF0YSBjaGFubmVsKSDigJMgdG8gaGFuZGxlIDIgb3IgbW9yZSBjbGllbnRzIGRlZmluaW5n IHRoZSBzYW1lIGFsaWFzLW5hbWUgd2hpY2ggaGF2ZSBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNz DQoNCmMpICAgICAgIFRoZSBET1RTIEdXIHJlY29nbmlzZXMgdGhhdCBhbGlhcy1uYW1lIGlzIG5v dCB1bmlxdWUgYW5kIGFkZHMgaW4g4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSAoSSB0aGlu ayBJIHByZWZlciB0aGlzIOKAnC1pbmZv4oCdIG5hbWUgdG8gY2xpZW50LWlkIG9yIG9yaWdpbmFs LWNsaWVudC1pZCBhcyDigJwtaWTigJ0gaXMgdG9vIGNsb3NlbHkgIGFzc29jaWF0ZWQgd2l0aCBD bGllbnQgSWRlbnRpdHkgZGVyaXZlZCBmcm9tIHRoZSBET1RTIEdXIENsaWVudCBjZXJ0aWZpY2F0 ZSkNCldlIGhhdmUgYWdyZWVkIHRoYXQgd2hlbiBhIGNsaWVudCByZXF1ZXN0cyBtaXRpZ2F0aW9u IHN0YXR1cywgdGhlIOKAnGFsaWFzLW5hbWXigJ0gc2hvdWxkIGJlIHJldHVybmVkIGFzIOKAnGFs aWFzLW5hbWXigJ0gYW5kIG5vdCB0aGUgc3Vic3RpdHV0ZWQgYWxpYXMtbmFtZSBjb25maWd1cmF0 aW9uICh0aGlzIGRvZXMgbmVlZCB0byBiZSBzdGF0ZWQgaW4gdGhlIHNwZWMgZm9yIGNsYXJpdHkp LiAgVGhpcyBtYWtlcyAoYSkgZGlmZmljdWx0IHRvIGJlIGhhbmRsZWQgYnkgRE9UUyBHVyB3aGlj aCB0aGVuIHJhaXNlcyB0aGUgcXVlc3Rpb24g4oCTIGRvIHdlIHJlYWxseSBuZWVkIGFsaWFzLW5h bWU/DQoNClRoZSBkZWZpbml0aW9uIGFuZCBhc3NvY2lhdGlvbiBvZiBBQ0xzL0ZpbHRlcnMgb2Yg dGhlIGRhdGEgY2hhbm5lbCBpcyBtb3JlIGRpZmZpY3VsdCDigJMgdGhlIFNlcnZlciBtdXN0IGlu c3RhbGwgLyBhcHBseSB0aGUgYXBwcm9wcmlhdGUgQUNMcyBvbiBhIHBlciAoT3JpZ2luYWwpIENs aWVudCBiYXNpcyB3aGVuIG1pdGlnYXRpb24gaXMgaW52b2tlZC4NCkNsaWVudCAx4oCZcyBjb25j ZXB0IG9mIGEgV2hpdGVsaXN0IElQIGNvdWxkIGJlIENsaWVudCAy4oCZcyBjb25jZXB0IG9mIGEg QmxhY2tsaXN0IElQLiAgVGhlIFNlcnZlciBuZWVkcyB0byBrbm93IHdoaWNoIGNsaWVudCBpcyBy ZXF1ZXN0aW5nIHRoZSBtaXRpZ2F0aW9uIGFuZCBpbnN0YWxsIHRoZSBjb3JyZWN0IEFDTHMg4oCT IGlmIHRoZXJlIHdhcyBubyDigJ1hZGRpdGlvbmFsLWNsaWVudC1pbmZv4oCdLCB0aGUgU2VydmVy IG9ubHkga25vd3MgdGhhdCBoZSBoYXMgdG8gaW5zdGFsbCBBTEwgb2YgdGhlIEFDTHMgKGkuZS4g Ym90aCB0aGUgQmxhY2sgYW5kIFdoaXRlIGxpc3Qgb2YgdGhlIHNhbWUgSVAgYXMgZGVmaW5lZCBi eSBDbGllbnQgMSBhbmQgQ2xpZW50IDIpIGFzIGRlZmluZWQgYnkgaGlzIGNsaWVudCAoRE9UUyBH Vykgd2hlbiBoaXMgY2xpZW50IHJlcXVlc3RzIGEgbWl0aWdhdGlvbi4gIEhlcmUsIEkgdGhpbmsg dGhhdCBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGNsaWVudCBmb3IgdGhlIERPVFMgR1csIOKA nWFkZGl0aW9uYWwtY2xpZW50LWluZm/igJ0gaXMgcmVxdWlyZWQuDQoNClJlZ2FyZHMNCg0KSm9u DQoNCkZyb206IERvdHMgW21haWx0bzogZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3Rz LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRk eQ0KU2VudDogMDcgT2N0b2JlciAyMDE3IDA0OjI4DQpUbzogSm9uIFNoYWxsb3c7IG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMNClN1 YmplY3Q6IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzDQoNCkluIGNhc2Ugb2Yg Y2xpZW50LXNpZGUgRE9UUyBnYXRld2F5LCB3aHkgZG9lcyB0aGUgRE9UUyBzZXJ2ZXIgbmVlZCB0 byBrbm93IHdoaWNoIOKAnERPVFMgY2xpZW504oCdIGhhcyBjb252ZXllZCB0aGUgbWl0aWdhdGlv biByZXF1ZXN0ID8NCkZvciBleGFtcGxlLCB0aGUgRE9UUyBjbGllbnQgY291bGQgYmUgYSBERG9T IGRldGVjdG9yIG9yIGFuIEFwcGxpY2F0aW9uIHNlcnZlciwgYW5kIHRoZSBjbGllbnQtc2lkZSBn YXRld2F5IHdpbGwgaGF2ZSB0byByZXNvbHZlIHRoZSBjb25mbGljdGluZyBtaXRpZ2F0aW9uIHJl cXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50cywgYWdncmVnYXRlIHRoZSBtaXRpZ2F0aW9uIHJl cXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50IGFuZCBzZW5kIHRoZSB1cGRhdGVkIG1pdGlnYXRp b24gcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuDQoNCi1UaXJ1DQoNCkZyb206IEpvbiBTaGFs bG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NClNlbnQ6IEZyaWRheSwgT2N0 b2JlciA2LCAyMDE3IDc6NDIgUE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1 bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9L b25kYUBNY0FmZWUuY29tPj47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGll dGYub3JnPjsgUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJp bnNAYXJib3IubmV0Pj4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVu Z2VzDQoNCkhpIFRpcnUsDQoNClVubGVzcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBob3cgZG9l cyB0aGUgQ2xpZW50IHNpZGUgb2YgRE9UUyBHVyBjb252ZXkgdG8gdGhlIHVwc3RyZWFtIHNlcnZl ciBhIHVuaXF1ZSDigJxjbGllbnQtaWTigJ0gd2hpY2ggaXMgZGlmZmVyZW50IHRvIHRoZSBpbXBs aWVkIGNsaWVudCBpZCBhcyBkZXJpdmVkIGZyb20gdGhlIFBLSSBjZXJ0aWZpY2F0ZSB0aGF0IHRo ZSBET1RTIEdX4oCZQ2xpZW50IHVzZXMvcHJlc2VudHMgd2hlbiBjb21tdW5pY2F0aW5nIHRvIHRo ZSBzZXJ2ZXI/DQpUbyBtZSwgdGhlcmUgbmVlZHMgdG8gYmUgYW4gb3B0aW9uIHN1Y2ggYXMg4oCc b3JpZ2luYWwtY2xpZW50LWlk4oCdIG9yIOKAnGNsaWVudC1pZOKAnSAod2hpY2ggaXMgY29uZnVz aW5nIHdoZW4gYWxzbyByZWZlcnJpbmcgdG8gdGhlIGNsaWVudCBpZGVudGl0eSBhcyBkZXJpdmVk IGZyb20gdGhlIChET1RTIEdXKSBDbGllbnTigJlzIFBLSSBjZXJ0aWZpY2F0ZSkgYXMgYSBwYXJ0 IG9mIHRoZSBwcm90b2NvbC4NCg0KSSBhZ3JlZSB0aGF0IHRoZSBET1RTIEdXIGNhbiBnZW5lcmF0 ZSBpdHMgb3duIHVuaXF1ZSBjbGllbnQtaWQgdG8gc3RvcCBtdWx0aXBsZSBlbnRyaWVzIGJlaW5n IG5lZWRlZC4NCg0KSSBhZ3JlZSB0aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g4oCcbGVha+KA nSBvdXQgaW50ZXJuYWwgaW5mb3JtYXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2ggYSBET1RTIEdX LCBzbyBteSBSRVFVSVJFRCBkb2VzIG5vdCBtYWtlIHNlbnNlLg0KDQpSZWdhcmRzDQoNCkpvbg0K UFMg4oCTIEkgYW0gaGF2aW5nIHRvIGRlYWwgd2l0aCBvdGhlciBzdHVmZiBhdCBwcmVzZW50IOKA kyBJIHdpbGwgZ2V0IGJhY2sgbGF0ZXIgb24gdGhlIG90aGVyIGlzc3VlcyB1bmRlciBkaXNjdXNz aW9uDQoNCkZyb206IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgW21haWx0bzogVGlydW1hbGVz d2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFA bWNhZmVlLmNvbT5dDQpTZW50OiAwNiBPY3RvYmVyIDIwMTcgMTQ6NTgNClRvOiBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsg Sm9uIFNoYWxsb3c7ICdEb2JiaW5zLCBSb2xhbmQnOyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3Rz QGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXMN Cg0KSSBkb27igJl0IHNlZSBhIG5lZWQgZm9yIGNsaWVudC1zaWRlIERPVFMgZ2F0ZXdheSB0byBj b252ZXkgdGhlIOKAnERPVFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4g 4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gbG9va3MgcmVxdWlyZWQgb25seSBmb3IgdGhlIHNl cnZlci1zaWRlIERPVFMgZ2F0ZXdheXMuIEluIGNhc2Ugb2Ygc2VydmVyLXNpZGUgRE9UUyBnYXRl d2F5LCBpdCBjYW4gY29udmV5IHRoZSBjbGllbnQtaWQgZ2VuZXJhdGVkIGZyb20gdGhlIOKAnERP VFMgY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4gVGhlIERPVFMgZ2F0ZXdh eSBjYW4gZ2VuZXJhdGUgYSB1bmlxdWUgY2xpZW50LWlkIGFuZCBkb2VzIG5vdCBoYXZlIHRvIHNl bmQgYW4gYXJyYXkgb2YgY2xpZW50LWlkcyB0byB0aGUgRE9UUyBzZXJ2ZXIgdG8gcmVzb2x2ZSBj bGFzaGVzLg0KDQotVGlydQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCkRvdHMgbWFpbGluZyBsaXN0DQoNCkRvdHNAaWV0Zi5vcmc8bWFpbHRv OkRvdHNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG90cw0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpEb3RzIG1haWxpbmcgbGlzdA0KDQpEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGll dGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg0K --_000_DM5PR16MB1788774A0B6F0CFFA3B688C9EA4A0DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQg MiAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCglj b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBV SSIsc2Fucy1zZXJpZjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNl cmlmO30NCnAuVGV4dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxs ZXMNCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6 IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQt d2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTMxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMzUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVt YWlsU3R5bGUzNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTQwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlNDENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGU0Mg0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTQzDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+VGhhbmtzIEpvbiBmb3IgdGhlIGNsYXJpZmljYXRpb24s IEkgd2lsbCB1cGRhdGUgYm90aCBzaWduYWwgYW5kIGRhdGEgY2hhbm5lbCBkcmFmdHMgdG8gYWRk cmVzcyB0aGUgY29tbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpw cy1pZXRmQGpwc2hhbGxvdy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBPY3Rv YmVyIDExLCAyMDE3IDQ6MzggUE08YnI+DQo8Yj5Ubzo8L2I+ICdrYW5hbWUgbmlzaGl6dWthJyAm bHQ7a2FuYW1lQG50dHY2LmpwJmd0OzsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7VGly dW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSZndDs7IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb207IGRvdHNAaWV0Zi5vcmc7IFJvbGFuZCBEb2JiaW5zICZsdDtyZG9iYmluc0BhcmJv ci5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBD aGFsbGVuZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBLYW5hbWUgLyBU aXJ1LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5TZWUgaW5saW5lIOKAkyBbSm9uMV0gMyBpbiBLYW5hbWHigJlzIHJl c3BvbnNlIGFuZCAzIGluIFRpcnXigJlzIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBEb3RzIFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86 ZG90cy1ib3VuY2VzQGlldGYub3JnIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBC ZWhhbGYgT2YNCjwvYj5rYW5hbWUgbmlzaGl6dWthPGJyPg0KPGI+U2VudDo8L2I+IDExIE9jdG9i ZXIgMjAxNyAxMDo0Nzxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsg Sm9uIFNoYWxsb3c7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t Ij4NCm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZG90 c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5IaSBK b24sIFRpcnUsPGJyPg0KPGJyPg0KJmd0OyAoYzEpIHJlcXVlc3RzIG1pdGlnYXRpb24gd2l0aCBh biBhbGlhcy1uYW1lIOKAnGFsaWFzLTHigJ0uJm5ic3A7IElmIChzMSkgZG9lcyBub3QgcGFzcyBh bnl0aGluZyBleHRyYSB0byAoYzIpIGZvciBvbndhcmQgdHJhbnNtaXNzaW9uLCAoczIpIHNlZXMg YSBzaW5nbGUgY2xpZW50IChjMikgcmVxdWVzdGluZyBtaXRpZ2F0aW9uIHdpdGggYWxpYXMtbmFt ZSDigJxhbGlhcy0x4oCdLiZuYnNwOyBGaW5lLCB0aGF0IHdvcmtzLjxicj4NCiZndDsgSWYgdGhl cmUgd2FzIGFub3RoZXIgRE9UUyBjbGllbnQgaW4gdGhlIHNhbWUgbG9jYXRpb24gYXMgKGMxKShp LmUuIGMxZGlmZiksIGJvdGggdXNpbmcgKHMxKSB3aG8gYWxzbyBkZWNpZGVkIHRvIHVzZSBhbGlh cy1uYW1lIOKAnGFsaWFzLTHigJ0gd2hvIHRoZW4gcmVxdWVzdHMgbWl0aWdhdGlvbiwgKHMyKSBo YXMgbm8gaWRlYSB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQg4oCcYWxpYXMtMeKAnSBkZWZpbml0 aW9ucyBpZiAoYzIpIGRvZXMgbm90IHNlbmQgYWxzbw0KIGFuIGV4dHJhIGRpZmZlcmVudGlhdG9y LiA8YnI+DQo8YnI+DQpGcm9tIHRoZSB2aWV3cG9pbnQgb2YgczIsIGlmIHRoZXJlIGlzIGEgZGlm ZmVyZW50aWF0b3Igb2YgcmVxdWVzdCBmcm9tIGMxIGFuZCBjMWRpZmYsIGl0IHdpbGwgYXNzaXN0 IHNvbWUgc2l0dWF0aW9uLiBGb3IgZXhhbXBsZSwgYSByZXRyaWV2YWwgcmVxdWVzdCBvZiBleGlz dGluZyBtaXRpZ2F0aW9uIGxpc3QgZnJvbSBjMiB3aWxsIGdldCBhbGwgb2YgdGhlIGRhdGEgZnJv bSBzMiBpZiB0aGVyZSBpcyBubyBkaWZmZXJlbnRpYXRvciBpbiB0aGUgcmVxdWVzdCwNCiBob3dl dmVyIGlmIHRoZXJlIGlzLCBzMiBjYW4gcmV0dXJuIG9ubHkgdGhlIHJlbGF0ZWQgaW5mb3JtYXRp b24gb2Ygc3BlY2lmaWMgb25lLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5bSm9uMV0gQWdyZWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i RU4tR0IiPjxicj4NCkJ1dCwgSSBkb24ndCB0aGluayBzdWNoIGtpbmQgb2YgZGlmZmVyZW50aWF0 b3IgaXMgcmVxdWlyZWQgYmV0d2VlbiBjMSBhbmQgczEsIGJlY2F1c2UgczEgc2hvdWxkIGlkZW50 aWZ5IGMxIGJhc2VkIG9uIOKAnGNsaWVudCBpZGVudGl0eeKAnSB3aGljaCB3aWxsIGJlIGNlcnRp ZmljYXRlIG9mIGMxIGlmIHRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24gaXMgUEtJLWJhc2VkLiBL ZWVwaW5nIHRoZSBiaW5kaW5nIG9mIOKAnGNsaWVudCBpZGVudGl0eeKAnSZuYnNwOyBhbmQgKG9y aWdpbmFsKS1jbGllbnQtaWQNCiBpbiBzaWduYWwgbWVzc2FnZSBpcyBhIGxpdHRsZSBiaXQgY29t cGxpY2F0ZWQgaW1wbGVtZW50YXRpb24gb2YgczEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltKb24xXSBBZ3JlZWQg4oCTIGJ1dCAoczIpIGFu ZCAoczMpIHdpbGwgaGF2ZSB0byBkbyB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i RU4tR0IiPjxicj4NClJlZ2FyZGluZyB0aGUgZGF0YS1jaGFubmVsLCB0aGVyZSBpcyBhIHBvc3Np YmlsaXR5IG9mIGNvbGxpc2lvbiBpbiBhbGlhcy1uYW1lIGFtb25nIGMxLCBjMWRpZmYsLCwsIHNv IHNob3VsZCB3ZSBuZWVkIHRvIGRlc2NyaWJlIGhvdyB0byBiaW5kIGEgZGF0YS1jaGFubmVsIGFu ZCBzaWduYWwtY2hhbm5lbCBmb3IgdmFyaW91cyBtdXR1YWwgYXV0aGVudGljYXRpb24gcGF0dGVy bnMgbGlrZSBQS0ksIFNQS0ksIFRMUy1QS0kgZXRjLC4uIGluIHRoZSBkcmFmdD8NCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bSm9uMV0gSW4gbXkg Y3VycmVudCBpbXBsZW1lbnRhdGlvbiwgYWxpYXMtbmFtZSAod2hldGhlciBkYXRhIG9yIHNpZ25h bCBjaGFubmVsKSBpcyBhc3NvY2lhdGVkIHdpdGggYSBjbGllbnQtaWQgKGFuZA0KIHBvc3NpYmx5 IOKAnGV4dHJhLWNsaWVudC1pbmZv4oCdIChub3QgeWV0IGNvZGVkKSkuJm5ic3A7IFRoZSBkZWNp c2lvbiBoZXJlIGlzIHdoZXRoZXIgd2UgaGF2ZSBhIHNpbmdsZSBwb29sIG9mIGFsaWFzLW5hbWVz IChhbmQgQUNMcykgb24gYSBET1RTIHNlcnZlciwgb3IgZWFjaCBET1RTIHNlcnZlciAoc3RhbmRh bG9uZSBvciBpbiBhIEdXKSBtYWludGFpbnMgc2VwYXJhdGUgbGlzdHMg4oCTIG9uZSBwZXIgY2xp ZW50LWlkLiZuYnNwOyBBbmQgdGhpcyBzaG91bGQgYmUgc3RhdGVkDQogaW4gdGhlIHNwZWNzIGZv ciBjbGFyaXR5Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PGJyPg0KPGJyPg0KcmVnYXJkcyw8 YnI+DQpLYW5hbWU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPk9uIDIwMTcvMTAvMTEgMTM6MzgsIEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+SGkgSm9uLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+UGxlYXNlIHNlZSBpbmxpbmUNCjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3 aW5kb3d0ZXh0Ij4gSm9uIFNoYWxsb3cgWzxhIGhyZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNo YWxsb3cuY29tIj5tYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBPY3RvYmVyIDExLCAyMDE3IDEyOjQ0IEFNPGJyPg0KPGI+ VG86PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxhIGhyZWY9Im1haWx0bzpUaXJ1bWFs ZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj4NCiZsdDtUaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBNY0FmZWUuY29tJmd0OzwvYT47IGthbmFtZSBuaXNoaXp1a2EgPGEgaHJlZj0ibWFpbHRvOmth bmFtZUBudHR2Ni5qcCI+DQombHQ7a2FuYW1lQG50dHY2LmpwJmd0OzwvYT47IDxhIGhyZWY9Im1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3Jn PC9hPjsgUm9sYW5kIERvYmJpbnMgPGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+ DQombHQ7cmRvYmJpbnNAYXJib3IubmV0Jmd0OzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5IaSBUaXJ1LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IGFueSBjb25mbGljdGluZyByZXF1ZXN0 IG5lZWQgdG8gYmUgc29ydGVkIG91dCBieSB0aGUgcmVzcGVjdGl2ZSBET1RTIHNlcnZlciBjb21w b25lbnQg4oCTIFNJRy0wMDkgLSBlc3BlY2lhbGx5IGlmIHRoZXJlIGFyZSBjb25mbGljdHMNCiBv dmVyIElQIGFkZHJlc3NlcyBpbiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0cy4gSWYgKGMxKSBhbmQg KGMxMSkgd2hldGhlciB1c2luZyBhbGlhcy1uYW1lIG9yIG5vdCBkbyBhIG1pdGlnYXRpb24gcmVx dWVzdCBhbmQgdGhpcyBjcmVhdGUgYSBtaXRpZ2F0aW9uIGNvbmZsaWN0LCB0aGVuIChzMSkgbmVl ZHMgdG8gc29ydCBpdCBvdXQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ib3dldmVyIGFsaWFzZXMgYXJlIHNldCB1cCBieSB0 aGUgZGF0YSBjaGFubmVsIGFuZCBwb3RlbnRpYWxseSB1c2VkIGJ5IHRoZSBzaWduYWwgY2hhbm5l bCBhdCBhIGxhdGVyIHRpbWUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbywgaWYgKGMxKSBhbmQgKGMxMSkgaGF2ZSBkaWZm ZXJlbnQgY2xpZW50IGlkZW50aXRpZXMsIHRoZW4gaW4gbXkgdGhpbmtpbmcgKHBlcmhhcHMgbmFp dmVseSkgdGhhdCBhIHNldHVwIG9mIOKAnGFsaWFzLTHigJ0gYnkgKGMxKSBmb2xsb3dlZCBsYXRl ciBieQ0KIChjMTEpIGFsc28gZGVmaW5pbmcgdGhlIGlkZW50aWNhbCBhbGlhcy1uYW1lIOKAnGFs aWFzLTHigJ0gdGhlbiB0aGUgYWxpYXMtbmFtZXMgYXJlIHRyZWF0ZWQgZGlmZmVyZW50bHkgYnkg KHMxKSBhcyBpdCBjYW4gc2VwYXJhdGVseSBhc3NvY2lhdGUg4oCcYWxpYXMtMeKAnSB3aXRoIHRo ZSBjb3JyZWN0IChjMSkgb3IgKGMxMSkuJm5ic3A7IEFzIChjMW4pIGNvdWxkIGJlIGEgbGFyZ2Ug bnVtYmVyIHdoZW4gc2NhbGluZyBvdXQsIHRoZXJlIGlzIGFuIGluY3JlYXNlZCBjaGFuY2UNCiBv ZiAyIG9yIG1vcmUgb2YgdGhlIGNsaWVudHMgYXQgdGhlIChjMSkgbGV2ZWwgY2hvb3NpbmcgdGhl IHNhbWUgYWxpYXMtbmFtZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPltUUl0gSSBkb27igJl0IHRoaW5rIHRoZXJl IHdpbGwgYmUgYSBsYXJnZSBudW1iZXIgb2YgRE9UUyBjbGllbnRzIGluIGEgZG9tYWluLCB0eXBp Y2FsbHkgYSBERG9TIG1pdGlnYXRpb24gc3lzdGVtIG9yIEREb1MgZGV0ZWN0b3IgaW4gYSBkb21h aW4gd2lsbA0KIGFjdCBhcyBET1RTIGNsaWVudHMgKGFuZCBpbiBmdXR1cmUgY29udGVudCBzZXJ2 ZXJzIHdpdGggRERvUyBkZXRlY3Rpb24gY2FwYWJpbGl0eSBjYW4gYWxzbyBhY3QgYXMgRE9UUyBj bGllbnRzKS4gJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5XaHkgZG8geW91IHRoaW5rIHRoZXJlIHdpbGwg YmUgbGFyZ2UgbnVtYmVyIG9mIERPVFMgY2xpZW50cyBpbiBhIGRvbWFpbiA/PC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ W0pvbjFdICZuYnNwO09uZSBvZiBteSBjdXN0b21lcnMgaGFzIG92ZXIgMTAwIG9mIGhpcyBjdXN0 b21lcnMgdGhhdCBhcmUgc2VwYXJhdGVseSBwcm90ZWN0ZWQgYW5kIGVhY2ggb2YgdGhlc2UgY3Vz dG9tZXJzIHdvdWxkIGJlIGNvbnNpZGVyZWQgYSAoYzEpIGluc3RhbmNlLiZuYnNwOw0KIEV4cGFu ZCB0aGlzIG91dCB0byBhIGJyb2FkYmFuZCBuZXR3b3JrIG9mIGhvbWUgcm91dGVycyBhbmQgdGhl IG51bWJlcnMgZ2V0IHZlcnkgbGFyZ2UuJm5ic3A7IFNlZSAzLjEuOCBhbmQgMy4yLjIgaW4gZG90 cyB1c2UgY2FzZXMgc3BlYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5b V2hlbiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0cyBjb21lIGluIGZyb20gKGMxKSBhbmQgKGMxMSks IHVzaW5nIHRoZWlyIGFwcHJvcHJpYXRlIGFsaWFzLW5hbWUgYW5kIHRoZXJlIGlzIGEgY29uZmxp Y3Qgd2hlbiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0DQogaXMgZXhwYW5kZWQgb3V0IOKAkyB0aGlz IGhhcyB0byBiZSBzb3J0ZWQgb3V0IGJ5IChzMSkuJm5ic3A7IEhvd2V2ZXIsIEkgYW0gYXNzdW1p bmcgdGhlcmUgaXMgbm90IGEgY29uZmxpY3QgaW4gdGhlIGV4cGFuZGVkIG1pdGlnYXRpb24gcmVx dWVzdF08L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPihzMSkgY2FuIGhhbmRsZSB0aGlzIGJ5IHRoZSBhc3NvY2lhdGlvbiBvZiB0 aGUgYWxpYXMtbmFtZXMgd2l0aCB0aGUgYXBwcm9wcmlhdGUgKGMxbikgaWRlbnRpdHkuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5PciBhcmUgeW91IHNheWluZyB0aGF0IChzMSkgaGFzIHRvIHJlamVjdCBhbGwgZHVwbGljYXRl IGFsaWFzLW5hbWVzIOKAkyBldmVuIHRob3VnaCB0aGV5IGFyZSBjb21pbmcgZnJvbSBkaWZmZXJl bnQgKGMxbikgZW50aXRpZXM/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPi0gdGhpcyBkb2VzIG5vdCBzY2FsZSBmb3IgbWU8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LSAoYzExKSDi gJMgZ29lcyBIdWg/IT8g4oCTIEkgaGF2ZSBub3QgcHJldmlvdXNseSBkZWZpbmVkIHRoaXMuIFdo YXQgaXMgYnJva2VuIGhlcmU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPj88L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPltUUl0gYzExIGhhcyB0byByZS10cnkgd2l0aCBhIGRp ZmZlcmVudCBhbGlhcyBuYW1lLCBSRVNUQ09ORiAoYW5kIE5FVENPTkYpIGRlYWxzIHdpdGggdGhp cyBwcm9ibGVtIGJ5IHJldHVybmluZyDigJxkYXRhLWV4aXN0c+KAnSBlcnJvciByZXNwb25zZSAo NDA5DQogcmVzcG9uc2UgY29kZSkuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXNzdW1pbmcgbXkgdW5kZXJzdGFuZGlu ZyBpcyBjb3JyZWN0IHRoYXQgdGhlIChzMSkmbmJzcDsgY2FuIGRpZmZlcmVudGlhdGUgYmV0d2Vl biBhbGlhcy1uYW1lcyB1c2VkIGJ5IGRpZmZlcmVudCAoYzFuKSBjbGllbnRzLCB3aGVuIChjMikg cGFzc2VzIHRoZSDigJxhbGlhcy0x4oCdDQogbmFtZSB1cHN0cmVhbSB3aXRob3V0IGFueSDigJxl eHRyYSAoYzFuIGluZm8p4oCdIGluZm9ybWF0aW9uIHRvIChzMiksIChzMikgd2lsbCByZWplY3Qg dGhlIGR1cGxpY2F0ZSAoKGMyKSBoYXMgcGFzc2VkIG9uIHRoZSBkYXRhIGNoYW5uZWwgcmVxdWVz dCBmcm9tIChjMSkgYW5kIChjMTEpKSB3aGljaCAoYzIpIHRoZW4gc2VlcyBhbmQgdGhlbiBoYXMg dG8gdGVsbCAoYzExKSDigJhZb3VyIHJlcXVlc3QgdG8gZGVmaW5lIOKAnGFsaWFzLTHigJ0gZmFp bGVkIGFzIGl0DQogaXMgYWxyZWFkeSBkZWZpbmVk4oCZLiAmbmJzcDtTbyBhZ2FpbiwgKGMxMSkg 4oCTIGdvZXMgSHVoPyE/IOKAkyBJIGhhdmUgbm90IHByZXZpb3VzbHkgZGVmaW5lZCB0aGlzLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SeKAmW0gbWlzc2luZyB0aGUgcG9pbnQgYXMgdG8gd2h5IHlvdSBhcmUgY29uY2VybmVk IGFib3V0IGFkZGluZyBpbiB0aGlzIGV4dHJhIGluZm9ybWF0aW9uIGJldHdlZW4gKGMyKSBhbmQg KHMyKSDigJMgd2UgaGF2ZSBwbGVudHkgb2Ygc3BhY2UgaW4gdGhlIFVEUA0KIHBhY2tldCDigJMg Q0JPUiBtYXBwaW5nIGhhcyBkb25lIGEgZ29vZCBkYXRhIHJlZHVjdGlvbiBqb2IuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij5bVFJdIFNwYWNlIGlzIG5vdCBhIHByb2JsZW0gZm9yIGFkZGluZyB0aGUgZXh0cmEgaW5m b3JtYXRpb24sIG15IGNvbmNlcm4gaXMgdGhlIG5lZWQgdG8gY29udmV5IHRoZSBleHRyYSBpbmZv cm1hdGlvbiBhbmQgRE9UUyBnYXRld2F5IG5vdCBhc3Npc3RpbmcNCiB0byByZXNvbHZlIHRoZSBz YW1lIGFsaWFzLW5hbWUgZnJvbSBkaWZmZXJlbnQgRE9UUyBjbGllbnRzLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltK b24xXSBJIHRoaW5rIHdlIG5lZWQgdGhpcyAob3B0aW9uYWwpIGV4dHJhIGluZm9ybWF0aW9uIHRo YXQgYW55IERPVFMgR1cgc2VydmVyIHNpZGUgY2FuIHNlbmQgdXBzdHJlYW0uJm5ic3A7IEFsbG93 aW5nIChjMykgdG8gZG8gdGhpcywgYnV0IG5vdCAoYzIpDQogbWFrZXMgbm8gc2Vuc2UgdG8gbWUu Jm5ic3A7IFRvIG1lLCBpdCBpcyBhIHJlcXVpcmVtZW50IHRoYXQgRE9UUyBHVyByZXNvbHZlcyBj b25mbGljdHMsIGRvZXMgZGF0YSByZWR1Y3Rpb24gZXRjLiB3aGVuZXZlciBpdCBjYW4gdG8gcmVk dWNlIHVwc3RyZWFtIHRyYWZmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltKb24xXSBJIHN0aWxsIGJlbGlldmUg dGhhdCAoczMpIGhhcyB0byBtYWludGFpbiBzZXBhcmF0aW9uIG9mIChjMSkgYW5kIChjMTEpIGlu Zm9ybWF0aW9uIChhbGlhcy1uYW1lcywgQUNMcyBhbmQgbWl0aWdhdGlvbiByZXF1ZXN0cykuJm5i c3A7IFNvLCB3aGVuDQogKGMxMSkgYXNrZXMgZm9yIGhpcyBtaXRpZ2F0aW9uIHN0YXR1cywgaGUg Z2V0cyBvbmx5IGRhdGEgcmVsZXZhbnQgdG8gaGltLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPi1UaXJ1PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Kb248L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IERvdHMgW21h aWx0bzoNCjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNl c0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZg0KPC9iPktvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHk8YnI+DQo8Yj5TZW50OjwvYj4gMTAgT2N0b2JlciAyMDE3IDE2OjU5PGJyPg0KPGI+VG86 PC9iPiBKb24gU2hhbGxvdzsga2FuYW1lIG5pc2hpenVrYTsgPGEgaHJlZj0ibWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwv YT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsgUm9s YW5kIERvYmJpbnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlz IENoYWxsZW5nZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5IaSBKb24sPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij5UaGUgcm9sZSBvZiBzMSBpcyBtdWNoIG1vcmUgdGhhbiBqdXN0IGZvcndhcmRpbmcg dGhlIERPVFMgY2xpZW50IG1lc3NhZ2VzLCBwbGVhc2Ugc2VlIChTSUctMDA5IGluIHRoZSByZXF1 aXJlbWVudHMgZHJhZnRzKSwgaWYgYSBET1RTIGNsaWVudCBoYXMNCiB1c2VkIHRoZSBzYW1lIGFs aWFzIG5hbWUgcHJldmlvdXNseSBjb252ZXllZCBieSBhbm90aGVyIGNsaWVudCB0aGVuIHMxIG11 c3QgcmVqZWN0IHRoZSByZXF1ZXN0LiBJZiBjb25mbGljdGluZyByZXF1ZXN0cyBhcmUgcmVzb2x2 ZWQgYnkgczEgdGhlbiBhbnkgcmVzcG9uc2UgbWVzc2FnZSBzZW50IGJ5IHMzIHdpbGwgYmUgZm9y d2FyZGVkIGJ5IHMxIHRvIHRoZSByaWdodCBET1RTIGNsaWVudC48L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPi1UaXJ1 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBKb24gU2hhbGxvdyBbPGEgaHJlZj0ibWFpbHRvOnN1 cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20iPm1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDEwLCAyMDE3IDg6NDcg UE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0OzxhIGhyZWY9 Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj5UaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDs7IGthbmFtZSBuaXNoaXp1a2EgJmx0OzxhIGhy ZWY9Im1haWx0bzprYW5hbWVAbnR0djYuanAiPmthbmFtZUBudHR2Ni5qcDwvYT4mZ3Q7Ow0KPGEg aHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+DQpkb3Rz QGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmlu c0BhcmJvci5uZXQiPnJkb2JiaW5zQGFyYm9yLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJFOiBbRG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SGkgVGlydSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZW4gdGhhdCBicmVha3MgYSBzaWduYWwgR0VU IGZvciBtaXRpZ2F0aW9uIHN0YXR1cyBmcm9tIChjMSkgKG1pdGlnYXRpb24gcmVxdWVzdCB1c2Vz IGFsaWFzLW5hbWUpIOKAkyB3aGF0IGdldHMgc2VudCBiYWNrIGluIHRoZSBhbGlhcy1uYW1lIGZp ZWxkDQogd2hlbiB0aGUgcmVzcG9uc2UgdGhhdCBpcyBzZW50IGJ5IChzMykgd2hlbiBpdCBnZXRz IHRvIChjMSk/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JIHRob3VnaHQgd2UgaGFkIGFncmVlZCB0byBsZWF2ZSB0aGUgYWxp YXMgbmFtZSDigJMgYXMgaXMg4oCTIChub3Qgc3Vic3RpdHV0ZWQpIGluIHdoYXQgaXMgc2VudCBi YWNrIHRvIChjMSkgZnJvbSAoczEpLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+KGMxKSBpcyBub3QgcGFydGljdWxhcmx5IGlu dGVyZXN0ZWQgaW4gaG93IChjMTEpIGlzIGdldHRpbmcgbWl0aWdhdGVkIGFuZCBwcm9iYWJseSBk b2VzIG5vdCB3YW50IChjMTEpIHN0YXRzIGFkZGVkIGludG8gaGlzIOKAkyAoczMpIG5lZWQgdG8g a25vdyBob3cNCiB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gKGMxKSBhbmQgKGMxMSkg4oCTIHdo aWNoIGlzIGVhc2lseSBkb25lIGlmIChjMSkgKG9yIChjMTEpIGluZm9ybWF0aW9uIGlzIHBhc3Nl ZCB1cCB0byAoczMpLCBzdGFydGluZyB3aXRoIChzMSkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIHdob2xlIHRoaW5n IG5lZWRzIHRvIGJlIHNjYWxhYmxlLCBhbmQgSSBhbSBzdHJ1Z2dsaW5nIHdpdGggaG93IHRvIGFj dHVhbGx5IGltcGxlbWVudCB5b3VyIHByb3Bvc2FsLiZuYnNwOyBBbGxvd2luZyBlYWNoIERPVFMg R1cgdG8gbGVhcm4gYW5kIHBhc3MNCiBvbiBzb21ldGhpbmcgZXh0cmEgdGhhdCBkaWZmZXJlbnRp YXRlcyB0aGUgRE9UUyBHVyBpbW1lZGlhdGUgY2xpZW50cyBtYWtlcyB0aGUgaW1wbGVtZW50YXRp b24gcmVsYXRpdmVseSBlYXN5LiZuYnNwOyBUaGVyZSBpcyBubyBuZWVkIGZvciBhIERPVFMgR1cg dG8gYWRkIGluIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaWYgZXh0cmEgaW5mb3JtYXRpb24gaXMg YWxyZWFkeSBlbWJlZGRlZCDigJMgdW5sZXNzIGhlIHNlZXMgYSBuYW1lIGNsYXNoIGZyb20gMiBv cg0KIG1vcmUgb2YgaGlzIHVuaXF1ZWx5IGlkZW50aWZpZWQgRE9UUyBjbGllbnRzIOKAkyB3aGlj aCB3aWxsIGJlIGRpZmZlcmVudCBlbnRpdGllcyBhbnl3YXkuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5Kb248L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ IERvdHMgW21haWx0bzoNCjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRv dHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZg0KPC9iPktvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHk8YnI+DQo8Yj5TZW50OjwvYj4gMTAgT2N0b2JlciAyMDE3IDE1OjUyPGJy Pg0KPGI+VG86PC9iPiBKb24gU2hhbGxvdzsga2FuYW1lIG5pc2hpenVrYTsgPGEgaHJlZj0ibWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3Jn PC9hPjsgUm9sYW5kIERvYmJpbnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RT IEdhdGV3YXlzIENoYWxsZW5nZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5UaGUg Y29uZmxpY3RpbmcgYWxpYXMtbmFtZXMgZnJvbSBET1RTIGNsaWVudCAoYzEpIGFuZCBhbm90aGVy IGNsaWVudCAobGV04oCZIGNhbGwgKGMxMSkpIGJlaGluZCAoczEpIHNob3VsZCBiZSByZXNvbHZl ZCBieSBzMSBpdHNlbGYsIGl0IGlzIGFsc28NCiB0aGUgcmVzcG9uc2liaWxpdHkgb2YgKHMxKSB0 byByZXNvbHZlIGNvbmZsaWN0aW5nIG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSAoYzEpIGFuZCAo YzExKSwNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5hZ2dyZWdhdGUgdGhl IG1pdGlnYXRpb24gcmVxdWVzdHMgZnJvbSB0aGUgRE9UUyBjbGllbnRzIChjMSBhbmQgYzExKSBh bmQgc2VuZCB0aGUgdXBkYXRlZCBtaXRpZ2F0aW9uIHJlcXVlc3QgKGMyKS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LVRpcnU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEpv biBTaGFsbG93IFs8YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+bWFp bHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgODoxMSBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tv bmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+Jmd0 Ozsga2FuYW1lIG5pc2hpenVrYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthbmFtZUBudHR2Ni5qcCI+ a2FuYW1lQG50dHY2LmpwPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9 Im1haWx0bzpkb3RzQGlldGYub3JnIj4NCmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmlu cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+cmRvYmJpbnNAYXJib3Iu bmV0PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlz IENoYWxsZW5nZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBUaXJ1LDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SSBhZ3JlZSBpbiBwYXJ0LCBidXQgd2UgbmVlZCB0byBsb29rIGF0IHRoZSBlbmQgKGMxKSB0byBl bmQgKHMzKSBwb3RlbnRpYWwgaXNzdWVzLiZuYnNwOyBXaGF0IHlvdSBhcmUgcHJvcG9zaW5nIHdv cmtzIGZpbmUgZm9yIChzMikgdG8gKHMzKS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPihjMSkgcmVxdWVzdHMgbWl0aWdhdGlv biB3aXRoIGFuIGFsaWFzLW5hbWUg4oCcYWxpYXMtMeKAnS4mbmJzcDsgSWYgKHMxKSBkb2VzIG5v dCBwYXNzIGFueXRoaW5nIGV4dHJhIHRvIChjMikgZm9yIG9ud2FyZCB0cmFuc21pc3Npb24sIChz Mikgc2VlcyBhIHNpbmdsZQ0KIGNsaWVudCAoYzIpIHJlcXVlc3RpbmcgbWl0aWdhdGlvbiB3aXRo IGFsaWFzLW5hbWUg4oCcYWxpYXMtMeKAnS4mbmJzcDsgRmluZSwgdGhhdCB3b3Jrcy48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgdGhl cmUgd2FzIGFub3RoZXIgRE9UUyBjbGllbnQgaW4gdGhlIHNhbWUgbG9jYXRpb24gYXMgKGMxKShp LmUuIGMxZGlmZiksIGJvdGggdXNpbmcgKHMxKSB3aG8gYWxzbyBkZWNpZGVkIHRvIHVzZSBhbGlh cy1uYW1lIOKAnGFsaWFzLTHigJ0gd2hvIHRoZW4NCiByZXF1ZXN0cyBtaXRpZ2F0aW9uLCAoczIp IGhhcyBubyBpZGVhIHRoYXQgdGhlcmUgYXJlIGRpZmZlcmVudCDigJxhbGlhcy0x4oCdIGRlZmlu aXRpb25zIGlmIChjMikgZG9lcyBub3Qgc2VuZCBhbHNvIGFuIGV4dHJhIGRpZmZlcmVudGlhdG9y Lg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5TbywgYW55IERPVFMgR1cgaW4gdGhlIGNoYWluIHNob3VsZCBiZSBwYXNzaW5n IG9uIGEg4oCcdW5pcXVlLWV4dHJh4oCdIHBpZWNlIG9mIGluZm9ybWF0aW9uLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVn YXJkczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Sm9uDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+IERvdHMgW21haWx0bzoNCjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNA aWV0Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZg0KPC9i PktvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk8YnI+DQo8Yj5TZW50OjwvYj4gMTAgT2N0b2JlciAy MDE3IDE1OjE1PGJyPg0KPGI+VG86PC9iPiBKb24gU2hhbGxvdzsga2FuYW1lIG5pc2hpenVrYTsg PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5k b3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij5BZ3JlZSB3aXRoIHlvdXIgcmVzcG9uc2UsIGNvbnNpZGVyIGEgZGVwbG95bWVudCB3 aGljaCBoYXMgdGhlIGZvbGxvd2luZyBET1RTIGFnZW50cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkRPVFMgY2xp ZW50cyAoYzEpDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjp3aW5kb3d0ZXh0Ij7Dnzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPi0tLS0tLS0tLS0tLS0t LS08L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjp3aW5kb3d0ZXh0Ij7DoDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPg0KIChzMSkgY2xpZW50LXNpZGUgRE9U UyBnYXRld2F5IChjMikgPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+w588L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4tLS0tLS0tLS0tLS08 L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OldpbmdkaW5ncztjb2xvcjp3aW5kb3d0ZXh0Ij7DoDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+KHMyKSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkgKGMz KQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6d2luZG93dGV4dCI+w588L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4tLS0tLS0tLS0tPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGlu Z3M7Y29sb3I6d2luZG93dGV4dCI+w6A8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij4NCiAoczMpIERPVFMgc2VydmVyPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5NeSBw b2ludCBpcywgKGMyKSBuZWVkIG5vdCBjb252ZXkgdGhlIOKAnGMxIGlkZW50aXR54oCdIHRvIChz MikgYnV0IChzMikgbmVlZHMgdG8gY29udmV5IHRoZSDigJxjMiBpZGVudGl0eeKAnSB0byAoYzMp IGFuZCAoYzMpIGluLXR1cm4gcHJvcGFnYXRlcyB0aGUNCiDigJxjMiBpZGVudGl0eeKAnSB0byAo czMpLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6d2luZG93dGV4dCI+LVRpcnU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEpvbiBTaGFs bG93IFs8YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSI+bWFpbHRvOnN1 cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IE9jdG9iZXIgMTAsIDIwMTcgNjoxNSBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxl c3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1j QWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+Jmd0Ozsga2Fu YW1lIG5pc2hpenVrYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthbmFtZUBudHR2Ni5qcCI+a2FuYW1l QG50dHY2LmpwPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0 bzpkb3RzQGlldGYub3JnIj4NCmRvdHNAaWV0Zi5vcmc8L2E+OyBSb2xhbmQgRG9iYmlucyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+cmRvYmJpbnNAYXJib3IubmV0PC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxs ZW5nZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBUaXJ1LDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWdyZWVk IHRoYXQgb25seSBhIERPVFMgR1cgc2VydmVyIGZhY2luZyBuZWVkcyB0byBzZW5kIGluZm9ybWF0 aW9uIHRvIHRoZSB1cHN0cmVhbSBET1RTIFNlcnZlciDigJMgd2hpY2ggY291bGQgYWxzbyBiZSBh IERPVFMgR1cuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmIzQzOy0tLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyB8IEQgfCZuYnNwOyZuYnNwOyZu YnNwOyB8PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgTyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJiM0MzstLS0tJiM0Mzs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgYzEgfC0tLS0tLS0tLS18IHMxIHwg VCB8IGMyIHwtLS0tLS0tLS18IHMyIHw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLSYjNDM7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJz cDsmbmJzcDsgfCBTIHwmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0mIzQzOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyB8IEcg fCZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLWFyY2hpdGVjdHVyZS0wNCNzZWN0aW9u LTIuMi4zIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLWFyY2hp dGVjdHVyZS0wNCNzZWN0aW9uLTIuMi4zPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgdGhlIERPVFMgR1cg Y2xpZW50IGZhY2luZyAoczEpIGlzIHRoZSBvbmUgd2l0aCBrbm93bGVkZ2Ugb2YgdGhlIGluZGl2 aWR1YWwgY2xpZW50cyB0aGF0IGFyZSBjdXJyZW50bHkgdXNpbmcgJm5ic3A7dGhlIERPVFMgc2Vy dmVyIHJ1bm5pbmcgb24NCiB0aGUgRE9UUyBHVy4mbmJzcDsgVGhpcyBpbmZvcm1hdGlvbiBoYXMg dG8gc29tZWhvdyBiZSBwYXNzZWQgb3ZlciB0byB0aGUgRE9UUyBHVyBzZXJ2ZXIgZmFjaW5nIChj MiksIGJ1dCBzZXBhcmF0ZSBET1RTIHN0YWNrcyBhcmUgYmVpbmcgcnVuIGZvciAoczEpIGFuZCAo YzIpIGFzIHBlciBhcmNoaXRlY3R1cmUgc3BlYyAyLjIuMy4mbmJzcDsgSSB3YXMgcmVmZXJyaW5n IHRvIHdoYXQgKHMxKSBtYXkgbmVlZCB0byBwYXNzIG9uIHRvIChjMikgaW4gbXkgZW1haWwgcmVz cG9uc2UNCiB0byBLYW5hbWUsIG5vdCB3aGF0IGlzIHNlbnQgYnkgKGMxKS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkpvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij4gRG90cyBbbWFpbHRvOg0KPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRm Lm9yZyI+ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mDQo8L2I+S29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeTxicj4NCjxiPlNlbnQ6PC9iPiAxMCBPY3RvYmVyIDIwMTcg MTM6MTY8YnI+DQo8Yj5Ubzo8L2I+IEpvbiBTaGFsbG93OyAna2FuYW1lIG5pc2hpenVrYSc7IDxh IGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4NCm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90 c0BpZXRmLm9yZzwvYT47IFJvbGFuZCBEb2JiaW5zPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb RG90c10gRE9UUyBHYXRld2F5cyBDaGFsbGVuZ2VzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+SSB0aG91Z2h0IHdlIGFncmVlZCB0aGF0IGJhc2VkIG9uIHRoZSBjdXJyZW50IERPVFMg cmVxdWlyZW1lbnRzIG9ubHkgdGhlIHNlcnZlci1zaWRlIERPVFMgR1cgbmVlZHMgdG8gY29udmV5 IHRoZSBET1RTIGNsaWVudCAob3IgY2xpZW50LXNpZGUgRE9UUw0KIFdHKSBpZGVudGl0eSB0byB0 aGUgRE9UUyBzZXJ2ZXIuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+LVRpcnU8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+IEpvbiBTaGFsbG93IFs8YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNv bSI+bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgMjo1MyBQTTxicj4NCjxiPlRvOjwvYj4gJ2th bmFtZSBuaXNoaXp1a2EnICZsdDs8YSBocmVmPSJtYWlsdG86a2FuYW1lQG50dHY2LmpwIj5rYW5h bWVAbnR0djYuanA8L2E+Jmd0OzsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dh clJlZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsg PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPg0KZG90c0BpZXRmLm9yZzwvYT47IFJvbGFu ZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmlu c0BhcmJvci5uZXQ8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNdIERPVFMg R2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEthbmFt ZSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkkgZG8gbm90IHRoaW5rIHRoYXQgaW5mb3JtYXRpb24gbmVjZXNzYXJpbHkgbmVl ZHMgdG8gYmUgdGhlIG9yaWdpbmFsIGNsaWVudCBpZGVudGl0eS4mbmJzcDsgVGhlIEdXIENsaWVu dCBzaWRlIHdpbGwgaGF2ZSBpdHMgb3duIGlkZW50aXR5IHdoaWNoIHRoZSBET1RTDQogU2VydmVy IGNhbiB1c2UgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIERPVFMgKEdXKSBDbGllbnRzLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+U28sIHllcywgYSBoYXNoZWQgc2V0IG9mIG5hbWVzIGNhbiBiZSB1c2VkIOKAkyBpdCBpcyB1 cCB0byB0aGUgRE9UUyBHVyBDbGllbnQgc2lkZSB0byBtYWtlIHN1cmUgdGhhdCB0aGVyZSBhcmUg bm8gaGFzaCBjb2xsaXNpb25zLiZuYnNwOyBPciBpdCBjb3VsZCBiZQ0KIGEgc2ltcGxlIGxpc3Qg c3VjaCBhcyBDMSwgQzIg4oCmQ24uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Kb248L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IERvdHMgW21haWx0bzoN CjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRm Lm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZg0KPC9iPmthbmFtZSBuaXNoaXp1a2E8YnI+DQo8Yj5T ZW50OjwvYj4gMTAgT2N0b2JlciAyMDE3IDA0OjE5PGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGly dW1hbGVzd2FyIFJlZGR5OyBKb24gU2hhbGxvdzsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxh IGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERv YmJpbnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxs ZW5nZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+SGksPGJyPg0KPGJyPg0KJmd0 OyBJIGFncmVlIHRoZSBiZWxvdyBwcm9ibGVtcyBhcmUgYXBwbGljYWJsZSBmb3Igc2VydmVyLXNp ZGUgRE9UUyBnYXRld2F5LCBpdCBtdXN0IGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCd IHRvIHRoZSBET1RTIHNlcnZlci4NCjxicj4NCkkgYWdyZWUgd2l0aCB0aGlzIHNlcnZlci1zaWRl IERPVFMgZ2F0ZXdheSBjYXNlLjxicj4NCkF0IHRoZSBzYW1lIHRpbWUsIEkgYWdyZWUgd2l0aCBi ZWxvdzo8YnI+DQomZ3Q7IEkgYWdyZWUgdGhhdCBpcyBub3QgYSBnb29kIHRoaW5nIHRvIOKAnGxl YWvigJ0gb3V0IGludGVybmFsIGluZm9ybWF0aW9uIHdoZW4gcGFzc2luZyB0aHJvdWdoIGEgRE9U UyBHVywNCjxicj4NCjxicj4NClRoZW4sIHNob3VsZCBET1RTIEdXIHNlbmQg4oCcY2xpZW50IGlk ZW50aXR54oCdIChpLmUuIGNlcnRpZmljYXRlcyBvZiBET1RTIGNsaWVudHMpIGl0c2VsZiBvciBo YXNoZWQo4oCcY2xpZW50IGlkZW50aXR54oCdKSB0byBET1RTIHNlcnZlcj88YnI+DQpJZiBsYXRl ciwgaG93IGNhbiBET1RTIHNlcnZlciByZWFjdCB0byB0aGUgYW1iaWd1b3VzIGluZm9ybWF0aW9u IG9mIHRoZSBoYXNoZWQo4oCcY2xpZW50IGlkZW50aXR54oCdKS48YnI+DQo8YnI+DQpyZWdhcmRz LDxicj4NCkthbmFtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gMjAxNy8xMC8wOSAyMjozNCwgS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgSm9u LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGFncmVlIHRoZSBiZWxvdyBw cm9ibGVtcyBhcmUgYXBwbGljYWJsZSBmb3Igc2VydmVyLXNpZGUgRE9UUyBnYXRld2F5LCBpdCBt dXN0IGNvbnZleSB0aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBET1RTIHNlcnZlci4g QnV0IGZvciB0aGUgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5LA0KIGl0IHNob3VsZCByZXNvbHZl IGNvbmZsaWN0aW5nIHJ1bGVzIGIvdyBET1RTIGNsaWVudHMgKGUuZy4gb25lIGNsaWVudCBpbnN0 YWxsaW5nIGJsYWNrLWxpc3QgQUNMIGZvciBhbiBJUCBhZGRyZXNzIGJ1dCB0aGUgb3RoZXIgY2xp ZW50IGluc3RhbGxzIHdoaXRlLWxpc3QgQUNMIGZvciB0aGUgc2FtZSBJUCBhZGRyZXNzLCBzYW1l IGFsaWFzLW5hbWVzIGZvciBkaWZmZXJlbnQgbWl0aWdhdGlvbiBzY29wZXMpLiBJIGRvbuKAmXQg c2VlIHRoZSBuZWVkDQogZm9yIGEgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNvbnZleSB0 aGUg4oCcY2xpZW50IGlkZW50aXR54oCdIHRvIHRoZSBzZXJ2ZXItc2lkZSBET1RTIGdhdGV3YXkg b3IgRE9UUyBzZXJ2ZXIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi1UaXJ1 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb24gU2hhbGxvdyBbPGEgaHJlZj0ibWFp bHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20iPm1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxs b3cuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgT2N0b2JlciA3LCAyMDE3 IDI6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPGEgaHJl Zj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPg0KJmx0O1RpcnVt YWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7PC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTwvYT47IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjsg Um9sYW5kIERvYmJpbnMNCjxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5uZXQiPiZsdDty ZG9iYmluc0BhcmJvci5uZXQmZ3Q7PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RvdHNd IERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhp IFRpcnUsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGlzIGRpc2N1c3Npb24gZ29lcyBiZXlvbmQganVzdCB0aGUgbWl0aWdh dGlvbiByZXF1ZXN0LiZuYnNwOyBXZSBuZWVkIHRvIGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3aXRo IGJvdGggYWxpYXMtbmFtZSBhbmQgYWNsLW5hbWUgKGRhdGEgY2hhbm5lbCk8L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBz aW1wbGUgY2FzZSBvZiBhIG1pdGlnYXRpb24gcmVxdWVzdCB3aXRoIG5vIGFsaWFzLW5hbWUgZG9l cyBub3QgcmVxdWlyZSBhbnkga25vd2xlZGdlIG9mIHRoZSBvcmlnaW5hbCBjbGllbnQuJm5ic3A7 DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkhvd2V2ZXIsIGlmIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgdXNlcyBhbGlhcy1u YW1lLCB0aGVuIHRoZXJlIGFyZSAzIHdheXMgb2YgaGFuZGxpbmcgdGhpczwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+YSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5UaGUgRE9UUyBHVyByZXBsYWNlcyB0aGUgYWxpYXMtbmFtZSB3aXRoIGl0cyBhY3R1YWwg ZGVmaW5pdGlvbiAodGFyZ2V0LWlwcyBldGMuIG1lcmdlZCBhcyBhcHByb3ByaWF0ZSksIHNvIGFs aWFzLW5hbWUgaXMgbm90IGZvcndhcmRlZCBvbiB0byBTZXJ2ZXIg4oCTIGp1c3QgdGhlDQogZXhw YW5kZWQgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGZvcndhcmRlZDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Yik8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgRE9U UyBHVyB1cGRhdGVzIHRoZSBhbGlhcy1uYW1lIHdpdGggYSB1bmlxdWUgYWxpYXMtbmFtZSB0aGF0 IGlzIGZvcndhcmRlZCAoYW5kIGhhcyB0byBkbyB0aGUgc2FtZSB0aGluZyB3aGVuIHRoZSBhbGlh cy1uYW1lIGlzIGNvbmZpZ3VyZWQgb24gdGhlIGRhdGEgY2hhbm5lbCkNCiDigJMgdG8gaGFuZGxl IDIgb3IgbW9yZSBjbGllbnRzIGRlZmluaW5nIHRoZSBzYW1lIGFsaWFzLW5hbWUgd2hpY2ggaGF2 ZSBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5jKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBET1RTIEdX IHJlY29nbmlzZXMgdGhhdCBhbGlhcy1uYW1lIGlzIG5vdCB1bmlxdWUgYW5kIGFkZHMgaW4g4oCd YWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSAoSSB0aGluayBJIHByZWZlciB0aGlzIOKAnC1pbmZv 4oCdIG5hbWUgdG8gY2xpZW50LWlkIG9yIG9yaWdpbmFsLWNsaWVudC1pZA0KIGFzIOKAnC1pZOKA nSBpcyB0b28gY2xvc2VseSAmbmJzcDthc3NvY2lhdGVkIHdpdGggQ2xpZW50IElkZW50aXR5IGRl cml2ZWQgZnJvbSB0aGUgRE9UUyBHVyBDbGllbnQgY2VydGlmaWNhdGUpPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIGhhdmUgYWdyZWVk IHRoYXQgd2hlbiBhIGNsaWVudCByZXF1ZXN0cyBtaXRpZ2F0aW9uIHN0YXR1cywgdGhlIOKAnGFs aWFzLW5hbWXigJ0gc2hvdWxkIGJlIHJldHVybmVkIGFzIOKAnGFsaWFzLW5hbWXigJ0gYW5kIG5v dCB0aGUgc3Vic3RpdHV0ZWQgYWxpYXMtbmFtZQ0KIGNvbmZpZ3VyYXRpb24gKHRoaXMgZG9lcyBu ZWVkIHRvIGJlIHN0YXRlZCBpbiB0aGUgc3BlYyBmb3IgY2xhcml0eSkuJm5ic3A7IFRoaXMgbWFr ZXMgKGEpIGRpZmZpY3VsdCB0byBiZSBoYW5kbGVkIGJ5IERPVFMgR1cgd2hpY2ggdGhlbiByYWlz ZXMgdGhlIHF1ZXN0aW9uIOKAkyBkbyB3ZSByZWFsbHkgbmVlZCBhbGlhcy1uYW1lPzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhlIGRlZmluaXRpb24gYW5kIGFzc29jaWF0aW9uIG9mIEFDTHMvRmlsdGVycyBvZiB0aGUgZGF0 YSBjaGFubmVsIGlzIG1vcmUgZGlmZmljdWx0IOKAkyB0aGUgU2VydmVyIG11c3QgaW5zdGFsbCAv IGFwcGx5IHRoZSBhcHByb3ByaWF0ZSBBQ0xzIG9uIGENCiBwZXIgKE9yaWdpbmFsKSBDbGllbnQg YmFzaXMgd2hlbiBtaXRpZ2F0aW9uIGlzIGludm9rZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNsaWVudCAx4oCZcyBjb25jZXB0IG9m IGEgV2hpdGVsaXN0IElQIGNvdWxkIGJlIENsaWVudCAy4oCZcyBjb25jZXB0IG9mIGEgQmxhY2ts aXN0IElQLiZuYnNwOyBUaGUgU2VydmVyIG5lZWRzIHRvIGtub3cgd2hpY2ggY2xpZW50IGlzIHJl cXVlc3RpbmcgdGhlIG1pdGlnYXRpb24NCiBhbmQgaW5zdGFsbCB0aGUgY29ycmVjdCBBQ0xzIOKA kyBpZiB0aGVyZSB3YXMgbm8g4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSwgdGhlIFNlcnZl ciBvbmx5IGtub3dzIHRoYXQgaGUgaGFzIHRvIGluc3RhbGwgQUxMIG9mIHRoZSBBQ0xzIChpLmUu IGJvdGggdGhlIEJsYWNrIGFuZCBXaGl0ZSBsaXN0IG9mIHRoZSBzYW1lIElQIGFzIGRlZmluZWQg YnkgQ2xpZW50IDEgYW5kIENsaWVudCAyKSBhcyBkZWZpbmVkIGJ5IGhpcyBjbGllbnQgKERPVFMg R1cpDQogd2hlbiBoaXMgY2xpZW50IHJlcXVlc3RzIGEgbWl0aWdhdGlvbi4mbmJzcDsgSGVyZSwg SSB0aGluayB0aGF0IGlmIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgY2xpZW50IGZvciB0aGUgRE9U UyBHVywg4oCdYWRkaXRpb25hbC1jbGllbnQtaW5mb+KAnSBpcyByZXF1aXJlZC48L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJl Z2FyZHM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkpvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBEb3RzIFttYWlsdG86DQo8YSBocmVm PSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Lb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5PGJyPg0KPGI+ U2VudDo8L2I+IDA3IE9jdG9iZXIgMjAxNyAwNDoyODxicj4NCjxiPlRvOjwvYj4gSm9uIFNoYWxs b3c7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3Jn Ij5kb3RzQGlldGYub3JnPC9hPjsgUm9sYW5kIERvYmJpbnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtEb3RzXSBET1RTIEdhdGV3YXlzIENoYWxsZW5nZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SW4gY2Fz ZSBvZiBjbGllbnQtc2lkZSBET1RTIGdhdGV3YXksIHdoeSBkb2VzIHRoZSBET1RTIHNlcnZlciBu ZWVkIHRvIGtub3cgd2hpY2gg4oCcRE9UUyBjbGllbnTigJ0gaGFzIGNvbnZleWVkIHRoZSBtaXRp Z2F0aW9uIHJlcXVlc3QgPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Rm9yIGV4YW1wbGUsIHRoZSBET1RTIGNsaWVudCBjb3VsZCBiZSBhIEREb1MgZGV0ZWN0b3Ig b3IgYW4gQXBwbGljYXRpb24gc2VydmVyLCBhbmQgdGhlIGNsaWVudC1zaWRlIGdhdGV3YXkgd2ls bCBoYXZlIHRvIHJlc29sdmUgdGhlIGNvbmZsaWN0aW5nIG1pdGlnYXRpb24gcmVxdWVzdHMNCiBm cm9tIHRoZSBET1RTIGNsaWVudHMsIGFnZ3JlZ2F0ZSB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0cyBm cm9tIHRoZSBET1RTIGNsaWVudCBhbmQgc2VuZCB0aGUgdXBkYXRlZCBtaXRpZ2F0aW9uIHJlcXVl c3QgdG8gdGhlIERPVFMgc2VydmVyLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4tVGlydTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSm9uIFNoYWxsb3cgWzxhIGhy ZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tIj5tYWlsdG86c3VwanBzLWlldGZA anBzaGFsbG93LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDYs IDIwMTcgNzo0MiBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAm bHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRp cnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPg0KZG90c0BpZXRmLm9yZzwv YT47IFJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0 Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0Rv dHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkhpIFRpcnUsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Vbmxlc3MgSSBhbSBtaXNzaW5nIHNvbWV0aGluZywgaG93IGRvZXMg dGhlIENsaWVudCBzaWRlIG9mIERPVFMgR1cgY29udmV5IHRvIHRoZSB1cHN0cmVhbSBzZXJ2ZXIg YSB1bmlxdWUg4oCcY2xpZW50LWlk4oCdIHdoaWNoIGlzIGRpZmZlcmVudCB0byB0aGUgaW1wbGll ZA0KIGNsaWVudCBpZCBhcyBkZXJpdmVkIGZyb20gdGhlIFBLSSBjZXJ0aWZpY2F0ZSB0aGF0IHRo ZSBET1RTIEdX4oCZQ2xpZW50IHVzZXMvcHJlc2VudHMgd2hlbiBjb21tdW5pY2F0aW5nIHRvIHRo ZSBzZXJ2ZXI/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRvIG1lLCB0aGVyZSBuZWVkcyB0byBiZSBhbiBvcHRpb24gc3VjaCBhcyDigJxv cmlnaW5hbC1jbGllbnQtaWTigJ0gb3Ig4oCcY2xpZW50LWlk4oCdICh3aGljaCBpcyBjb25mdXNp bmcgd2hlbiBhbHNvIHJlZmVycmluZyB0byB0aGUgY2xpZW50IGlkZW50aXR5IGFzDQogZGVyaXZl ZCBmcm9tIHRoZSAoRE9UUyBHVykgQ2xpZW504oCZcyBQS0kgY2VydGlmaWNhdGUpIGFzIGEgcGFy dCBvZiB0aGUgcHJvdG9jb2wuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgdGhlIERPVFMgR1cgY2FuIGdl bmVyYXRlIGl0cyBvd24gdW5pcXVlIGNsaWVudC1pZCB0byBzdG9wIG11bHRpcGxlIGVudHJpZXMg YmVpbmcgbmVlZGVkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IGlzIG5vdCBhIGdvb2QgdGhpbmcgdG8g 4oCcbGVha+KAnSBvdXQgaW50ZXJuYWwgaW5mb3JtYXRpb24gd2hlbiBwYXNzaW5nIHRocm91Z2gg YSBET1RTIEdXLCBzbyBteSBSRVFVSVJFRCBkb2VzIG5vdCBtYWtlIHNlbnNlLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVn YXJkczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Sm9uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlBTIOKAkyBJIGFtIGhhdmluZyB0byBkZWFsIHdpdGggb3RoZXIgc3R1 ZmYgYXQgcHJlc2VudCDigJMgSSB3aWxsIGdldCBiYWNrIGxhdGVyIG9uIHRoZSBvdGhlciBpc3N1 ZXMgdW5kZXIgZGlzY3Vzc2lvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBLb25kYSwgVGlydW1hbGVzd2Fy IFJlZGR5IFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFA bWNhZmVlLmNvbSI+VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbTwvYT5dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gMDYgT2N0b2JlciAyMDE3IDE0OjU4PGJyPg0KPGI+VG86PC9iPiA8YSBo cmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTwvYT47IEpvbiBTaGFsbG93OyAnRG9iYmlucywgUm9sYW5kJzsNCjxhIGhy ZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSRTogW0RvdHNdIERPVFMgR2F0ZXdheXMgQ2hhbGxlbmdlczwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5JIGRvbuKAmXQgc2VlIGEgbmVlZCBmb3IgY2xpZW50LXNpZGUgRE9UUyBnYXRld2F5IHRvIGNv bnZleSB0aGUg4oCcRE9UUyBjbGllbnQgaWRlbnRpdHnigJ0gdG8gdGhlIERPVFMgc2VydmVyLiDi gJxET1RTIGNsaWVudCBpZGVudGl0eeKAnSBsb29rcyByZXF1aXJlZCBvbmx5IGZvciB0aGUgc2Vy dmVyLXNpZGUNCiBET1RTIGdhdGV3YXlzLiBJbiBjYXNlIG9mIHNlcnZlci1zaWRlIERPVFMgZ2F0 ZXdheSwgaXQgY2FuIGNvbnZleSB0aGUgY2xpZW50LWlkIGdlbmVyYXRlZCBmcm9tIHRoZSDigJxE T1RTIGNsaWVudCBpZGVudGl0eeKAnSB0byB0aGUgRE9UUyBzZXJ2ZXIuIFRoZSBET1RTIGdhdGV3 YXkgY2FuIGdlbmVyYXRlIGEgdW5pcXVlIGNsaWVudC1pZCBhbmQgZG9lcyBub3QgaGF2ZSB0byBz ZW5kIGFuIGFycmF5IG9mIGNsaWVudC1pZHMgdG8gdGhlIERPVFMgc2VydmVyDQogdG8gcmVzb2x2 ZSBjbGFzaGVzLiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LVRpcnU8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLUdCIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+RG90 cyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tR0IiPjxhIGhyZWY9Im1haWx0bzpEb3RzQGlldGYub3JnIj5Eb3RzQGlldGYub3JnPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLUdCIj5Eb3RzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPkRvdHNA aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LUdCIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90czwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB1788774A0B6F0CFFA3B688C9EA4A0DM5PR16MB1788namp_-- From nobody Thu Oct 12 21:14:01 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFBD13431E; Thu, 12 Oct 2017 21:13:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150786803986.23806.3611055464584048542@ietfa.amsl.com> Date: Thu, 12 Oct 2017 21:13:59 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-05.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 04:14:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-05.txt Pages : 58 Date : 2017-10-12 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-05 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 12 21:27:25 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE872132949 for ; Thu, 12 Oct 2017 21:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 nvMc6sB8Cstt for ; Thu, 12 Oct 2017 21:27:21 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 783151331D2 for ; Thu, 12 Oct 2017 21:27:21 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507868840; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=c g5OloP2dyAnA6ty3fc3UuKUSzFWPIzx/apfq1Si2A s=; b=BthBjXzGLcPW4qA0+Af3eAoUIkM458UL+4iBJDJ8Ovu2 XKTXim5FnMpl+LSVPhTpG07zAJHGK7l4IjkCGqcTA/5dwRPV+c FwXGG+xa9x8N6yCsI2emnyz/ayzyWhy5EjSJQSBfm1TvSC/33P VNyyAaTe+VezYX98KKxHL5P/oNQ= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 1829_0d33_e9629554_6af0_48ec_8c97_70d335919d22; Thu, 12 Oct 2017 23:27:20 -0500 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 12 Oct 2017 22:27:19 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 12 Oct 2017 22:27:18 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 12 Oct 2017 22:27:18 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 12 Oct 2017 22:27:18 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 13 Oct 2017 04:27:17 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.021; Fri, 13 Oct 2017 04:27:17 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-05.txt Thread-Index: AQHTQ9nGoyGIsCgrmEqo8xDCST0YK6LhLyjg Date: Fri, 13 Oct 2017 04:27:17 +0000 Message-ID: References: <150786803986.23806.3611055464584048542@ietfa.amsl.com> In-Reply-To: <150786803986.23806.3611055464584048542@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:Dxs81HamU9WtZNHF28kfi3pCQR3xMN7AsVeWl9BQ2LYUw98Ww4EG8FWcYYAb3WxXaX+OQid+FGO61/5AaVqIDC5PuYBujv7zmMe1DjF63tlLDpd0HciBsasAKBt593EvZfWTaltFmQkvGwV6AGUPtfuYI0X+L0usfONao4fj8iP5YzgGIwQ3NzowzugE4JkRR4lecowBzJHdfyXJpFURBMT7S26LeXyL+DrUQYxOhkZIbex8r+zFrtGZ4mnwJU9tyE/ZUBWNSJHqtkra6V+CLxuRSo8hfPw3VD14E/wvkQDJ5N1wnNa69QxuJEMdeZblaYPvAyDreiPZVk0JnC2vSw==; 5:lb38LaX8Te/eq8a6LhnQ56CpRHfxxBVC1eeJsh4ID9BwWkDnV9VKbpIIDcp3kYmkbwW9m+5GoV+ri6ieK9tEQw+8aU/rxkqrPlaXr/qhk5sq7TCaFMduSfvS6vzg3tO3xfQGzdrnEiuIwFHLoqNICx4BBINMeuPBtel+TsfERG8=; 24:DVSa0CuxOz5Zr0LV5C6Mcvt1UlLyV92KMnU8619yCLWVXLmmyQssYR5FbkBr83ZgJf3UqnNQeYkM4af6y8pP7KH9i5ZP6ohHttojdIZG620=; 7:G0xd1rrOV9Edk9VzAUj4J09LAKWZW6c7hEvRT8l0rVwq7ShwkGdh6rdFL5v6Q4IEJfkKedJ/V2t72AU0bfY9TynQicBA4F+7WK6sY3USVrr0+0HK89v6ECnBJCXWkdsXeMs9hjbgP4TdWZ/5WZyIhtWWMgAK+PRIfO/+s/Do89J7Ap+46T97DX2fj6OxznpKvpqIGE75D6SnsLHSC/dT0k0Ulj8QTKvZ6TwWIT3YHaA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 61d7b5eb-af38-4bc4-f662-08d511f2affc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 04599F3534 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(13464003)(32952001)(377454003)(189002)(199003)(377424004)(53936002)(9686003)(86362001)(6506006)(229853002)(230783001)(2351001)(77096006)(50986999)(5640700003)(2501003)(6436002)(53546010)(6306002)(102836003)(105586002)(6246003)(54356999)(3846002)(99286003)(478600001)(76176999)(106356001)(66066001)(33656002)(101416001)(55016002)(6116002)(5660300001)(189998001)(25786009)(316002)(6916009)(3280700002)(7696004)(68736007)(8936002)(8676002)(1730700003)(81156014)(81166006)(2906002)(7736002)(305945005)(74316002)(2950100002)(80792005)(4001150100001)(14454004)(966005)(3660700001)(2900100001)(72206003)(97736004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2017 04:27:17.3891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6135> : inlines <6130> : streams <1767018> : uri <2515700> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-05.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 04:27:23 -0000 This revision https://tools.ietf.org/html/draft-ietf-dots-signal-channel-05= addresses comments received from Jon.=20 -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, October 13, 2017 9:44 AM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-05.txt > Pages : 58 > Date : 2017-10-12 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. A companion > document defines the DOTS data channel, a separate reliable > communication layer for DOTS management and configuration. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-05 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Oct 12 21:46:41 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDE7134325; Thu, 12 Oct 2017 21:46:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150786999934.23874.4072989911038197395@ietfa.amsl.com> Date: Thu, 12 Oct 2017 21:46:39 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-05.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 04:46:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Kaname Nishizuka Liang Xia Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-data-channel-05.txt Pages : 28 Date : 2017-10-12 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data not easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-05 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 12 21:49:41 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2153134337 for ; Thu, 12 Oct 2017 21:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 crflFclghlm7 for ; Thu, 12 Oct 2017 21:49:38 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 E4918134323 for ; Thu, 12 Oct 2017 21:49:37 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1507870177; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-exchange-antispam-report-test:x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=J IwzUK2fhgQ7Uvn8833TAz+IXkqSGIzoDcYpLbu+C9 M=; b=DkruWDLuOor/32ZpdTC/qtI5SZsDdm//hVoc/vkuE4Mq 7VaNcMoQ6lnQUSbaLVmHQJlXjupCN4AC/y91zVDbxL5JjhwlIk cw4lpQ0/VrOaJSxV8Qlfg5lyykh6Lt3tTcG5QiOUyPRc0re5wi xsIJX8Nsnkvf/e7sicRg7/iOJIU= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 1829_22a7_14a796ab_5db0_4181_a6da_37fb4122010e; Thu, 12 Oct 2017 23:49:36 -0500 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 12 Oct 2017 22:49:35 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 12 Oct 2017 22:49:34 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 12 Oct 2017 22:49:34 -0600 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 12 Oct 2017 22:49:34 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 13 Oct 2017 04:49:33 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.021; Fri, 13 Oct 2017 04:49:33 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-05.txt Thread-Index: AQHTQ95Q4U+rLirs30+h2NmYjFoOvKLhNVsA Date: Fri, 13 Oct 2017 04:49:32 +0000 Message-ID: References: <150786999934.23874.4072989911038197395@ietfa.amsl.com> In-Reply-To: <150786999934.23874.4072989911038197395@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:qELUetu8w/zojOyMQrWqi/0AeOGnmkFsWsSuKTDaAFu/wV+OijiQxkeblbMaXVP9g+EFI4bKJCTMORthtoqeaiDAIHDQFdsrFiHPn1nZ68N53gmVHq3/oUW8cxEdbG4GAD9tdz9+qPARsEyLYvjgsIkSBcrkChWnr8PjiYtHZJb+/Os8MC1yV5YG9f4/YZ21KlT4puybLa9xSHQYbq5zPc2DoLeja+86pAk8RjUbgESmWcNM0SCLK8E7yU9AU4pb95OvoSSwN3VnVghCKE4CzJIcJFUnpaMyIHPUzkr4DNRdg96JwPUYWsE+/pKRfX28Mjyyaf796eXOwjM/ZoWpCQ==; 5:tslLMrqt/hOJx5NWYY98KLUf5VpmX+G0ljzMnfNZxQykmymYQQpEOKk1RKG9JJwHmHRR69y3ULjC7cs456anKL7YMRHYzRNoCSI5JMMwbbZR+s28h3jLTTGY7N8eeY3vW2GsGfuMeba47sS1hfgyiQ==; 24:tKUuRg7kJIN3CfPuJRXOpvhQn91womF6+mshhum/p3P1Pl3ZPXz0k8GA6wihlVBRfl1xifbDIpvXjoCZjCW379xmwH9vWpRBEe710givnJk=; 7:PxQNqnaVYmTHJZH/vI7RuwbbcWjfLw2By2woRAPShb6d1M2YMKkwe8D4cRlD6gmWBcZVIqiUPeu5/cqnf7pDNS8BAhXZn+1SKGl2gnpMkaNXULVZQ7nYP9/HoOqXeUyYOtecvlSQLUsYkS4C1nqQr/xyOb5jLdzwI5r2FHxLdFoWJyrSqTIQ/4YtJRfotBvvHJ3K8ZEj4YgKPDNbNorOpIJD4ZlSOGYP/R4fZHRzMlU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 97315eb9-b857-478b-f35f-08d511f5cc11 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 04599F3534 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(13464003)(377424004)(377454003)(32952001)(199003)(33656002)(966005)(101416001)(50986999)(54356999)(76176999)(478600001)(72206003)(2351001)(25786009)(106356001)(105586002)(3280700002)(230783001)(3660700001)(2501003)(2906002)(2950100002)(6916009)(5660300001)(7696004)(6246003)(2900100001)(6306002)(53936002)(9686003)(189998001)(66066001)(68736007)(6116002)(97736004)(4001150100001)(80792005)(102836003)(99286003)(55016002)(8676002)(81166006)(81156014)(74316002)(5640700003)(305945005)(229853002)(14454004)(7736002)(316002)(1730700003)(86362001)(6506006)(77096006)(3846002)(8936002)(6436002)(53546010)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2017 04:49:32.9618 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6135> : inlines <6130> : streams <1767020> : uri <2515708> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-05.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 04:49:40 -0000 This revision https://tools.ietf.org/html/draft-ietf-dots-data-channel-05 a= ddresses comments from Jon. Uploaded both DOTS signal and data channel draf= ts to https://github.com/dotswg to track comments and updates. -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, October 13, 2017 10:17 AM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Data Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Kaname Nishizuka > Liang Xia > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-data-channel-05.txt > Pages : 28 > Date : 2017-10-12 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data not > easily or appropriately communicated through the DOTS signal channel > under attack conditions. This is a companion document to the DOTS > signal channel specification. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-data-channel-05 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Oct 13 07:43:40 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC2C13306F for ; Fri, 13 Oct 2017 07:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vdjg4YvRQpE for ; Fri, 13 Oct 2017 07:43:37 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C0313306C for ; Fri, 13 Oct 2017 07:43:37 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id A4F85C02A2; Fri, 13 Oct 2017 16:43:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 862DE1A0063; Fri, 13 Oct 2017 16:43:35 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0361.001; Fri, 13 Oct 2017 16:43:35 +0200 From: To: "Teague, Nik" CC: "dots@ietf.org" Thread-Topic: [Dots] Multihoming & Requirements I-D Thread-Index: AdMB7J9UMsgK1k4tR6G+2SshwpeLvxCRLFZA Date: Fri, 13 Oct 2017 14:43:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05387C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A011752@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9C775E38-299E-449D-922E-69DD62E9ED04@arbor.net>, <787AE7BB302AE849A7480A190F8B93300A0117A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Multihoming & Requirements I-D X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 14:43:39 -0000 Hi Nick, I have parked this one for a moment.=20 An example of the changes I would like to see added to the requirements dra= ft is available at:=20 https://github.com/dotswg/dots-requirements/pull/61/files=20 I can provide more text, but let's start with this. Cheers, Med > -----Message d'origine----- > De=A0: Teague, Nik [mailto:nteague@verisign.com] > Envoy=E9=A0: vendredi 21 juillet 2017 10:06 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: Roland Dobbins; dots@ietf.org > Objet=A0: Re: [Dots] Multihoming & Requirements I-D >=20 >=20 >=20 > Sent from my iPhone >=20 > > On 21 Jul 2017, at 09:39, "mohamed.boucadair@orange.com" > wrote: > > > > The goal is to provide a set of guidance for DOTS clients/gateways when > multihomed. >=20 > I think this may be key point here - I think the issue of multihoming may > be more a question for implementors vs the protocol itself but have no > objections to clarifying text. >=20 > I would like to understand if there are any suggested updates to the > architecture and requirements drafts that you feel would address the > concern? >=20 > Thanks, >=20 > -Nik From nobody Fri Oct 13 17:45:20 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1551326ED for ; Fri, 13 Oct 2017 17:45: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 lRBflCm1Qhox for ; Fri, 13 Oct 2017 17:45:17 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 21FFF132332 for ; Fri, 13 Oct 2017 17:45:17 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id u32so6422322uau.0 for ; Fri, 13 Oct 2017 17:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=TDbbDErBuB1W6YJwMYknnEjmuq62CjdFf5IGm5y3MiU=; b=Pe1u4RZ36qMYyISsi0PTvB6XwO/rJAKqFjia/4QD3IDXMargStTuSKzKG9Hl8ak28I xqoJ4ioskUDj/sUqtmWrbHbw7qQ/LU1quLzQeE62vBgVQe19HwB/pzJgi26l0Mf0XFvR 48mzWZ2WW/wboUMC8F86NPfxACaRidduCODrK8a+NCTrc/E4kKT8s7Z1OBcFr+cB1LAC DE8Spqj+a0mphlojaOgED873z6dsbyImGhS5frJR/+aiwiAw/KPwmWRZZ5a3PI+C5G/8 dP1jl+J885cANP2QIRwJ5XbHKqIFswJVfoqOr47FvyhRQrAc+ZgJF0gZx7+jhMrx5QUn 9Dkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=TDbbDErBuB1W6YJwMYknnEjmuq62CjdFf5IGm5y3MiU=; b=sFAJkE1cYLxJdM96M/0IBMxbyixNWxXaAy7hYpOeNxX96jeRpqjfv2WTSK6vRDptI+ eBCnfPH3y/uKFmSZeVAW/IOdX8W/WQ+sJcxIsxR7WmF6bENToMKn2JQc951Fgjv4mCS9 gfd4zWjArzm7abhgClMooOp0LNaAniuyU6fU1ojI3FyOfwnWpVPfXM6noARsHpFc/0KK eV0HO7wcILd2NgaLCuAzp2iMP2bO2E3S8Q7tmA/Ep8OgZZ1jOZrb2jTjWAnIYiiUW+FL oO/IPCkg8C1uTtfBX9FQ5XKTjZRruOsZPX6A7dgFtCez630J1nXAEPQzFy3E9sg0byD+ q9Pw== X-Gm-Message-State: AMCzsaWMdlsUkDk/8RIQ0ZQX7BooBbJdAyPLwNAlleZW/30IlTa5pVii z3M6BXjyO3/Hkj5CqmrpIJPtqZS4nDq4+h/tKUpsaoAw X-Google-Smtp-Source: AOwi7QD102iRCTaIj5PJdBS+//sV4wTc0FzAPqcqu19u6hmXLl86QVuPda9WyamG9jnuumG2tIyuosGQXVUfTKLfRQo= X-Received: by 10.176.28.5 with SMTP id a5mr2680158uaj.157.1507941915876; Fri, 13 Oct 2017 17:45:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.71.134 with HTTP; Fri, 13 Oct 2017 17:44:55 -0700 (PDT) In-Reply-To: References: From: Artyom Gavrichenkov Date: Sat, 14 Oct 2017 03:44:55 +0300 Message-ID: To: dots@ietf.org Content-Type: multipart/alternative; boundary="f403043e4bbc3ce2c8055b7716c8" Archived-At: Subject: Re: [Dots] A few suggestions for draft-ietf-dots-use-cases-07 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 00:45:19 -0000 --f403043e4bbc3ce2c8055b7716c8 Content-Type: text/plain; charset="UTF-8" Hi, I know, everyone is busy, but still, could I have any response on this? Hereby I declare that I'm fine here with Crocker's rules, so, if you feel I'm dumb or don't understand something, please don't hesitate to express that. I'll just be really happy with some input that will help me move forward. Thanks, and have a good day, | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 On Mon, Oct 2, 2017 at 1:38 PM, Artyom Gavrichenkov wrote: > Hi! > > Here's the subj. I believe, some of the issues I'm raising were > discussed already, but I'm not able to find the relevant e-mail > threads. Sorry for that. > > == > 3.1.1. > - Paragraph 3: "is performed" -> "are performed". > - I propose changing the use case title: > "End-customer with a single upstream transit provider offering DDoS > mitigation services" > -> > "End-customer with a single upstream transit provider offering DDoS > mitigation services on demand" > - I propose adding two new paragraphs after paragraph 7, as follows: > > It is understood that the upstream transit provider may be unable to > end the mitigation in case the DOTS client has requested for the DDoS > mitigation services to be terminated, but the attack is still ongoing. > For example, the upstream transit provider may use Flow Specification > Rules within its Border Gateway Protocol sessions [RFC5575] to filter > the attack traffic by the means of indicating that some traffic > patterns shouldn't be allowed to reach its border routers. Therefore, > the upstream transit provider may not be able to end the mitigation at > the request, because its own network will be then flooded with > malicious traffic, rendering it unusable for the enterprise as well as > for nearly all other customers of the provider. In such case, the > DOTS server responds to the termination request with a message > indicating that the request has been acknowledged, but cannot be > currently fulfilled and will be addressed as soon as it is possible. > The DOTS client may still request the mitigation status information, > statistics and other related information beyond this point. The DOTS > client may cancel the termination request by issuing the mitigation > request again. > > Another issue with Flow Specification Rules and other similar > mechanisms is that the upstream transit provider may be unable to > provide any reasonable information on the status of the attack, as > this information is not available to the upstream transit provider > itself. In this case, in response to any request for mitigation > status information, statistics and other related information the > upstream transit provider must clearly indicate that it employs > tools which can affect the quality of the provided information. The > DOTS client should then treat the statistics returned as a rough > estimate at best, and should make his decision to request the > mitigation termination based on other information available, for > example, on the data received from other upstream transit providers > (see 3.1.2) or from the local CSIRT (see 3.1.10). > > > == > 3.1.2. > I propose a new paragraph (IPaNP), after 2. The motivation: this is > what already happens now, ad-hoc, via phone or instant messaging, > without DOTS and/or any mutual agreements between ISPs. Therefore, it > makes sense to cover this case in the process of designing a DDoS > mitigation control protocol: > > In case there's no such agreement between the upstream transit > providers, the DOTS client may still decide to share the information > and statistics obtained from one or more of the upstream transit > providers to others by unicasting or broadcasting the status messages. > An upstream transit provider receiving this kind of data may then plan > the allocation of its mitigation facilities with accordance to the > current risk level, as seen by other upstream transit providers or the > enterprise itself. > > > == > 3.1.4. > IPaNP, after 5: > > The MSSP receiving a request to end the mitigation may be unable to > act accordingly due to reasons similar to what is discussed in 3.1.1. > In such case, the enterprise may react with diversion of Internet > traffic destined for its network back from the MSSP network > facilities, or may wait for MSSP to effectively stop the mitigation. > > > == > 3.1.5. > I propose changing the paragraph 2 to the following: > > The DOTS client built into the Web server has been configured to > request DDoS mitigation services from an upstream transit provider or > overlay MSSP once specific attack traffic thresholds have been > reached, or certain network traffic conditions prevail, or the Web > application behind the Web server becomes unable to successfully > handle all the incoming HTTP requests on time due to the limited CPU > power or RAM amount and there's a pattern in some those HTTP requests > which is qualified as typical for a DDoS attack by the Web > application. Once the specified conditions have been met, the DOTS > communications dialogue and subsequent DDoS mitigation initiation and > termination actions described above take place. > > > == > 3.1.6. > I propose a change to the paragraph 1: > "router, layer-3 switch, firewall, or load-balance" > -> > "router, layer 3 switch, firewall, IDS, IPS, Web application firewall, > or load balancer". > > > == > 3.1.8. > IPaNP, after 3: > > Note that only the messages directly related to the DDoS attack and > mitigation status should be passed between the DDoS MSSPs via DOTS, > both in the request for an assistance and during the course of the > attack. The exchange of the rest of the information that may be of > use in this scenario, which includes interconnection metadata, > logging, authorization rules, geo-blocking restriction policies, and > similar data, falls out of scope for this document and must be > implemented by the means of other protocols and interfaces, such as > Content Delivery Network Interconnection (CDNI) Logging interface > [RFC7937] or CDNI Metadata interface [RFC8006]. > > > == > I propose adding two more use cases, as follows: > > 3.1.9. End-customer with an upstream transit provider or MSSP > offering DDoS mitigation services on the permanent basis > > This scenario shares almost all characteristics with 3.1.1, except > that due to the lack of a capable local IDMS solution, strict uptime > requirements, or other reasons the enterprise has previously requested > its hosting provider, upstream transit provider or MSSP in > its place to provide the DDoS mitigation services permanently, > without a need to detect and explicitly turn the mitigation > on in case a DDoS attack has started. > > In this case, when an attack is in place, the DOTS server on the > upstream transit provider network immediately notifies the DOTS client > on the enterprise network about the attack and periodically signals > the DOTS client in order to provide mitigation status information and > related information. The enterprise security and network operations > departments may then use this information to take care of the network > status, to plan maintenance windows and routing policies, and to share > it with CSIRT if applicable (see 3.1.10). > > 3.1.10. Community member notifying CSIRT about the attack > > A Computer Security Incident Response Team (CSIRT) [RFC2350] is > responsible for assisting members of a community within its > constituency in implementing proactive measures to reduce the risks > of computer security incidents, and to assist the community in > responding to such incidents when they occur. The community may > consist of sites, networks or organizations, such as enterprises > operating in one industry, regional transit providers or DDoS > mitigation MSSPs. > > Typically, a Computer Security Incident Response Team would need an > information about ongoing DDoS attack on a member of the community as > soon as possible to act accordingly, issuing notifications, > recommendations and policies for the rest of its community. > > A member of the community implements a DOTS client while the > corresponding CSIRT implements a DOTS server. The DOTS client signals > the DOTS server on the CSIRT network that an attack had started. > During the course of the attack, the DOTS client frequently updates > the information about the status of mitigation, provided by the DDoS > mitigation solution deployed by the member as well as its upstream > transit providers or MSSPs. In turn, the DOTS server on the CSIRT > side periodically signals the DOTS client in order to provide > information about similar attacks currently ongoing on other community > members, so that the DOTS client could make an informed decision to > whether maintain or terminate the mitigation via other means. > > > == > Also, please consider updating the Github repo for the Use Cases draft. > It's now on the version 05 while the most recent one is 07. > > | Artyom Gavrichenkov > | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 > | mailto: ximaera@gmail.com > | fb: ximaera > | telegram: xima_era > | skype: xima_era > | tel. no: +7 916 515 49 58 > --f403043e4bbc3ce2c8055b7716c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I know, everyone is busy, but s= till, could I have any response on this?

Hereby I declare that I'm fine here with Crocker's rules, so, if you feel= I'm=20 dumb or don't understand something, please don't hesitate to expres= s that. I'll just be=20 really happy with some input that will help me move forward.

T= hanks, and have a good day,

<= br>| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc = 4d08 9191
| mailto: ximaera@gmail.com
| fb: ximaera
| telegram: xima_era
| skyp= e: xima_era
| tel. no: +7 916 515 49 58

On Mon, Oct 2, 2017 at 1:38 PM, Artyom Gavri= chenkov <ximaera@gmail.com> wrote:
Hi!

Here's the subj. I believe, some of the issues I'm raising were
discussed already, but I'm not able to find the relevant e-mail
threads. Sorry for that.

=3D=3D
3.1.1.
- Paragraph 3: "is performed" -> "are performed". - I propose changing the use case title:
=C2=A0 "End-customer with a single upstream transit provider offering = DDoS
=C2=A0 mitigation services"
=C2=A0 ->
=C2=A0 "End-customer with a single upstream transit provider offering = DDoS
=C2=A0 mitigation services on demand"
- I propose adding two new paragraphs after paragraph 7, as follows:

=C2=A0 =C2=A0It is understood that the upstream transit provider may be una= ble to
=C2=A0 =C2=A0end the mitigation in case the DOTS client has requested for t= he DDoS
=C2=A0 =C2=A0mitigation services to be terminated, but the attack is still = ongoing.
=C2=A0 =C2=A0For example, the upstream transit provider may use Flow Specif= ication
=C2=A0 =C2=A0Rules within its Border Gateway Protocol sessions [RFC5575] to= filter
=C2=A0 =C2=A0the attack traffic by the means of indicating that some traffi= c
=C2=A0 =C2=A0patterns shouldn't be allowed to reach its border routers.= =C2=A0 Therefore,
=C2=A0 =C2=A0the upstream transit provider may not be able to end the mitig= ation at
=C2=A0 =C2=A0the request, because its own network will be then flooded with=
=C2=A0 =C2=A0malicious traffic, rendering it unusable for the enterprise as= well as
=C2=A0 =C2=A0for nearly all other customers of the provider.=C2=A0 In such = case, the
=C2=A0 =C2=A0DOTS server responds to the termination request with a message=
=C2=A0 =C2=A0indicating that the request has been acknowledged, but cannot = be
=C2=A0 =C2=A0currently fulfilled and will be addressed as soon as it is pos= sible.
=C2=A0 =C2=A0The DOTS client may still request the mitigation status inform= ation,
=C2=A0 =C2=A0statistics and other related information beyond this point.=C2= =A0 The DOTS
=C2=A0 =C2=A0client may cancel the termination request by issuing the mitig= ation
=C2=A0 =C2=A0request again.

=C2=A0 =C2=A0Another issue with Flow Specification Rules and other similar<= br> =C2=A0 =C2=A0mechanisms is that the upstream transit provider may be unable= to
=C2=A0 =C2=A0provide any reasonable information on the status of the attack= , as
=C2=A0 =C2=A0this information is not available to the upstream transit prov= ider
=C2=A0 =C2=A0itself.=C2=A0 In this case, in response to any request for mit= igation
=C2=A0 =C2=A0status information, statistics and other related information t= he
=C2=A0 =C2=A0upstream transit provider must clearly indicate that it employ= s
=C2=A0 =C2=A0tools which can affect the quality of the provided information= .=C2=A0 The
=C2=A0 =C2=A0DOTS client should then treat the statistics returned as a rou= gh
=C2=A0 =C2=A0estimate at best, and should make his decision to request the<= br> =C2=A0 =C2=A0mitigation termination based on other information available, f= or
=C2=A0 =C2=A0example, on the data received from other upstream transit prov= iders
=C2=A0 =C2=A0(see 3.1.2) or from the local CSIRT (see 3.1.10).


=3D=3D
3.1.2.
I propose a new paragraph (IPaNP), after 2. The motivation: this is
what already happens now, ad-hoc, via phone or instant messaging,
without DOTS and/or any mutual agreements between ISPs. Therefore, it
makes sense to cover this case in the process of designing a DDoS
mitigation control protocol:

=C2=A0 =C2=A0In case there's no such agreement between the upstream tra= nsit
=C2=A0 =C2=A0providers, the DOTS client may still decide to share the infor= mation
=C2=A0 =C2=A0and statistics obtained from one or more of the upstream trans= it
=C2=A0 =C2=A0providers to others by unicasting or broadcasting the status m= essages.
=C2=A0 =C2=A0An upstream transit provider receiving this kind of data may t= hen plan
=C2=A0 =C2=A0the allocation of its mitigation facilities with accordance to= the
=C2=A0 =C2=A0current risk level, as seen by other upstream transit provider= s or the
=C2=A0 =C2=A0enterprise itself.


=3D=3D
3.1.4.
IPaNP, after 5:

=C2=A0 =C2=A0The MSSP receiving a request to end the mitigation may be unab= le to
=C2=A0 =C2=A0act accordingly due to reasons similar to what is discussed in= 3.1.1.
=C2=A0 =C2=A0In such case, the enterprise may react with diversion of Inter= net
=C2=A0 =C2=A0traffic destined for its network back from the MSSP network =C2=A0 =C2=A0facilities, or may wait for MSSP to effectively stop the mitig= ation.


=3D=3D
3.1.5.
I propose changing the paragraph 2 to the following:

=C2=A0 =C2=A0The DOTS client built into the Web server has been configured = to
=C2=A0 =C2=A0request DDoS mitigation services from an upstream transit prov= ider or
=C2=A0 =C2=A0overlay MSSP once specific attack traffic thresholds have been=
=C2=A0 =C2=A0reached, or certain network traffic conditions prevail, or the= Web
=C2=A0 =C2=A0application behind the Web server becomes unable to successful= ly
=C2=A0 =C2=A0handle all the incoming HTTP requests on time due to the limit= ed CPU
=C2=A0 =C2=A0power or RAM amount and there's a pattern in some those HT= TP requests
=C2=A0 =C2=A0which is qualified as typical for a DDoS attack by the Web
=C2=A0 =C2=A0application.=C2=A0 Once the specified conditions have been met= , the DOTS
=C2=A0 =C2=A0communications dialogue and subsequent DDoS mitigation initiat= ion and
=C2=A0 =C2=A0termination actions described above take place.


=3D=3D
3.1.6.
I propose a change to the paragraph 1:
=C2=A0"router, layer-3 switch, firewall, or load-balance"
=C2=A0->
=C2=A0"router, layer 3 switch, firewall, IDS, IPS, Web application fir= ewall,
=C2=A0or load balancer".


=3D=3D
3.1.8.
IPaNP, after 3:

=C2=A0 =C2=A0Note that only the messages directly related to the DDoS attac= k and
=C2=A0 =C2=A0mitigation status should be passed between the DDoS MSSPs via = DOTS,
=C2=A0 =C2=A0both in the request for an assistance and during the course of= the
=C2=A0 =C2=A0attack.=C2=A0 The exchange of the rest of the information that= may be of
=C2=A0 =C2=A0use in this scenario, which includes interconnection metadata,=
=C2=A0 =C2=A0logging, authorization rules, geo-blocking restriction policie= s, and
=C2=A0 =C2=A0similar data, falls out of scope for this document and must be=
=C2=A0 =C2=A0implemented by the means of other protocols and interfaces, su= ch as
=C2=A0 =C2=A0Content Delivery Network Interconnection (CDNI) Logging interf= ace
=C2=A0 =C2=A0[RFC7937] or CDNI Metadata interface [RFC8006].


=3D=3D
I propose adding two more use cases, as follows:

3.1.9.=C2=A0 End-customer with an upstream transit provider or MSSP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 offering DDoS mitigation services on the perman= ent basis

=C2=A0 =C2=A0This scenario shares almost all characteristics with 3.1.1, ex= cept
=C2=A0 =C2=A0that due to the lack of a capable local IDMS solution, strict = uptime
=C2=A0 =C2=A0requirements, or other reasons the enterprise has previously r= equested
=C2=A0 =C2=A0its hosting provider, upstream transit provider or MSSP in
=C2=A0 =C2=A0its place to provide the DDoS mitigation services permanently,=
=C2=A0 =C2=A0without a need to detect and explicitly turn the mitigation =C2=A0 =C2=A0on in case a DDoS attack has started.

=C2=A0 =C2=A0In this case, when an attack is in place, the DOTS server on t= he
=C2=A0 =C2=A0upstream transit provider network immediately notifies the DOT= S client
=C2=A0 =C2=A0on the enterprise network about the attack and periodically si= gnals
=C2=A0 =C2=A0the DOTS client in order to provide mitigation status informat= ion and
=C2=A0 =C2=A0related information.=C2=A0 The enterprise security and network= operations
=C2=A0 =C2=A0departments may then use this information to take care of the = network
=C2=A0 =C2=A0status, to plan maintenance windows and routing policies, and = to share
=C2=A0 =C2=A0it with CSIRT if applicable (see 3.1.10).

3.1.10.=C2=A0 Community member notifying CSIRT about the attack

=C2=A0 =C2=A0A Computer Security Incident Response Team (CSIRT) [RFC2350] i= s
=C2=A0 =C2=A0responsible for assisting members of a community within its =C2=A0 =C2=A0constituency in implementing proactive measures to reduce the = risks
=C2=A0 =C2=A0of computer security incidents, and to assist the community in=
=C2=A0 =C2=A0responding to such incidents when they occur.=C2=A0 The commun= ity may
=C2=A0 =C2=A0consist of sites, networks or organizations, such as enterpris= es
=C2=A0 =C2=A0operating in one industry, regional transit providers or DDoS<= br> =C2=A0 =C2=A0mitigation MSSPs.

=C2=A0 =C2=A0Typically, a Computer Security Incident Response Team would ne= ed an
=C2=A0 =C2=A0information about ongoing DDoS attack on a member of the commu= nity as
=C2=A0 =C2=A0soon as possible to act accordingly, issuing notifications, =C2=A0 =C2=A0recommendations and policies for the rest of its community.
=C2=A0 =C2=A0A member of the community implements a DOTS client while the =C2=A0 =C2=A0corresponding CSIRT implements a DOTS server.=C2=A0 The DOTS c= lient signals
=C2=A0 =C2=A0the DOTS server on the CSIRT network that an attack had starte= d.
=C2=A0 =C2=A0During the course of the attack, the DOTS client frequently up= dates
=C2=A0 =C2=A0the information about the status of mitigation, provided by th= e DDoS
=C2=A0 =C2=A0mitigation solution deployed by the member as well as its upst= ream
=C2=A0 =C2=A0transit providers or MSSPs.=C2=A0 In turn, the DOTS server on = the CSIRT
=C2=A0 =C2=A0side periodically signals the DOTS client in order to provide<= br> =C2=A0 =C2=A0information about similar attacks currently ongoing on other c= ommunity
=C2=A0 =C2=A0members, so that the DOTS client could make an informed decisi= on to
=C2=A0 =C2=A0whether maintain or terminate the mitigation via other means.<= br>

=3D=3D
Also, please consider updating the Github repo for the Use Cases draft.
It's now on the version 05 while the most recent one is 07.

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: ximaera@gmail.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

--f403043e4bbc3ce2c8055b7716c8-- From nobody Fri Oct 13 17:45:46 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53163132332 for ; Fri, 13 Oct 2017 17:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttbXsN0Qe2Co for ; Fri, 13 Oct 2017 17:45:42 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 AB151132403 for ; Fri, 13 Oct 2017 17:45:41 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id h34so6409766uaa.6 for ; Fri, 13 Oct 2017 17:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EyONAiwJVb2YGaimxpT/LlctCF5aYqmLMDQl25PGWwY=; b=npMB4h2bxTOvSNgNHZEz+SnCTq8vINF2CHFUpCiVOjU+esmzsQEr1HLDvZ4d0uU8od uhPIqk8+IWMnrPY1lP416nMJic2Kpk5vM6tQsLUMEAWaWXpn8nFTbZaethJoTCMk9Y+t J7guqhe2mJqNRpJYMk8EwyKFdJ74fhSHs+hOkF46t+ToDEUg11QRqMkU+hsgbT+3aNiR G+NVNrIbGA+LQWnUGAsxKSq+eLjBSJQIZ1rkIvDAWlJJnfZQGpGY/bDW7HQeR8aHjZ3S N+VdjcMm3lNW8jKlNnxnDTz199d2eMmN2GzzGe7dTcoKrpHdEofc5sEEszMlo1OI5C+b zQtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=EyONAiwJVb2YGaimxpT/LlctCF5aYqmLMDQl25PGWwY=; b=jGDXLL/1YrU4ryCpCWDtywCEhgZEFz6U/QoNM17zm+nLKIa2LJd5yDBn6qi5BYK+V4 nItfrYQ1nbuRq+3jqCAA1YzsJXWPyCiSPlfDiyrnBxX6zgtTDyVhd81Sj5yhdtNXley5 zA5QG8f+9vTuhchpKsTjpUC05++bh+dma+Sqa9EZOi82nzwQgqZQpcHvodTUqMvcArX9 Fu81+qGVt6fs69Fz2y/J3SiHTOa67Jm3k7huDHKpvAI288vNAkoZScbrC5J9YUJqsVdN n1yriQcpd4PMljtyRIhFyfmywy4UtvvvWwwoNgceTXh63UK898H0rg3pNN7wfjA/nKM3 V8ag== X-Gm-Message-State: AMCzsaU7O7wM3oIdNTd4oIO1VejRS/uH48R+IjTK9D2/lC47iUunZQLj BJlN5iNsDh8qkI/yvbIQPzPzLNCufOHaNMunc3CLBkCh X-Google-Smtp-Source: AOwi7QDcUyP1Fj97GGdDO7JbM1pF6JYzwmiuUQ7Lz5bPE5bwYl496jau3jrAUSybUjpW14cfh3NHo8E4gVBJ4aaSgxI= X-Received: by 10.176.27.164 with SMTP id k36mr2528844uai.59.1507941940473; Fri, 13 Oct 2017 17:45:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.71.134 with HTTP; Fri, 13 Oct 2017 17:45:20 -0700 (PDT) In-Reply-To: References: From: Artyom Gavrichenkov Date: Sat, 14 Oct 2017 03:45:20 +0300 Message-ID: To: dots@ietf.org Content-Type: multipart/alternative; boundary="94eb2c13320ab436ae055b7717b1" Archived-At: Subject: Re: [Dots] A few suggestions for draft-ietf-dots-requirements-06 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 00:45:44 -0000 --94eb2c13320ab436ae055b7717b1 Content-Type: text/plain; charset="UTF-8" Hi again, " Hi, I know, everyone is busy, but still, could I have any response on this? Hereby I declare that I'm fine here with Crocker's rules, so, if you feel I'm dumb or don't understand something, please don't hesitate to express that. I'll just be really happy with some input that will help me move forward. Thanks, and have a good day, " | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 On Mon, Oct 2, 2017 at 1:42 PM, Artyom Gavrichenkov wrote: > Hi! > > Here are my two cents for the current draft. > > > == > 2.2, SIG-005. > > There's a concern my concern about limiting the size of the > active-but-terminating period. To quote my suggestions for the use > case document: > > > It is understood that the upstream transit provider may be unable to > > end the mitigation in case the DOTS client has requested for the DDoS > > mitigation services to be terminated, but the attack is still ongoing. > > For example, the upstream transit provider may use Flow Specification > > Rules within its Border Gateway Protocol sessions [RFC5575] to filter > > the attack traffic by the means of indicating that some traffic > > patterns shouldn't be allowed to reach its border routers. Therefore, > > the upstream transit provider may not be able to end the mitigation at > > the request, because its own network will be then flooded with > > malicious traffic, rendering it unusable for the enterprise as well as > > for nearly all other customers of the provider. In such case, the > > DOTS server responds to the termination request with a message > > indicating that the request has been acknowledged, but cannot be > > currently fulfilled and will be addressed as soon as it is possible. > > The DOTS client may still request the mitigation status information, > > statistics and other related information beyond this point. The DOTS > > client may cancel the termination request by issuing the mitigation > > request again. > > > > Another issue with Flow Specification Rules and other similar > > mechanisms is that the upstream transit provider may be unable to > > provide any reasonable information on the status of the attack, as > > this information is not available to the upstream transit provider > > itself. In this case, in response to any request for mitigation > > status information, statistics and other related information the > > upstream transit provider should clearly indicate that it employs > > tools which can affect the quality of the provided information. The > > DOTS client should then treat the statistics returned as a rough > > estimate at best, and should make his decision to request the > > mitigation termination based on other information available, for > > example, on the data received from other upstream transit providers > > (see 3.1.2) or from the local CSIRT (see 3.1.10). > > What's important here are the consequences for a DOTS client which > decides to withdraw the mitigation request while an attack is still > ongoing. If the active-but-terminating period is initially 30 seconds > tops, then after 30 seconds the mitigator will either continue > filtering, yet making the DOTS client unable to track the mitigation > status, or it may just use a black hole community to drop the traffic > towards the victim completely, so the result is complete downtime for > the victim. But if the active-but-terminating period is unlimited, > then the client will still have full control on the situation. And, if > it's really eager to stop the mitigation no matter what, it may just > kill the BGP session towards the mitigator. > > At least, it seems to be important to split those cases: > 1) a DOTS client requests the DOTS server to end the mitigation, where > the server may acknowledge the request but refuse to comply for an > unlimited period of time; > 2) a DOTS client requests the DOTS server to end the mitigation > completely (due to excessive costs, for instance), where the server > MUST comply but may start to drop the traffic completely. > > I'll be happy to provide detailed requirements for both scenarios if > you want me to. > > A side note: I can't find this in the mailing list, but why the > initial window is 30 seconds? What can a mitigation provider actually > do within this period? It's not enough even for BGP announcement to > propagate globally. I've seen a BGP announcement propagation taking up > to 2 minutes, for example. A brief RIPE Labs study ( > https://labs.ripe.net/Members/vastur/the-shape-of-a-bgp-update ) > showed that full visibility of an announcement took about 38 seconds, > while a subsequent withdrawal took more than 2 minutes to propagate. > > Moreover, the architecture document even features the concept of > gateway and chaining. A request to end the mitigation may propagate > through the gateway, acting as a sort of proxy, towards the upper > level mitigation provider, which may take time on a saturated network > link. Then, this upper level provider is left with, like, 20 seconds > to comply. So I'd consider changing the MUST in the last paragraph of > SIG-005 to SHOULD. > > == > 2.2, SIG-007. > > Under certain conditions, a DOTS client may be an awful decision > maker. Imagine a 80 Gbps DDoS attack with combined SYN flood, WP > Pingback and HTTPS flood towards a typical 200 Mbps link. The > congestion on the last mile will render any network service, including > the CPE with DOTS client in it, unable to come up with any sane > mitigation scope. > > Thus, I propose changing the first MUST in SIG-007 to SHOULD. > > > == > 2.2, SIG-009. > > "Conflicting" or complementing? Note that different DOTS clients in an > enterprise network infrastructure may have different visibility > scopes, either per some subsets of IP addresses (which may of may not > form one continuous prefix range) or per OSI level. Using the previous > example, one DOTS client on an IDS/IPS will see a SYN flood while > another DOTS client on a Web server will see an HTTPS flood towards > the same network resource. The IDS (like Snort) will be unable to > track down HTTPS requests while the Web server wouldn't see the SYN > flood mostly mitigated on the IDS. > > One may argue that in this case there must be a DOTS gateway at the > edge of the network, acting as a proxy and a decision maker, yet > again, in practical datacenter conditions it may be hard to set up and > maintain one. > > > == > 2.3, DATA-004 > > It is unclear what should happen if a DOTS client adds an entry both > to the blacklist and to the whitelist. Either one of the lists should > be given priority over the other, or, say, adding an entry to the > blacklist should automatically force the deletion of the corresponding > entry from the whitelist (which may add computational complexity). > Leaving this up to the implementation may cause harm to > inter-operability of different clients and servers. > > I'd consider adding a paragraph like that: > > A DOTS client MUST assume complete responsibility for maintaining > all the entries it adds both to the blacklist and to the whitelist. > In case of a collision (i. e. when an entry is added to the > blacklist which is already present in the whitelist, or vice versa) > the behaviour is undefined. > > > == > 1.2. > It's not that important really, but I'd consider reviewing the > definition of DDoS attack. > > Currently, DDoS is defined as "a distributed denial-of-service attack, > in which traffic originating from multiple sources are directed at a > target on a network". This lacks the definition of "source". Is it a > source IP address? Then, a SYN flood with a fixed spoofed IP source > doesn't qualify to be called DDoS, which is odd. > > Or, is it a network source, like, a physical machine? Do virtual > instances count then? And, again, a SYN flood generated on a single > server somewhere on DEC-IX (which is actually what we faced once) is > not a DDoS attack? > > I'd consider changing the definition towards the perceived effect and > the goal of an attacker. Something on the lines of: > > DoS: an attack in which one or more machines target a victim and > attempt to prevent the victim from doing useful work by rendering the > victim unavailable, unresponsible, or unreachable. > > DDoS: a DoS attack which achieves the goal of rendering the victim > unavailable, unresponsible, or unreachable by the means of exhausting > the finite resources of a network connected entity, which may or > may not be the victim itself. Denial-of-service considerations are > discussed in detail in [RFC4732]. > > Or one can simply take the definition from one of Roland's > presentations, like that: > http://mirror.die.net/misc/defending-ddos/stateofdanger.pdf , slide 3. > > | Artyom Gavrichenkov > | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 > | mailto: ximaera@gmail.com > | fb: ximaera > | telegram: xima_era > | skype: xima_era > | tel. no: +7 916 515 49 58 > --94eb2c13320ab436ae055b7717b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi again,

"
Hi,

I kn= ow, everyone is busy, but still, could I have any response on this?

= Hereby I declare that I'm fine here with Crocker's rules, so, if you feel= I'm=20 dumb or don't understand something, please don't hesitate to expres= s that. I'll just be=20 really happy with some input that will help me move forward.

T= hanks, and have a good day,
"
<= br clear=3D"all">

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1= ee5 00e7 94bc 4d08 9191
| mailto: ximaera@gmail.com
| fb: ximaera
| telegram: xima= _era
| skype: xima_era
| tel. no: +7 916 515 49 58

On Mon, Oct 2, 2017 at 1:42 PM, Artyom Gavri= chenkov <ximaera@gmail.com> wrote:
Hi!

Here are my two cents for the current draft.


=3D=3D
2.2, SIG-005.

There's a concern my concern about limiting the size of the
active-but-terminating period. To quote my suggestions for the use
case document:

> It is understood that the upstream transit provider may be unable to > end the mitigation in case the DOTS client has requested for the DDoS<= br> > mitigation services to be terminated, but the attack is still ongoing.=
> For example, the upstream transit provider may use Flow Specification<= br> > Rules within its Border Gateway Protocol sessions [RFC5575] to filter<= br> > the attack traffic by the means of indicating that some traffic
> patterns shouldn't be allowed to reach its border routers.=C2=A0 T= herefore,
> the upstream transit provider may not be able to end the mitigation at=
> the request, because its own network will be then flooded with
> malicious traffic, rendering it unusable for the enterprise as well as=
> for nearly all other customers of the provider.=C2=A0 In such case, th= e
> DOTS server responds to the termination request with a message
> indicating that the request has been acknowledged, but cannot be
> currently fulfilled and will be addressed as soon as it is possible. > The DOTS client may still request the mitigation status information, > statistics and other related information beyond this point.=C2=A0 The = DOTS
> client may cancel the termination request by issuing the mitigation > request again.
>
> Another issue with Flow Specification Rules and other similar
> mechanisms is that the upstream transit provider may be unable to
> provide any reasonable information on the status of the attack, as
> this information is not available to the upstream transit provider
> itself.=C2=A0 In this case, in response to any request for mitigation<= br> > status information, statistics and other related information the
> upstream transit provider should clearly indicate that it employs
> tools which can affect the quality of the provided information.=C2=A0 = The
> DOTS client should then treat the statistics returned as a rough
> estimate at best, and should make his decision to request the
> mitigation termination based on other information available, for
> example, on the data received from other upstream transit providers > (see 3.1.2) or from the local CSIRT (see 3.1.10).

What's important here are the consequences for a DOTS client which
decides to withdraw the mitigation request while an attack is still
ongoing. If the active-but-terminating period is initially 30 seconds
tops, then after 30 seconds the mitigator will either continue
filtering, yet making the DOTS client unable to track the mitigation
status, or it may just use a black hole community to drop the traffic
towards the victim completely, so the result is complete downtime for
the victim. But if the active-but-terminating period is unlimited,
then the client will still have full control on the situation. And, if
it's really eager to stop the mitigation no matter what, it may just kill the BGP session towards the mitigator.

At least, it seems to be important to split those cases:
1) a DOTS client requests the DOTS server to end the mitigation, where
the server may acknowledge the request but refuse to comply for an
unlimited period of time;
2) a DOTS client requests the DOTS server to end the mitigation
completely (due to excessive costs, for instance), where the server
MUST comply but may start to drop the traffic completely.

I'll be happy to provide detailed requirements for both scenarios if you want me to.

A side note: I can't find this in the mailing list, but why the
initial window is 30 seconds? What can a mitigation provider actually
do within this period? It's not enough even for BGP announcement to
propagate globally. I've seen a BGP announcement propagation taking up<= br> to 2 minutes, for example. A brief RIPE Labs study (
https://labs.ripe.net/Members/vas= tur/the-shape-of-a-bgp-update )
showed that full visibility of an announcement took about 38 seconds,
while a subsequent withdrawal took more than 2 minutes to propagate.

Moreover, the architecture document even features the concept of
gateway and chaining. A request to end the mitigation may propagate
through the gateway, acting as a sort of proxy, towards the upper
level mitigation provider, which may take time on a saturated network
link. Then, this upper level provider is left with, like, 20 seconds
to comply. So I'd consider changing the MUST in the last paragraph of SIG-005 to SHOULD.

=3D=3D
2.2, SIG-007.

Under certain conditions, a DOTS client may be an awful decision
maker. Imagine a 80 Gbps DDoS attack with combined SYN flood, WP
Pingback and HTTPS flood towards a typical 200 Mbps link. The
congestion on the last mile will render any network service, including
the CPE with DOTS client in it, unable to come up with any sane
mitigation scope.

Thus, I propose changing the first MUST in SIG-007 to SHOULD.


=3D=3D
2.2, SIG-009.

"Conflicting" or complementing? Note that different DOTS clients = in an
enterprise network infrastructure may have different visibility
scopes, either per some subsets of IP addresses (which may of may not
form one continuous prefix range) or per OSI level. Using the previous
example, one DOTS client on an IDS/IPS will see a SYN flood while
another DOTS client on a Web server will see an HTTPS flood towards
the same network resource. The IDS (like Snort) will be unable to
track down HTTPS requests while the Web server wouldn't see the SYN
flood mostly mitigated on the IDS.

One may argue that in this case there must be a DOTS gateway at the
edge of the network, acting as a proxy and a decision maker, yet
again, in practical datacenter conditions it may be hard to set up and
maintain one.


=3D=3D
2.3, DATA-004

It is unclear what should happen if a DOTS client adds an entry both
to the blacklist and to the whitelist. Either one of the lists should
be given priority over the other, or, say, adding an entry to the
blacklist should automatically force the deletion of the corresponding
entry from the whitelist (which may add computational complexity).
Leaving this up to the implementation may cause harm to
inter-operability of different clients and servers.

I'd consider adding a paragraph like that:

=C2=A0 =C2=A0A DOTS client MUST assume complete responsibility for maintain= ing
=C2=A0 =C2=A0all the entries it adds both to the blacklist and to the white= list.
=C2=A0 =C2=A0In case of a collision (i. e. when an entry is added to the =C2=A0 =C2=A0blacklist which is already present in the whitelist, or vice v= ersa)
=C2=A0 =C2=A0the behaviour is undefined.


=3D=3D
1.2.
It's not that important really, but I'd consider reviewing the
definition of DDoS attack.

Currently, DDoS is defined as "a distributed denial-of-service attack,=
in which traffic originating from multiple sources are directed at a
target on a network". This lacks the definition of "source".= Is it a
source IP address? Then, a SYN flood with a fixed spoofed IP source
doesn't qualify to be called DDoS, which is odd.

Or, is it a network source, like, a physical machine? Do virtual
instances count then? And, again, a SYN flood generated on a single
server somewhere on DEC-IX (which is actually what we faced once) is
not a DDoS attack?

I'd consider changing the definition towards the perceived effect and the goal of an attacker. Something on the lines of:

=C2=A0 =C2=A0DoS:=C2=A0 an attack in which one or more machines target a vi= ctim and
=C2=A0 =C2=A0attempt to prevent the victim from doing useful work by render= ing the
=C2=A0 =C2=A0victim unavailable, unresponsible, or unreachable.

=C2=A0 =C2=A0DDoS:=C2=A0 a DoS attack which achieves the goal of rendering = the victim
=C2=A0 =C2=A0unavailable, unresponsible, or unreachable by the means of exh= austing
=C2=A0 =C2=A0the finite resources of a network connected entity, which may = or
=C2=A0 =C2=A0may not be the victim itself.=C2=A0 Denial-of-service consider= ations are
=C2=A0 =C2=A0discussed in detail in [RFC4732].

Or one can simply take the definition from one of Roland's
presentations, like that:
http://mirror.die.net/misc/defending= -ddos/stateofdanger.pdf , slide 3.

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: ximaera@gmail.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

--94eb2c13320ab436ae055b7717b1-- From nobody Sun Oct 15 23:23:29 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ACE1342EB for ; Sun, 15 Oct 2017 23:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 LYkGBb8VrPFu for ; Sun, 15 Oct 2017 23:23:25 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 938091342E8 for ; Sun, 15 Oct 2017 23:23:25 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1508135004; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=PyGNzNQ1Jf5z0cWS9HNU30R29Ok4r2eWxw35aY OR0Ao=; b=RXmytcoL2KBYdVrDqvYXRPxTO3VN4ZWshMuNnt7T 1gLRYPPPNsoiJW6sr9+Oir37fvH3nAKLCPQOkzaLyHFssXviP2 WajI8aobRZZqQ/r4PBxHGAx41wdBOqvUepHijiVuPzUP6hbyiA dLcwJbhc+qRtm1RhhIgmqKrDu9WwS+Q= Received: from DNVEXAPP1N04.corpzone.internalzone.com (dnvexapp1n04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 4d1b_19b1_c60ba964_043c_4095_9203_87de6da0fd69; Mon, 16 Oct 2017 01:23:24 -0500 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 00:23:21 -0600 Received: from DNVEX10N01.corpzone.internalzone.com (10.44.82.192) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 16 Oct 2017 00:23:21 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEX10N01.corpzone.internalzone.com (10.44.82.192) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 16 Oct 2017 00:23:21 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 00:23:20 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 16 Oct 2017 06:23:19 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.022; Mon, 16 Oct 2017 06:23:19 +0000 From: "Konda, Tirumaleswar Reddy" To: "'dots@ietf.org'" Thread-Topic: Minutes from the October-02-2017 Virtual Interim Meeting Thread-Index: AdM8VrzmSj2Cd2oFQI2oXkHy1FYAHgHnXhdQ Date: Mon, 16 Oct 2017 06:23:19 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC0104FE35B8@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0104FE35B8@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:vL2xHXeul099zu8c4NTOapM2pl4Dyj6ldCgN3k6NQ1n3ZkTxiE2BsuDoQ+WGuv7LZrKusOlPLRekUNMhYP9MAxQMwgt+RkVtvhR2VxqnRu2v0Mz9FAeW1zT5D8uaLiLjdqtoRNm85XKLyaVuxEI/gQcSitp1VUeG2uy15N5SQw/oxDObbwxT6Kl5MpAksXrE7LUC6T1IVsVB6WlDFIp6cROKDAz7Mz1I0hRNLnSSqkfVlndiilgttiQG/o+Ii2dcnlL3s2iyca2CcVWA9P1t0rmWgvdGI2vVo1sn/ECshaVQirEwnGZgy/52Adl+aWHgxTwqd6K3hnbjmNkqOBKkrw==; 5:AM7Md3E8b9EdjwGaiOulXNhmaV6ueDdctsuArYQaf1dFNPU4BwLvy47se8hz5jueWoxGI4ADa/+chLU4QtLkeDVCm3IPtCf/1gNWaOjzdRSEuzjm/rUnuoh++s1/B1jghAkoTftEbsHfqlB2bxb6KQ==; 24:EExOjlS04bLVARrHzoqi17EDl+/custK9K0YIYdP+t3CDkLWNpfoROq0qGEJJAPbqMo8KT9uiKsFPda9kAGrYJTI/UV1Yfbe8W0SnH6tMqI=; 7:zS7BrYCSMq3+WPv0WT4DN//9s4PAu16+gOk4Qob18+la7wzkhlNPd+hNs1J5bFVnb/oNovAP8SLQfZ0G1Xzm7TidKpX92DQRNoMcQg4+i0h/8hAm1nzqATqHUSTPhGdZ/b+NwArikgyFDumADEBpmjnKnSUZI2FzwRiE/wVSakc+OpA8yLb8DX8u+mzxjMCll51vINVd1cG1MT0cq6FpTIQ+3onBehfb44zxJGCozCQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 54f4d645-7158-4acf-4342-08d5145e64f8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(120809045254105)(198458107723671); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(32952001)(13464003)(377454003)(199003)(81156014)(81166006)(8936002)(3846002)(6246003)(33656002)(8676002)(102836003)(6116002)(53936002)(68736007)(7736002)(305945005)(74316002)(230783001)(66066001)(5660300001)(55016002)(9686003)(316002)(80792005)(99286003)(6306002)(6916009)(2950100002)(7696004)(53546010)(2900100001)(97736004)(72206003)(14454004)(966005)(54356999)(76176999)(478600001)(101416001)(50986999)(3660700001)(189998001)(6436002)(2906002)(86362001)(3280700002)(105586002)(6506006)(25786009)(229853002)(77096006)(106356001)(85282002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2017 06:23:19.4547 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6136> : inlines <6133> : streams <1767452> : uri <2517279> Archived-At: Subject: Re: [Dots] Minutes from the October-02-2017 Virtual Interim Meeting X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 06:23:27 -0000 The DOTS signal channel currently uses a default mitigation lifetime of 360= 0 seconds, https://www.sans.org/reading-room/whitepapers/analyst/ddos-attac= ks-advancing-enduring-survey-34700 report discusses that the most common DD= oS attacks lasted less than one hour (42%), although 14% experienced attack= s that lasted for up to one day and 13% for more than a day (between one an= d three days). The weighted average for attack duration across all reported= DDoS attacks is 8.7 hours, or an entire business day. Based on the above survey, looks like the default mitigation lifetime in th= e spec is reasonable.=20 -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Tuesday, October 3, 2017 8:21 PM > To: 'dots@ietf.org' > Subject: [Dots] Minutes from the October-02-2017 Virtual Interim Meeting >=20 > Hello! >=20 > Draft minutes from yesterday's (October 2, 2017) virtual interim meeting = can > be found here: >=20 > https://datatracker.ietf.org/meeting/interim-2017-dots- > 03/materials/minutes-interim-2017-dots-03-201710021000/ >=20 > Thank you to all who attended. If you have corrections to the minutes, > please send them to the chairs. >=20 > Regards, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sun Oct 15 23:37:33 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C991134302 for ; Sun, 15 Oct 2017 23:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 MrasjQNFiK1L for ; Sun, 15 Oct 2017 23:37:29 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 61B98134305 for ; Sun, 15 Oct 2017 23:37:29 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1508135848; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=J o1swc704ZwM1565XhyRS/LlP8ZzeeiNH5fvZ2z8UN I=; b=QEkKNJgx1zbIGZlbMZkzgLm9HS2q33IbgFIUxuKG6b1f OMFPZYzZfM5aDt1k6RclDP5M0gZj1QRfUwQQvzyQty2/7Pf30T SI53cfNAitpEL7mZh8NhGsFF48UhrqNgp30a4a71Rc8bedUkJE gpIIDRhNd6mGskUvrDnavT7ouQo= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 29f1_0af7_c407d508_7359_4d15_b70e_309f4a5179c0; Mon, 16 Oct 2017 01:37:28 -0500 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 02:36:43 -0400 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 02:36:42 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 16 Oct 2017 02:36:42 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 02:36:41 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 16 Oct 2017 06:36:41 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.022; Mon, 16 Oct 2017 06:36:41 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: Indefinite (-1) lifetime parameter value in a mitigation request Thread-Index: AdM8WNcDulXT2ZozSEqn/bTK8DUlxAJ7wYFA Date: Mon, 16 Oct 2017 06:36:41 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A04DB16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A04DB16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:Dlcy22XNCea4Ny9J0UITcSGdG40yTNipublVO6OBWznGYhDry9/scGBn+/k7Tw35rvw9+H0Da7WCt8lI6HLe3yHq5LZdfcS8bqgn1KkS4Ef0/XOK4BIWPE9JlSqHxisAAMslC1NqjbhO2swrGKHsePa8IkSxG8XrN6Av01NuiTpTfgn1LZhIRNWlpzU6q26j9CbLqawS0yrhDXpbrXtzRDkQYzr3DCgM+th+BD27zmRsN1AsK1KPv4licjqclOpwKdUZunBn6hR4qqemhh4TnQxe7LIVFi+gvrhrDhKSS9tniH5T6UDZBshHDs+SGmD/AwVQoVis9NMFyRGpjzSWsw==; 5:Y0lr76/l4mpJKoOgbXtcHTZuEV5k1POrHbgyxL0CfUQBPn9XCEDZ6SZr/Nq7skNsFw8strpFO+YA8EhUXZA72rAJd9lf2yGU37Sbs94lSdkZ/vrb7hlEmCVVJNVi5PJDNUGSxkgpbCZlOiU/ACS4QQ==; 24:aGYUwuADbH5VOHWmM2FjBV8LtQMrHRocF8Ls5BmHn7bKzhj5UsIlb9ndAyQ15LxZ+94BLxN4y5mTows3T/Fk3QFBSOF672B9ZqSPPBtEPlI=; 7:z0geOAVdpbwh0l4j+y+un9TkfCxLwv0poL63THaLTs1P8myKdqmGO3cX7TCJjiGc8/xMfQuJ5m+h+oUbfSDt14l2ay4O7wkJTuLjAnWbqyaPanI/WVwYzzxpWNHVRbvTedETjQuWjvpjWCovkqh+UUi8IJKQvnYHUCAvyaNfuToKMBk7aSZ9KjPzJFnMCu+zUwCQiGm8CWjReKwnOCZYB7SkHsptEhTw51fzRPJLGiw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8096d166-3313-4078-61c6-08d5146042c3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(32952001)(199003)(53754006)(377454003)(3280700002)(53546010)(19609705001)(3660700001)(2950100002)(8936002)(97736004)(316002)(3846002)(102836003)(66066001)(110136005)(2906002)(6116002)(6306002)(14454004)(86362001)(478600001)(81156014)(72206003)(9686003)(81166006)(2501003)(790700001)(8676002)(54896002)(74316002)(6436002)(5660300001)(105586002)(99286003)(76176999)(33656002)(53936002)(54356999)(50986999)(7736002)(77096006)(2900100001)(55016002)(6506006)(7696004)(101416001)(6246003)(25786009)(229853002)(68736007)(189998001)(80792005)(106356001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788F08EC2FD29826300974CEA4F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2017 06:36:41.0747 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6136> : inlines <6133> : streams <1767453> : uri <2517284> Archived-At: Subject: Re: [Dots] Indefinite (-1) lifetime parameter value in a mitigation request X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 06:37:32 -0000 --_000_DM5PR16MB1788F08EC2FD29826300974CEA4F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Artyom has posted a similar use case (https://mailarchive.ietf.org/arch/msg= /dots/J4eAz-511qAHw2pnUkXxNr558Dc) to add to the use cases draft, an End-cu= stomer with an upstream transit provider or MSSP offering DDoS mitigation s= ervices on the permanent basis. I don't see a problem with this use case and below requirement. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Tuesday, October 3, 2017 8:34 PM To: dots@ietf.org Subject: [Dots] Indefinite (-1) lifetime parameter value in a mitigation re= quest Hi all, In reference to the comment raised by Flemming during the interim meeting a= bout the indefinite lifetime, I would like to remind that value was introdu= ced in the signal channel draft to adhere to this requirement from draft-ie= tf-dots-requirements: DOTS servers SHOULD support indefinite mitigation lifetimes, enabling architectures in which the mitigator is always in the traffic path to the resources for which the DOTS client is requesting protection. DOTS servers MAY refuse mitigations with indefinite lifetimes, for policy reasons. The reasons themselves are out of scope for this document, but MUST be included in the mitigation rejection message from the server, per SIG-005. Cheers, Med --_000_DM5PR16MB1788F08EC2FD29826300974CEA4F0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Artyom has posted a similar use case (https://mailarchiv= e.ietf.org/arch/msg/dots/J4eAz-511qAHw2pnUkXxNr558Dc) to add to the use cas= es draft, an End-customer with an upstream transit provider or MSSP offering DDoS mitigation services on the permanen= t basis.

I don’t see a problem with this u= se case and below requirement.

 

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Tuesday, October 3, 2017 8:34 PM
To: dots@ietf.org
Subject: [Dots] Indefinite (-1) lifetime parameter value in a mitiga= tion request

 

Hi all,

 

In reference to the comment raised by Flemming during the = interim meeting about the indefinite lifetime, I would like to remind that = value was introduced in the signal channel draft to adhere to this requirement from draft-ietf-dots-requirements:

 

      DOT= S servers SHOULD support indefinite mitigation lifetimes,=

      ena= bling architectures in which the mitigator is always in the

      tra= ffic path to the resources for which the DOTS client is

      req= uesting protection.  DOTS servers MAY refuse mitigations with

      ind= efinite lifetimes, for policy reasons.  The reasons themselves

      are= out of scope for this document, but MUST be included in the

      mit= igation rejection message from the server, per SIG-005.

 

Cheers,

Med

--_000_DM5PR16MB1788F08EC2FD29826300974CEA4F0DM5PR16MB1788namp_-- From nobody Mon Oct 16 02:00:56 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08C513445B for ; Mon, 16 Oct 2017 02:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH7MqJhv3iSc for ; Mon, 16 Oct 2017 02:00:52 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 D18701243F6 for ; Mon, 16 Oct 2017 02:00:48 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e41GP-0007Y5-VK; Mon, 16 Oct 2017 10:00:46 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A04DB16@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Mon, 16 Oct 2017 10:00:47 +0100 Message-ID: <022301d3465d$4216a700$c643f500$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0224_01D34665.A3DBF960" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIsSItiw+KbZSKdQA/ci7ebhEGfjAKNp3Iooh+70uA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Indefinite (-1) lifetime parameter value in a mitigation request X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 09:00:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0224_01D34665.A3DBF960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This works for me as well. From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 16 October 2017 07:37 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Indefinite (-1) lifetime parameter value in a mitigation request Artyom has posted a similar use case ( https://mailarchive.ietf.org/arch/msg/dots/J4eAz-511qAHw2pnUkXxNr558Dc) to add to the use cases draft, an End-customer with an upstream transit provider or MSSP offering DDoS mitigation services on the permanent basis. I don't see a problem with this use case and below requirement. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Tuesday, October 3, 2017 8:34 PM To: dots@ietf.org Subject: [Dots] Indefinite (-1) lifetime parameter value in a mitigation request Hi all, In reference to the comment raised by Flemming during the interim meeting about the indefinite lifetime, I would like to remind that value was introduced in the signal channel draft to adhere to this requirement from draft-ietf-dots-requirements: DOTS servers SHOULD support indefinite mitigation lifetimes, enabling architectures in which the mitigator is always in the traffic path to the resources for which the DOTS client is requesting protection. DOTS servers MAY refuse mitigations with indefinite lifetimes, for policy reasons. The reasons themselves are out of scope for this document, but MUST be included in the mitigation rejection message from the server, per SIG-005. Cheers, Med ------=_NextPart_000_0224_01D34665.A3DBF960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This works for me as = well.

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 16 October 2017 = 07:37
To: mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] Indefinite (-1) lifetime = parameter value in a mitigation = request

 

Artyom has posted a similar use = case (https://mailarchive.ietf.org/arch/ms= g/dots/J4eAz-511qAHw2pnUkXxNr558Dc) to add to the use cases draft, an = End-customer with an upstream transit provider or MSSP offering DDoS = mitigation services on the permanent basis.

I don’t see a problem with = this use case and below requirement.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Tuesday, October 3, 2017 8:34 PM
To: dots@ietf.org
Subject: = [Dots] Indefinite (-1) lifetime parameter value in a mitigation = request

 

Hi = all,

 

In = reference to the comment raised by Flemming during the interim meeting = about the indefinite lifetime, I would like to remind that value was = introduced in the signal channel draft to adhere to this requirement = from draft-ietf-dots-requirements:

 

      DOTS = servers SHOULD support indefinite mitigation = lifetimes,

      enabling = architectures in which the mitigator is always in = the

      traffic = path to the resources for which the DOTS client = is

      requesting = protection.  DOTS servers MAY refuse mitigations = with

      indefinite = lifetimes, for policy reasons.  The reasons = themselves

      are out of = scope for this document, but MUST be included in = the

      mitigation = rejection message from the server, per SIG-005.

 

Cheers,

Med

------=_NextPart_000_0224_01D34665.A3DBF960-- From nobody Tue Oct 17 02:40:14 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB8B13334E for ; Tue, 17 Oct 2017 02:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMBmU2hlgkww for ; Tue, 17 Oct 2017 02:40:11 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9607613331E for ; Tue, 17 Oct 2017 02:40:11 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 2B09B1C070D for ; Tue, 17 Oct 2017 11:40:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 1060418007F for ; Tue, 17 Oct 2017 11:40:10 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0361.001; Tue, 17 Oct 2017 11:40:10 +0200 From: To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-boucadair-dots-multihoming-02.txt Thread-Index: AQHTRysmMqDkM0lbaky2tM9m1gNMRqLnyD/A Date: Tue, 17 Oct 2017 09:40:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A055D86@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <150823287612.21507.11590006146775541122.idtracker@ietfa.amsl.com> In-Reply-To: <150823287612.21507.11590006146775541122.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Dots] TR: New Version Notification for draft-boucadair-dots-multihoming-02.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 09:40:13 -0000 RGVhciBhbGwsIA0KDQpBIG5ldyB1cGRhdGVkIHZlcnNpb24gb2YgdGhpcyBkcmFmdCBpcyBhdmFp bGFibGUgb25saW5lIHRvIHJlZmxlY3Qgc29tZSBvZiB0aGUgY29tbWVudHMgaGVhcmQgb24gdGhl IG1haWxpbmcgbGlzdC4gDQoNClRoZSBtYWluIGNoYW5nZXMgYXJlOg0KKiBDbGFyaWZ5IHRoYXQg dGhlIGludGVudCBpcyB0byBwcm92aWRlIGRlcGxveW1lbnQgZ3VpZGFuY2Ugd2hlbiBET1RTIGlz IGRlcGxveWVkIGluIGEgbXVsdGktaG9tZWQgY29udGV4dC4NCiogTWFrZSBpdCBjbGVhciB0aGF0 IG5vIHNwZWNpZmljIGV4dGVuc2lvbnMgYXJlIHJlcXVpcmVkIHRvIERPVFMgc2lnbmFsL2RhdGEg Y2hhbm5lbC4NCg0KQ29tbWVudHMsIHN1Z2dlc3Rpb25zLCBhbmQgY29udHJpYnV0aW9ucyBhcmUg d2VsY29tZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+IERlwqA6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBtYXJkaSAxNyBvY3RvYnJlIDIwMTcgMTE6MzUNCj4g w4DCoDogVGlydW1hbGVzd2FyIFJlZGR5OyBUaXJ1bWFsZXN3YXIgUmVkZHk7IEJPVUNBREFJUiBN b2hhbWVkIElNVC9PTE4NCj4gT2JqZXTCoDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1ib3VjYWRhaXItZG90cy1tdWx0aWhvbWluZy0NCj4gMDIudHh0DQo+IA0KPiANCj4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJvdWNhZGFpci1kb3RzLW11bHRpaG9taW5nLTAyLnR4 dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1vaGFtZWQgQm91Y2FkYWly IGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFm dC1ib3VjYWRhaXItZG90cy1tdWx0aWhvbWluZw0KPiBSZXZpc2lvbjoJMDINCj4gVGl0bGU6CQlN dWx0aS1ob21pbmcgRGVwbG95bWVudCBDb25zaWRlcmF0aW9ucyBmb3IgRGlzdHJpYnV0ZWQtDQo+ IERlbmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAoRE9UUykNCj4gRG9jdW1l bnQgZGF0ZToJMjAxNy0xMC0xNg0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQ YWdlczoJCTE0DQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtYm91Y2FkYWlyLWRvdHMtDQo+IG11bHRpaG9taW5nLTAyLnR4dA0KPiBT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91 Y2FkYWlyLWRvdHMtDQo+IG11bHRpaG9taW5nLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1kb3RzLQ0KPiBtdWx0aWhvbWluZy0w Mg0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1ib3VjYWRhaXItDQo+IGRvdHMtbXVsdGlob21pbmctMDINCj4gRGlmZjogICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ib3VjYWRhaXItZG90 cy0NCj4gbXVsdGlob21pbmctMDINCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50 IGRpc2N1c3NlcyBtdWx0aS1ob21pbmcgY29uc2lkZXJhdGlvbnMgZm9yIERpc3RyaWJ1dGVkLQ0K PiAgICBEZW5pYWwtb2YtU2VydmljZSBPcGVuIFRocmVhdCBTaWduYWxpbmcgKERPVFMpLiAgVGhl IGdvYWwgaXMgdG8NCj4gICAgcHJvdmlkZSBhIHNldCBvZiBndWlkYW5jZSBmb3IgRE9UUyBjbGll bnRzL2dhdGV3YXlzIHdoZW4gbXVsdGlob21lZC4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZg0KPiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQo= From nobody Wed Oct 18 07:21:02 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3D613219C for ; Wed, 18 Oct 2017 07:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28pFDyQWjAQP for ; Wed, 18 Oct 2017 07:20:54 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1E3132125 for ; Wed, 18 Oct 2017 07:20:54 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id B7E0A2083F; Wed, 18 Oct 2017 16:20:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 9AC602006D; Wed, 18 Oct 2017 16:20:52 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Wed, 18 Oct 2017 16:20:52 +0200 From: To: Russ White <7riw77@gmail.com> CC: "dots@ietf.org" Thread-Topic: I-D.boucadair-dots-discovery: Russ White Comments Thread-Index: AdNIHEwH4W2PWY69TJKRGmbP6oEJ5g== Date: Wed, 18 Oct 2017 14:20:52 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0567E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0567E1OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] I-D.boucadair-dots-discovery: Russ White Comments X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 14:21:00 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0567E1OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ, all, A new version that takes into account the comments from Russ is available o= nline: URL: https://www.ietf.org/internet-drafts/draft-boucadair-dots-s= erver-discovery-03.txt Status: https://datatracker.ietf.org/doc/draft-boucadair-dots-serve= r-discovery/ Htmlized: https://tools.ietf.org/html/draft-boucadair-dots-server-dis= covery-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-boucadair-dots-= server-discovery-03 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-dots-se= rver-discovery-03 As per the comments from Russ, the new version allow to accommodate deploym= ents that would require supplying a name or a "an IP address + reference id= entifier" or an IP address only. Russ, please double check the new version and feel free to raise any commen= t you may have. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0567E1OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ, all,

 

A new version that takes into account the c= omments from Russ is available online:

 

URL:    =         https://www.ietf.org/internet-drafts/draft-boucadair-dots-se= rver-discovery-03.txt

Status:   &nb= sp;     https://da= tatracker.ietf.org/doc/draft-boucadair-dots-server-discovery/

Htmlized:   &= nbsp;   https://tools.ietf.org/= html/draft-boucadair-dots-server-discovery-03

Htmlized:   &= nbsp;   https://datat= racker.ietf.org/doc/html/draft-boucadair-dots-server-discovery-03

Diff:    = ;       https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-dots-server-discov= ery-03

 

As per the comments from Russ, the new vers= ion allow to accommodate deployments that would require supplying a name or= a “an IP address + reference identifier” or an IP address only.

 

Russ, please double check the new version a= nd feel free to raise any comment you may have.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A0567E1OPEXCLILMA3corp_-- From nobody Thu Oct 19 07:41:53 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35518124B17 for ; Thu, 19 Oct 2017 07:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmMzGtV_HbAM for ; Thu, 19 Oct 2017 07:41:45 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E06612421A for ; Thu, 19 Oct 2017 07:41:45 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id DED471603D2 for ; Thu, 19 Oct 2017 16:41:43 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id C33A94004C for ; Thu, 19 Oct 2017 16:41:43 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0361.001; Thu, 19 Oct 2017 16:41:43 +0200 From: To: "dots@ietf.org" Thread-Topic: Multihoming & DOTS Architecture I-D Thread-Index: AdNI6GEooCAhGxC0R066qYfqRXa+3Q== Date: Thu, 19 Oct 2017 14:41:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05719D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A05719DOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Multihoming & DOTS Architecture I-D X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:41:51 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A05719DOPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The following was suggested during the last IETF meeting (from the minutes,= https://datatracker.ietf.org/meeting/99/materials/minutes-99-dots/): "Chairs: suggest to add the multi-homing contents into existing requirement= s and architecture draft." I already made a text proposal for integrating multi-homing to the requirem= ents I-D. This message focuses on the proposed modifications to the archite= cture draft. Please check the proposal at: https://github.com/dotswg/dots-architecture/pull/19/files Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A05719DOPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The following was suggested during the last IETF =
meeting (from the minutes, https://datatracker.ietf.org/meeting/99/mate=
rials/minutes-99-dots/): 
“Chairs: suggest to add the multi-homing co=
ntents into existing requirements and architecture draft.”=

 
I already made a text proposal for integrating mu=
lti-homing to the requirements I-D. This message focuses on the proposed mo=
difications to the architecture draft. Please check the proposal at: <=
/o:p>
 
https://github.com/dotswg/dots-architecture/pull/19/fi=
les  
 
Cheers,
Med
--_000_787AE7BB302AE849A7480A190F8B93300A05719DOPEXCLILMA3corp_-- From nobody Thu Oct 19 11:00:32 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82BA1321CB for ; Thu, 19 Oct 2017 11:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 EH78N-7BraBo for ; Thu, 19 Oct 2017 11:00:30 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CB4132031 for ; Thu, 19 Oct 2017 11:00:30 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v9JI0SR8037028 for ; Thu, 19 Oct 2017 14:00:28 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu v9JI0SR8037028 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1508436028; bh=u99XuyY/0r5bxr0T3bnKtViWrCvy9YuHMq//W6DDVQ0=; h=From:To:Subject:Date:From; b=oryzQ6FpIFJE//9w4dewBhl426DLkoKRr1Sgoe72cHJpvpRyTXfDTcFq8rLSVo7P5 o9GaJCYqj77kXCF0KL6M6kJhKQXwqBIOlFMA8OL0+oSiN7pF17tJl1L82lolHwi77X ypKw/uKeEMHYQOor2+7AgXf4cUC4bpF+GrQL3fQk= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v9JI0KSN029674 for ; Thu, 19 Oct 2017 14:00:20 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Thu, 19 Oct 2017 14:00:20 -0400 From: Roman Danyliw To: "'dots@ietf.org'" Thread-Topic: Call for IETF 100 (Singapore) agenda items Thread-Index: AdNJA+8w3QQu8SKpQciO/yXwNzK/5g== Date: Thu, 19 Oct 2017 18:00:20 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104FEEAF9@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Call for IETF 100 (Singapore) agenda items X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 18:00:32 -0000 Hello WG! The Singapore (IETF 100) meeting is almost upon us. If you would like time= on the agenda, please contact the chairs. Regards, Roman and Tobias From nobody Fri Oct 20 17:32:54 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FF31345C2; Fri, 20 Oct 2017 17:24:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: Kathleen.Moriarty.ietf@gmail.com, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854547399.20809.5599966721037389190.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:33 -0700 Archived-At: Subject: [Dots] dots - Requested session has been scheduled for IETF 100 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:34 -0000 Dear Roman Danyliw, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dots Session 1 (2:00:00) Tuesday, Afternoon Session I 1330-1530 Room Name: Olivia size: 150 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: DDoS Open Threat Signaling Area Name: Security Area Session Requester: Roman Danyliw Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: mile i2nsf sacm saag Second Priority: opsawg People who must be present: Kathleen Moriarty Roman Danyliw Tobias Gondrom Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Oct 22 12:16:53 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F1113AA20; Sun, 22 Oct 2017 12:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AVrohzDgW2f; Sun, 22 Oct 2017 12:16:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B4E13AA1D; Sun, 22 Oct 2017 12:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2048; q=dns/txt; s=iport; t=1508699809; x=1509909409; h=from:to:subject:message-id:date:mime-version: content-transfer-encoding; bh=uVo2bQbqL6fgNcqZkCjFV9tFzAKVGqbZn5MB0djexhM=; b=bqTEyvj6aprwU5KxpobljTINBr5DOOt32qhzy2pqnsX4NXQaqUUudnX+ UdWl2CN/cVE6O9Qo7DpymPOyZxyeH65WHxhG+X+QtboEoA61/vXZRhdog ibwlHKD5xFjyEJ3tZEDKDXPtI/x+MJcVkXolbTn32AjzwXm3/Tt3du8/Q 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAAAj7uxZ/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbieDeoofjz2QHIUygmWCEQojiVY/GAECAQEBAQEBAWsohUc?= =?us-ascii?q?PAQV2AiYCXwEMCAEBig8NEKsAgieLEwEBAQEBBQEBAQEBHgWBD4IbBIIHgVCBa?= =?us-ascii?q?SmHcIMqgmEFoWaOHIZYi2yHNZV8gTkfOIFbVSUVgy2CWR+CAyQ2AYtCAQEB?= X-IronPort-AV: E=Sophos;i="5.43,418,1503360000"; d="scan'208";a="310927616" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Oct 2017 19:16:48 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v9MJGlNn002375; Sun, 22 Oct 2017 19:16:48 GMT From: Flemming Andreasen To: dots , draft-ietf-dots-requirements@ietf.org Message-ID: <4a26e434-c79f-8b47-28b1-d68c33dd87b3@cisco.com> Date: Sun, 22 Oct 2017 15:17:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Dots] DOTS Requirements review (-06) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 19:16:51 -0000 Greetings I have reviewed the latest version of the DOTS requirements draft (https://www.ietf.org/id/draft-ietf-dots-requirements-06.txt). In general, I think the draft is in good shape with only a few edits required, so I hope we can move to WGLC soon. I have a few comments below (of which the NAT one is the only real substantial one). I have also submitted a pull request with a few nit fixes on GitHub: Section 1.2 - The definition of "DOTS Signal" is slightly inconsistent with the respective "Client Signal" and "Server Signal" definitions. SIG-005: - Not clear that always requiring "number of packets" metrics is meaningful. Consider TCP-based attacks for example. Number of bytes may always be ok - above and beyond that it should probably be extensible and/or attack dependent. - I don't think the requirements document should get into specifying timer values - expontial backoff with some maximum value seems about the right level of detail here. SIG-009: - To be clear, the conflicts only apply within a single administrative domain, right ? For example, if a client tells the same domain to alternately turn on/off mitigation for a given prefix, route flapping may occur. The same concern does not apply if a client tells two different administrative domains to respective turn mitigation on (domain 1) and off (domain 2). If so, can we clarify that (also in lieu of some of the multi-homing comments raised previously) ? SIG-010: - DOTS Client behind NAT. On one hand, it seems reasonable to have this requirement since clients for sure can be behind NATs, and with things like dynamic DNS, they can     certainly be reachable. However, if we do want to allow for this scenario, and in particular for the DOTS client to have a private IP-address (potentially behind multiple NATs), then we have more work to do because it won't do the DOTS server any good to get a mitigation request referring to that private IP-address (or prefix). Thanks -- Flemming From nobody Mon Oct 23 04:17:39 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DE213F3A5 for ; Mon, 23 Oct 2017 04:17:38 -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=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRvdLOk0zlAD for ; Mon, 23 Oct 2017 04:17:36 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 96C6B138103 for ; Mon, 23 Oct 2017 04:17:36 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e6ajd-0004Pu-Ke; Mon, 23 Oct 2017 12:17:33 +0100 From: "Jon Shallow" To: "'Flemming Andreasen'" , References: <4a26e434-c79f-8b47-28b1-d68c33dd87b3@cisco.com> In-Reply-To: <4a26e434-c79f-8b47-28b1-d68c33dd87b3@cisco.com> Date: Mon, 23 Oct 2017 12:17:33 +0100 Message-ID: <06ff01d34bf0$8604eba0$920ec2e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH8wkP0sgU40RdvSB10atHrQInOFqKeM4gg Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Requirements review (-06) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 11:17:38 -0000 Hi Flemming, The way my mind works is to think of a practical situation and see if = things fit. As I read SIG-010, there could be a DOTS client with a management IP = address that is RFC1918 - this client could be monitoring Netflow = information and can request mitigation for the appropriate public IPs = that are being monitored. So SIG-010 is needed for this use case. It is the responsibility of the DOTS server as to whether it accepts a = mitigation request for a particular target ip (or domain etc.) or not. If there is going to be a NAT border where public IPs are mapped into = private IPs (and vice versa), I would then expect there to be a DOTS = gateway between these 2 zones, and it is the responsibility of the DOTS = gateway to do any target-ip mappings. Regards Jon -----Original Message----- From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Flemming Andreasen Sent: 22 October 2017 20:17 To: dots; draft-ietf-dots-requirements@ietf.org Subject: [Dots] DOTS Requirements review (-06) Greetings I have reviewed the latest version of the DOTS requirements draft = (https://www.ietf.org/id/draft-ietf-dots-requirements-06.txt). In = general, I think the draft is in good shape with only a few edits = required, so I hope we can move to WGLC soon. I have a few comments = below (of which the NAT one is the only real substantial one). I have = also submitted a pull request with a few nit fixes on GitHub: Section 1.2 - The definition of "DOTS Signal" is slightly inconsistent with the = respective "Client Signal" and "Server Signal" definitions. SIG-005: - Not clear that always requiring "number of packets" metrics is = meaningful. Consider TCP-based attacks for example. Number of bytes may = always be ok - above and beyond that it should probably be extensible = and/or attack dependent. - I don't think the requirements document should get into specifying = timer values - expontial backoff with some maximum value seems about the = right level of detail here. SIG-009: - To be clear, the conflicts only apply within a single administrative = domain, right ? For example, if a client tells the same domain to = alternately turn on/off mitigation for a given prefix, route flapping = may occur. The same concern does not apply if a client tells two = different administrative domains to respective turn mitigation on = (domain 1) and off (domain 2). If so, can we clarify that (also in lieu = of some of the multi-homing comments raised previously) ? SIG-010: - DOTS Client behind NAT. On one hand, it seems reasonable to have this = requirement since clients for sure can be behind NATs, and with things = like dynamic DNS, they can certainly be reachable. However, if we do = want to allow for this scenario, and in particular for the DOTS client = to have a private IP-address (potentially behind multiple NATs), then we = have more work to do because it won't do the DOTS server any good to get = a mitigation request referring to that private IP-address (or prefix). Thanks -- Flemming _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Mon Oct 23 05:28:11 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C3C138A2C for ; Mon, 23 Oct 2017 05:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ped1XI1mKEEO for ; Mon, 23 Oct 2017 05:28:08 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D8C138347 for ; Mon, 23 Oct 2017 05:28:08 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 045D060E24; Mon, 23 Oct 2017 14:28:07 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id D600A40062; Mon, 23 Oct 2017 14:28:06 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0361.001; Mon, 23 Oct 2017 14:28:06 +0200 From: To: Jon Shallow , 'Flemming Andreasen' , "dots@ietf.org" Thread-Topic: DOTS & NAT (was RE: [Dots] DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94Q== Date: Mon, 23 Oct 2017 12:28:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 12:28:10 -0000 Hi Jon, all,=20 I agree with Flemming that "some more work" is needed. IMHO, this is a typi= cal discussion to include in a dedicated section in the DOTS architecture I= -D. >From a requirement standpoint, we don't need to elaborate how the protocols= will fulfil it. SIG-10 does even a nice job by citing RFC8085 which points= to NAT traversal mechanisms. One could pick his/her favorite protocol from= the list in 8085 to discover the external IP address/prefix, if needed. Ex= ternal IP addresses/prefixes can be IPv4 for a NAT44 or NAT64, but can be I= Pv6 prefixes for enterprises deploying NPTv6, and so on.=20 In some deployments, DOTS clients may be provisioned with the set of intern= al resources, so there is no need for discovery.=20 Also, as Jon mentioned, DOTS gateways can be of help to set the appropriate= IP addresses/prefixes/port numbers in the presence of translators.=20 An open question though would be to discuss if there is a value in having a= feature in the DOTS protocol to inform a DOTS client that a NAT is detecte= d on-path. This can be presented as an information element returned by the = server to the client. This information can be, for example, used by the cli= ent to adjust its HT interval, adjust the internal IP addresses/prefixes to= be protected, etc. Opinions? Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > Envoy=E9=A0: lundi 23 octobre 2017 13:18 > =C0=A0: 'Flemming Andreasen'; dots@ietf.org > Objet=A0: Re: [Dots] DOTS Requirements review (-06) >=20 > Hi Flemming, >=20 > The way my mind works is to think of a practical situation and see if > things fit. >=20 > As I read SIG-010, there could be a DOTS client with a management IP > address that is RFC1918 - this client could be monitoring Netflow > information and can request mitigation for the appropriate public IPs tha= t > are being monitored. So SIG-010 is needed for this use case. >=20 > It is the responsibility of the DOTS server as to whether it accepts a > mitigation request for a particular target ip (or domain etc.) or not. >=20 > If there is going to be a NAT border where public IPs are mapped into > private IPs (and vice versa), I would then expect there to be a DOTS > gateway between these 2 zones, and it is the responsibility of the DOTS > gateway to do any target-ip mappings. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of > Flemming Andreasen > Sent: 22 October 2017 20:17 > To: dots; draft-ietf-dots-requirements@ietf.org > Subject: [Dots] DOTS Requirements review (-06) >=20 > Greetings >=20 > I have reviewed the latest version of the DOTS requirements draft > (https://www.ietf.org/id/draft-ietf-dots-requirements-06.txt). In general= , > I think the draft is in good shape with only a few edits required, so I > hope we can move to WGLC soon. I have a few comments below (of which the > NAT one is the only real substantial one). I have also submitted a pull > request with a few nit fixes on GitHub: >=20 >=20 > Section 1.2 > - The definition of "DOTS Signal" is slightly inconsistent with the > respective "Client Signal" and "Server Signal" definitions. >=20 > SIG-005: > - Not clear that always requiring "number of packets" metrics is > meaningful. Consider TCP-based attacks for example. Number of bytes may > always be ok - above and beyond that it should probably be extensible > and/or attack dependent. > - I don't think the requirements document should get into specifying time= r > values - expontial backoff with some maximum value seems about the right > level of detail here. >=20 > SIG-009: > - To be clear, the conflicts only apply within a single administrative > domain, right ? For example, if a client tells the same domain to > alternately turn on/off mitigation for a given prefix, route flapping may > occur. The same concern does not apply if a client tells two different > administrative domains to respective turn mitigation on (domain 1) and of= f > (domain 2). If so, can we clarify that (also in lieu of some of the multi= - > homing comments raised previously) ? >=20 > SIG-010: > - DOTS Client behind NAT. On one hand, it seems reasonable to have this > requirement since clients for sure can be behind NATs, and with things > like dynamic DNS, they can certainly be reachable. However, if we do > want to allow for this scenario, and in particular for the DOTS client to > have a private IP-address (potentially behind multiple NATs), then we hav= e > more work to do because it won't do the DOTS server any good to get a > mitigation request referring to that private IP-address (or prefix). >=20 >=20 > Thanks >=20 > -- Flemming >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Oct 23 08:28:57 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA65E139432 for ; Mon, 23 Oct 2017 08:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9nJtfWfd3TH for ; Mon, 23 Oct 2017 08:28:53 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DAE139428 for ; Mon, 23 Oct 2017 08:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3612; q=dns/txt; s=iport; t=1508772533; x=1509982133; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=aS+7jex9pLMaMGXZbuXlmz1GjUQ8UugLYEC8jpu0vYo=; b=HLiby/NrSIHCpyo5M8+PWO5e1NlQLEMPb45vf7MCYvmoNZ1bpsa4Y2ND BWGLoX6z+zW02zKrrWGA52IS/Ohi2J1b74D/+3PJoVXYEm6aBXoEbBKQn A9wX1ShOEz2u2wH7+VnNJIv26jm1+pTFneuJ2Ve5OPwt9mtG3W0/wpWki k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAABrCu5Z/4gNJK1aGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbieDeoofj0GBVCZ7lT6CEQoYC4UYAoRUPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUdAQEBAQIBAQEhFTYQBwQLDgMEAQEBAgIjAwICJx8JCAYBDAYCAQGKDwUIE?= =?us-ascii?q?KYigieLHwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CGwSCB4FQgWkpC4JBNYR?= =?us-ascii?q?vgyqCYQWhZpR0ghWJVySHEZV8gTkfOIFbVSUVSYJkglkfggMkNgGLeQEBAQ?= X-IronPort-AV: E=Sophos;i="5.43,423,1503360000"; d="scan'208";a="20326746" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2017 15:28:47 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9NFSk6S003145; Mon, 23 Oct 2017 15:28:47 GMT To: Jon Shallow , dots@ietf.org References: <4a26e434-c79f-8b47-28b1-d68c33dd87b3@cisco.com> <06ff01d34bf0$8604eba0$920ec2e0$@jpshallow.com> From: Flemming Andreasen Message-ID: <972dc5ed-1853-a156-9c86-8c6c8f8aa9cd@cisco.com> Date: Mon, 23 Oct 2017 11:29:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <06ff01d34bf0$8604eba0$920ec2e0$@jpshallow.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Dots] DOTS Requirements review (-06) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 15:28:56 -0000 On 10/23/17 7:17 AM, Jon Shallow wrote: > Hi Flemming, > > The way my mind works is to think of a practical situation and see if things fit. > > As I read SIG-010, there could be a DOTS client with a management IP address that is RFC1918 - this client could be monitoring Netflow information and can request mitigation for the appropriate public IPs that are being monitored. So SIG-010 is needed for this use case. Agreed. What about when the attack target is also using a private IP address ? > > It is the responsibility of the DOTS server as to whether it accepts a mitigation request for a particular target ip (or domain etc.) or not. Fair enough, but if we want the protocol to work for attack targets that have private IP-addresses, then we need to say more about how that is going to work. > > If there is going to be a NAT border where public IPs are mapped into private IPs (and vice versa), I would then expect there to be a DOTS gateway between these 2 zones, and it is the responsibility of the DOTS gateway to do any target-ip mappings. Agree that's an option, but it's not the only. Cheers -- Flemming > Regards > > Jon > > -----Original Message----- > From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Flemming Andreasen > Sent: 22 October 2017 20:17 > To: dots; draft-ietf-dots-requirements@ietf.org > Subject: [Dots] DOTS Requirements review (-06) > > Greetings > > I have reviewed the latest version of the DOTS requirements draft (https://www.ietf.org/id/draft-ietf-dots-requirements-06.txt). In general, I think the draft is in good shape with only a few edits required, so I hope we can move to WGLC soon. I have a few comments below (of which the NAT one is the only real substantial one). I have also submitted a pull request with a few nit fixes on GitHub: > > > Section 1.2 > - The definition of "DOTS Signal" is slightly inconsistent with the respective "Client Signal" and "Server Signal" definitions. > > SIG-005: > - Not clear that always requiring "number of packets" metrics is meaningful. Consider TCP-based attacks for example. Number of bytes may always be ok - above and beyond that it should probably be extensible and/or attack dependent. > - I don't think the requirements document should get into specifying timer values - expontial backoff with some maximum value seems about the right level of detail here. > > SIG-009: > - To be clear, the conflicts only apply within a single administrative domain, right ? For example, if a client tells the same domain to alternately turn on/off mitigation for a given prefix, route flapping may occur. The same concern does not apply if a client tells two different administrative domains to respective turn mitigation on (domain 1) and off (domain 2). If so, can we clarify that (also in lieu of some of the multi-homing comments raised previously) ? > > SIG-010: > - DOTS Client behind NAT. On one hand, it seems reasonable to have this requirement since clients for sure can be behind NATs, and with things like dynamic DNS, they can certainly be reachable. However, if we do want to allow for this scenario, and in particular for the DOTS client to have a private IP-address (potentially behind multiple NATs), then we have more work to do because it won't do the DOTS server any good to get a mitigation request referring to that private IP-address (or prefix). > > > Thanks > > -- Flemming > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > . > From nobody Mon Oct 23 08:35:44 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DF8139428 for ; Mon, 23 Oct 2017 08:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X01k3ClnOT3I for ; Mon, 23 Oct 2017 08:35:31 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1FE1394E2 for ; Mon, 23 Oct 2017 08:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5798; q=dns/txt; s=iport; t=1508772931; x=1509982531; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=GgSnJJVmduPc5C/JHiN2NYylajT53lQFP5MzCjx0Zp4=; b=bf5hZ6QH7xfrc2GcHcPIlQuvn9YX2Cc/Gfj2+js+Lrwe/4rGNrkSz0AM GRuw1OTv+SqfRXnZhrHfQzvtTIrWFYu1IKNpjQgE467W4OY7grQkdyCNA 9kErDh0KYGez27he1cYM7dmXql4CU7xzDd+175ilZsXKuxUkK6bL+dnd9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAAAqC+5Z/4MNJK1aGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzEuZG4ng3qKH49BgVQme5U+ghEKGAuFGAKEVD8YAQIBAQEBAQE?= =?us-ascii?q?BayiFHQEBAQECAQEBIQ8BBTYQBwQLEQEDAQEBAgIjAwICJx8DBggGAQwGAgEBi?= =?us-ascii?q?g8FCBClIYInix8BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPghsEggeBUIFpKQu?= =?us-ascii?q?CQTWEb4MqgmEFoWaIe4t5ghWJVySHEZV8gTkfOIFbVSUVSYJkglkfggMkNgGLe?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.43,423,1503360000"; d="scan'208";a="20330818" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2017 15:35:30 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9NFZTMV018128; Mon, 23 Oct 2017 15:35:29 GMT To: mohamed.boucadair@orange.com, Jon Shallow , "dots@ietf.org" References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Flemming Andreasen Message-ID: <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> Date: Mon, 23 Oct 2017 11:35:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 15:35:35 -0000 On 10/23/17 8:28 AM, mohamed.boucadair@orange.com wrote: > Hi Jon, all, > > I agree with Flemming that "some more work" is needed. IMHO, this is a typical discussion to include in a dedicated section in the DOTS architecture I-D. Agreed. > >From a requirement standpoint, we don't need to elaborate how the protocols will fulfil it. SIG-10 does even a nice job by citing RFC8085 which points to NAT traversal mechanisms. One could pick his/her favorite protocol from the list in 8085 to discover the external IP address/prefix, if needed. External IP addresses/prefixes can be IPv4 for a NAT44 or NAT64, but can be IPv6 prefixes for enterprises deploying NPTv6, and so on. Part of the challenge here is that the attack target and the DOTS client are not necessarily one and the same, which makes it more difficult to determine the public-facing IP-address/port under attack (at least if the DOTS client is going to do it). > In some deployments, DOTS clients may be provisioned with the set of internal resources, so there is no need for discovery. > > Also, as Jon mentioned, DOTS gateways can be of help to set the appropriate IP addresses/prefixes/port numbers in the presence of translators. Agreed - but they still need a way to figure out the private/public mapping for a given attack target. > An open question though would be to discuss if there is a value in having a feature in the DOTS protocol to inform a DOTS client that a NAT is detected on-path. This can be presented as an information element returned by the server to the client. This information can be, for example, used by the client to adjust its HT interval, adjust the internal IP addresses/prefixes to be protected, etc. Opinions? It sounds appealing, but it's very difficult to do this reliably, and it's not just NATs that are an issue here; Firewalls present similar challenges (and they may or may not be NAT'ing individual flows). -- Flemming > Cheers, > Med > >> -----Message d'origine----- >> De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow >> Envoyé : lundi 23 octobre 2017 13:18 >> À : 'Flemming Andreasen'; dots@ietf.org >> Objet : Re: [Dots] DOTS Requirements review (-06) >> >> Hi Flemming, >> >> The way my mind works is to think of a practical situation and see if >> things fit. >> >> As I read SIG-010, there could be a DOTS client with a management IP >> address that is RFC1918 - this client could be monitoring Netflow >> information and can request mitigation for the appropriate public IPs that >> are being monitored. So SIG-010 is needed for this use case. >> >> It is the responsibility of the DOTS server as to whether it accepts a >> mitigation request for a particular target ip (or domain etc.) or not. >> >> If there is going to be a NAT border where public IPs are mapped into >> private IPs (and vice versa), I would then expect there to be a DOTS >> gateway between these 2 zones, and it is the responsibility of the DOTS >> gateway to do any target-ip mappings. >> >> Regards >> >> Jon >> >> -----Original Message----- >> From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of >> Flemming Andreasen >> Sent: 22 October 2017 20:17 >> To: dots; draft-ietf-dots-requirements@ietf.org >> Subject: [Dots] DOTS Requirements review (-06) >> >> Greetings >> >> I have reviewed the latest version of the DOTS requirements draft >> (https://www.ietf.org/id/draft-ietf-dots-requirements-06.txt). In general, >> I think the draft is in good shape with only a few edits required, so I >> hope we can move to WGLC soon. I have a few comments below (of which the >> NAT one is the only real substantial one). I have also submitted a pull >> request with a few nit fixes on GitHub: >> >> >> Section 1.2 >> - The definition of "DOTS Signal" is slightly inconsistent with the >> respective "Client Signal" and "Server Signal" definitions. >> >> SIG-005: >> - Not clear that always requiring "number of packets" metrics is >> meaningful. Consider TCP-based attacks for example. Number of bytes may >> always be ok - above and beyond that it should probably be extensible >> and/or attack dependent. >> - I don't think the requirements document should get into specifying timer >> values - expontial backoff with some maximum value seems about the right >> level of detail here. >> >> SIG-009: >> - To be clear, the conflicts only apply within a single administrative >> domain, right ? For example, if a client tells the same domain to >> alternately turn on/off mitigation for a given prefix, route flapping may >> occur. The same concern does not apply if a client tells two different >> administrative domains to respective turn mitigation on (domain 1) and off >> (domain 2). If so, can we clarify that (also in lieu of some of the multi- >> homing comments raised previously) ? >> >> SIG-010: >> - DOTS Client behind NAT. On one hand, it seems reasonable to have this >> requirement since clients for sure can be behind NATs, and with things >> like dynamic DNS, they can certainly be reachable. However, if we do >> want to allow for this scenario, and in particular for the DOTS client to >> have a private IP-address (potentially behind multiple NATs), then we have >> more work to do because it won't do the DOTS server any good to get a >> mitigation request referring to that private IP-address (or prefix). >> >> >> Thanks >> >> -- Flemming >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > . > From nobody Tue Oct 24 01:50:25 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA6613C2F9 for ; Tue, 24 Oct 2017 01:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FiOMcYsK2ql for ; Tue, 24 Oct 2017 01:50:21 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E498113EDF4 for ; Tue, 24 Oct 2017 01:50:20 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 61010A0FF2; Tue, 24 Oct 2017 10:50:19 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 3B65D1C007E; Tue, 24 Oct 2017 10:50:19 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0361.001; Tue, 24 Oct 2017 10:50:18 +0200 From: To: Flemming Andreasen , Jon Shallow , "dots@ietf.org" Thread-Topic: DOTS & NAT (was RE: [Dots] DOTS Requirements review (-06)) Thread-Index: AQHTTBSRjGcTRhzKwEyCZ6P3u1sMhqLyqKoQ Date: Tue, 24 Oct 2017 08:50:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> In-Reply-To: <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 08:50:23 -0000 SGkgRmxlbW1pbmcsIGFsbCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQN Cg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRmxlbW1pbmcgQW5kcmVh c2VuIFttYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tXQ0KPiBFbnZvecOpwqA6IGx1bmRpIDIzIG9j dG9icmUgMjAxNyAxNzozNg0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBKb24g U2hhbGxvdzsgZG90c0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogRE9UUyAmIE5BVCAod2FzIFJF OiBbRG90c10gRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKQ0KPiANCj4gDQo+IA0KPiBP biAxMC8yMy8xNyA4OjI4IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0K PiA+IEhpIEpvbiwgYWxsLA0KPiA+DQo+ID4gSSBhZ3JlZSB3aXRoIEZsZW1taW5nIHRoYXQgInNv bWUgbW9yZSB3b3JrIiBpcyBuZWVkZWQuIElNSE8sIHRoaXMgaXMgYQ0KPiB0eXBpY2FsIGRpc2N1 c3Npb24gdG8gaW5jbHVkZSBpbiBhIGRlZGljYXRlZCBzZWN0aW9uIGluIHRoZSBET1RTDQo+IGFy Y2hpdGVjdHVyZSBJLUQuDQo+IEFncmVlZC4NCj4gPiA+RnJvbSBhIHJlcXVpcmVtZW50IHN0YW5k cG9pbnQsIHdlIGRvbid0IG5lZWQgdG8gZWxhYm9yYXRlIGhvdyB0aGUNCj4gcHJvdG9jb2xzIHdp bGwgZnVsZmlsIGl0LiBTSUctMTAgZG9lcyBldmVuIGEgbmljZSBqb2IgYnkgY2l0aW5nIFJGQzgw ODUNCj4gd2hpY2ggcG9pbnRzIHRvIE5BVCB0cmF2ZXJzYWwgbWVjaGFuaXNtcy4gT25lIGNvdWxk IHBpY2sgaGlzL2hlciBmYXZvcml0ZQ0KPiBwcm90b2NvbCBmcm9tIHRoZSBsaXN0IGluIDgwODUg dG8gZGlzY292ZXIgdGhlIGV4dGVybmFsIElQIGFkZHJlc3MvcHJlZml4LA0KPiBpZiBuZWVkZWQu IEV4dGVybmFsIElQIGFkZHJlc3Nlcy9wcmVmaXhlcyBjYW4gYmUgSVB2NCBmb3IgYSBOQVQ0NCBv cg0KPiBOQVQ2NCwgYnV0IGNhbiBiZSBJUHY2IHByZWZpeGVzIGZvciBlbnRlcnByaXNlcyBkZXBs b3lpbmcgTlBUdjYsIGFuZCBzbw0KPiBvbi4NCj4gUGFydCBvZiB0aGUgY2hhbGxlbmdlIGhlcmUg aXMgdGhhdCB0aGUgYXR0YWNrIHRhcmdldCBhbmQgdGhlIERPVFMgY2xpZW50DQo+IGFyZSBub3Qg bmVjZXNzYXJpbHkgb25lIGFuZCB0aGUgc2FtZSwgd2hpY2ggbWFrZXMgaXQgbW9yZSBkaWZmaWN1 bHQgdG8NCj4gZGV0ZXJtaW5lIHRoZSBwdWJsaWMtZmFjaW5nIElQLWFkZHJlc3MvcG9ydCB1bmRl ciBhdHRhY2sgKGF0IGxlYXN0IGlmDQo+IHRoZSBET1RTIGNsaWVudCBpcyBnb2luZyB0byBkbyBp dCkuDQoNCltNZWRdIFRoaXMgaXMgZXhhY3RseSB0aGUga2luZCBvZiB0aGUgZGlzY3Vzc2lvbiB0 byBoYXZlLiBUaGFua3MuIA0KDQpXaXRoIG9yIHdpdGhvdXQgTkFULCBET1RTIGNsaWVudHMgYXJl IGFzc3VtZWQgdG8gYmUgZmVkIHdpdGggdGhlIGludGVybmFsIHRhcmdldChzKS4gVGhpcyBjYW4g YmUgYWNoaWV2ZWQgYnkgcHJvdmlzaW9uaW5nIChsaWtlbHkpIG9yIGJ5IGRpc2NvdmVyeSBtZWFu cyAoZS5nLiwgcmVzaWRlbnRpYWwgb3Igc21hbGwgZW50ZXJwcmlzZSBuZXR3b3JrcykuIA0KDQpD YW4gd2UgYXNzdW1lIHRoYXQgdGhlIGRpc2NvdmVyeSBvZiB0aGUgZXh0ZXJuYWwgSVAgYWRkcmVz cy9wcmVmaXgvLi4gaXMgZG9uZSBieSBhIERPVFMgY2xpZW50IG9ubHkgaWYgaXQgaXMgZXhwbGlj aXRseSBpbnN0cnVjdGVkIHRvIGRvIHNvPw0KDQoNCj4gPiBJbiBzb21lIGRlcGxveW1lbnRzLCBE T1RTIGNsaWVudHMgbWF5IGJlIHByb3Zpc2lvbmVkIHdpdGggdGhlIHNldCBvZg0KPiBpbnRlcm5h bCByZXNvdXJjZXMsIHNvIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGRpc2NvdmVyeS4NCj4gPg0KPiA+ IEFsc28sIGFzIEpvbiBtZW50aW9uZWQsIERPVFMgZ2F0ZXdheXMgY2FuIGJlIG9mIGhlbHAgdG8g c2V0IHRoZQ0KPiBhcHByb3ByaWF0ZSBJUCBhZGRyZXNzZXMvcHJlZml4ZXMvcG9ydCBudW1iZXJz IGluIHRoZSBwcmVzZW5jZSBvZg0KPiB0cmFuc2xhdG9ycy4NCj4gQWdyZWVkIC0gYnV0IHRoZXkg c3RpbGwgbmVlZCBhIHdheSB0byBmaWd1cmUgb3V0IHRoZSBwcml2YXRlL3B1YmxpYw0KPiBtYXBw aW5nIGZvciBhIGdpdmVuIGF0dGFjayB0YXJnZXQuDQoNCltNZWRdIEJlY2F1c2UgYSBERG9TIGF0 dGFjayBpcyBvYnNlcnZlZCBmcm9tIHRoZSBpbnRlcm5hbCBuZXR3b3JrLCBtYXBwaW5nKHMpIGFy ZSBuZWNlc3NhcmlseSBtYWludGFpbmVkIGJ5IHRoZSBvbi1wYXRoIHRyYW5zbGF0b3IocykuIE90 aGVyd2lzZSwgdGhlIGluY29taW5nIGF0dGFjayB0cmFmZmljIGNvdWxkbid0IGJlIGZvcndhcmRl ZCB0byBpbnRlcm5hbCBob3N0cy4gDQpUaGlzIG1vZGVsIGFzc3VtZXMgdGhhdCB0aGUgZ2F0ZXdh eSBpcyBjb2xsb2NhdGVkIHdpdGggdGhlIE5BVC4gU28sIHRoZSBnYXRld2F5IGNhbiByZXBsYWNl IHRoZSBpbnRlcm5hbCBJUCBhZGRyZXNzL3ByZWZpeCB3aXRoIHRoZSBvbmUgcmV0cmlldmVzIGZy b20gdGhlIE5BVCBtYXBwaW5nIHRhYmxlLiANCg0KRG8geW91IHNlZSBhbnkgaXNzdWUgd2l0aCB0 aGlzIHNjaGVtZT8NCg0KPiA+IEFuIG9wZW4gcXVlc3Rpb24gdGhvdWdoIHdvdWxkIGJlIHRvIGRp c2N1c3MgaWYgdGhlcmUgaXMgYSB2YWx1ZSBpbg0KPiBoYXZpbmcgYSBmZWF0dXJlIGluIHRoZSBE T1RTIHByb3RvY29sIHRvIGluZm9ybSBhIERPVFMgY2xpZW50IHRoYXQgYSBOQVQNCj4gaXMgZGV0 ZWN0ZWQgb24tcGF0aC4gVGhpcyBjYW4gYmUgcHJlc2VudGVkIGFzIGFuIGluZm9ybWF0aW9uIGVs ZW1lbnQNCj4gcmV0dXJuZWQgYnkgdGhlIHNlcnZlciB0byB0aGUgY2xpZW50LiBUaGlzIGluZm9y bWF0aW9uIGNhbiBiZSwgZm9yDQo+IGV4YW1wbGUsIHVzZWQgYnkgdGhlIGNsaWVudCB0byBhZGp1 c3QgaXRzIEhUIGludGVydmFsLCBhZGp1c3QgdGhlIGludGVybmFsDQo+IElQIGFkZHJlc3Nlcy9w cmVmaXhlcyB0byBiZSBwcm90ZWN0ZWQsIGV0Yy4gT3BpbmlvbnM/DQo+IEl0IHNvdW5kcyBhcHBl YWxpbmcsIGJ1dCBpdCdzIHZlcnkgZGlmZmljdWx0IHRvIGRvIHRoaXMgcmVsaWFibHksIGFuZA0K PiBpdCdzIG5vdCBqdXN0IE5BVHMgdGhhdCBhcmUgYW4gaXNzdWUgaGVyZTsgRmlyZXdhbGxzIHBy ZXNlbnQgc2ltaWxhcg0KPiBjaGFsbGVuZ2VzIChhbmQgdGhleSBtYXkgb3IgbWF5IG5vdCBiZSBO QVQnaW5nIGluZGl2aWR1YWwgZmxvd3MpLg0KPiANCg0KW01lZF0gSSBmdWxseSBhZ3JlZSB0aGF0 IGZpcmV3YWxscyBkZXRlY3QgaXMgbW9yZSBjb21wbGV4LiBMZXQncyBwdXQgaXQgYXNpZGUgYW5k IGZvY3VzIG9uIHRoZSBOQVQgY2FzZS4gDQoNCldlIGNhbiBjb25zaWRlciBtYW55IGFwcHJvYWNo ZXMgdG8gZGV0ZWN0IGEgTkFULCBlLmcuLCANCg0KKDEpIFRoZSBET1RTIGNsaWVudCBpbnNlcnRz IGluIHRoZSBjb3JlIG1lc3NhZ2UgdGhlIElQIGFkZHJlc3MvcG9ydCBpdCB1c2VzIHRvIHNlbmQg dGhlIHJlcXVlc3QgdG8gdGhlIERPVFMgc2VydmVyLiBVcG9uIHJlY2VpcHQgb2YgdGhlIHJlcXVl c3QgYnkgdGhlIERPVFMgc2VydmVyLCBpdCBjaGVja3MgaWYgdGhlIGVuY2xvc2VkIElQIGFkZHJl c3MvcG9ydCBtYXRjaCB0aGUgc291cmNlIElQIGFkZHJlc3MvcG9ydCBvZiB0aGUgcmVjZWl2ZWQg cGFja2V0LiBJZiB5ZXMsIHRoZSBzZXJ2ZXIgc2V0cyBpbiB0aGUgcmVzcG9uc2UgYSBkZWRpY2F0 ZWQgcGFyYW1ldGVyIHRvIGluZGljYXRlIHRoYXQgYSB0cmFuc2xhdG9yIGlzIGRldGVjdGVkIG9u LXBhdGguDQoNCigyKSBUaGUgRE9UUyBzZXJ2ZXIgaW5zZXJ0cyBzeXN0ZW1hdGljYWxseSB0aGUg c291cmNlIElQIGFkZHJlc3MvcG9ydCBpbiBhIHJlc3BvbnNlIHRvIGEgbWVzc2FnZSBmcm9tIGEg RE9UUyBjbGllbnQuIFVwb24gcmVjZWlwdCBvZiB0aGF0IHJlc3BvbnNlLCB0aGUgRE9UUyBjbGll bnQgY29tcGFyZXMgdGhlIGVuY2xvc2VkIGFkZHJlc3MvcG9ydCB3aXRoIHRoZSBvbmVzIGl0IHVz ZWQgdG8gc2VuZCB0aGUgcmVxdWVzdCB0byBkZXRlY3QgYW55IG1pc21hdGNoLiANCg0KDQo+IC0t IEZsZW1taW5nDQo+IA0KPiANCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+IERlwqA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSm9uIFNoYWxsb3cNCj4gPj4gRW52b3nDqcKgOiBs dW5kaSAyMyBvY3RvYnJlIDIwMTcgMTM6MTgNCj4gPj4gw4DCoDogJ0ZsZW1taW5nIEFuZHJlYXNl bic7IGRvdHNAaWV0Zi5vcmcNCj4gPj4gT2JqZXTCoDogUmU6IFtEb3RzXSBET1RTIFJlcXVpcmVt ZW50cyByZXZpZXcgKC0wNikNCj4gPj4NCj4gPj4gSGkgRmxlbW1pbmcsDQo+ID4+DQo+ID4+IFRo ZSB3YXkgbXkgbWluZCB3b3JrcyBpcyB0byB0aGluayBvZiBhIHByYWN0aWNhbCBzaXR1YXRpb24g YW5kIHNlZSBpZg0KPiA+PiB0aGluZ3MgZml0Lg0KPiA+Pg0KPiA+PiBBcyBJIHJlYWQgU0lHLTAx MCwgdGhlcmUgY291bGQgYmUgYSBET1RTIGNsaWVudCB3aXRoIGEgbWFuYWdlbWVudCBJUA0KPiA+ PiBhZGRyZXNzIHRoYXQgaXMgUkZDMTkxOCAtIHRoaXMgY2xpZW50IGNvdWxkIGJlIG1vbml0b3Jp bmcgTmV0Zmxvdw0KPiA+PiBpbmZvcm1hdGlvbiBhbmQgY2FuIHJlcXVlc3QgbWl0aWdhdGlvbiBm b3IgdGhlIGFwcHJvcHJpYXRlIHB1YmxpYyBJUHMNCj4gdGhhdA0KPiA+PiBhcmUgYmVpbmcgbW9u aXRvcmVkLiAgU28gU0lHLTAxMCBpcyBuZWVkZWQgZm9yIHRoaXMgdXNlIGNhc2UuDQo+ID4+DQo+ ID4+IEl0IGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgRE9UUyBzZXJ2ZXIgYXMgdG8gd2hl dGhlciBpdCBhY2NlcHRzIGENCj4gPj4gbWl0aWdhdGlvbiByZXF1ZXN0IGZvciBhIHBhcnRpY3Vs YXIgdGFyZ2V0IGlwIChvciBkb21haW4gZXRjLikgb3Igbm90Lg0KPiA+Pg0KPiA+PiBJZiB0aGVy ZSBpcyBnb2luZyB0byBiZSBhIE5BVCBib3JkZXIgd2hlcmUgcHVibGljIElQcyBhcmUgbWFwcGVk IGludG8NCj4gPj4gcHJpdmF0ZSBJUHMgKGFuZCB2aWNlIHZlcnNhKSwgSSB3b3VsZCB0aGVuIGV4 cGVjdCB0aGVyZSB0byBiZSBhIERPVFMNCj4gPj4gZ2F0ZXdheSBiZXR3ZWVuIHRoZXNlIDIgem9u ZXMsIGFuZCBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIERPVFMNCj4gPj4gZ2F0ZXdh eSB0byBkbyBhbnkgdGFyZ2V0LWlwIG1hcHBpbmdzLg0KPiA+Pg0KPiA+PiBSZWdhcmRzDQo+ID4+ DQo+ID4+IEpvbg0KPiA+Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBG cm9tOiBEb3RzIFttYWlsdG86aWV0Zi1zdXBqcHMtZG90cy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YNCj4gPj4gRmxlbW1pbmcgQW5kcmVhc2VuDQo+ID4+IFNlbnQ6IDIyIE9jdG9iZXIg MjAxNyAyMDoxNw0KPiA+PiBUbzogZG90czsgZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50c0Bp ZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBbRG90c10gRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgt MDYpDQo+ID4+DQo+ID4+IEdyZWV0aW5ncw0KPiA+Pg0KPiA+PiBJIGhhdmUgcmV2aWV3ZWQgdGhl IGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBET1RTIHJlcXVpcmVtZW50cyBkcmFmdA0KPiA+PiAoaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0wNi50eHQp LiBJbg0KPiBnZW5lcmFsLA0KPiA+PiBJIHRoaW5rIHRoZSBkcmFmdCBpcyBpbiBnb29kIHNoYXBl IHdpdGggb25seSBhIGZldyBlZGl0cyByZXF1aXJlZCwgc28gSQ0KPiA+PiBob3BlIHdlIGNhbiBt b3ZlIHRvIFdHTEMgc29vbi4gSSBoYXZlIGEgZmV3IGNvbW1lbnRzIGJlbG93IChvZiB3aGljaA0K PiB0aGUNCj4gPj4gTkFUIG9uZSBpcyB0aGUgb25seSByZWFsIHN1YnN0YW50aWFsIG9uZSkuIEkg aGF2ZSBhbHNvIHN1Ym1pdHRlZCBhIHB1bGwNCj4gPj4gcmVxdWVzdCB3aXRoIGEgZmV3IG5pdCBm aXhlcyBvbiBHaXRIdWI6DQo+ID4+DQo+ID4+DQo+ID4+IFNlY3Rpb24gMS4yDQo+ID4+IC0gVGhl IGRlZmluaXRpb24gb2YgIkRPVFMgU2lnbmFsIiBpcyBzbGlnaHRseSBpbmNvbnNpc3RlbnQgd2l0 aCB0aGUNCj4gPj4gcmVzcGVjdGl2ZSAiQ2xpZW50IFNpZ25hbCIgYW5kICJTZXJ2ZXIgU2lnbmFs IiBkZWZpbml0aW9ucy4NCj4gPj4NCj4gPj4gU0lHLTAwNToNCj4gPj4gLSBOb3QgY2xlYXIgdGhh dCBhbHdheXMgcmVxdWlyaW5nICJudW1iZXIgb2YgcGFja2V0cyIgbWV0cmljcyBpcw0KPiA+PiBt ZWFuaW5nZnVsLiBDb25zaWRlciBUQ1AtYmFzZWQgYXR0YWNrcyBmb3IgZXhhbXBsZS4gTnVtYmVy IG9mIGJ5dGVzIG1heQ0KPiA+PiBhbHdheXMgYmUgb2sgLSBhYm92ZSBhbmQgYmV5b25kIHRoYXQg aXQgc2hvdWxkIHByb2JhYmx5IGJlIGV4dGVuc2libGUNCj4gPj4gYW5kL29yIGF0dGFjayBkZXBl bmRlbnQuDQo+ID4+IC0gSSBkb24ndCB0aGluayB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50IHNo b3VsZCBnZXQgaW50byBzcGVjaWZ5aW5nDQo+IHRpbWVyDQo+ID4+IHZhbHVlcyAtIGV4cG9udGlh bCBiYWNrb2ZmIHdpdGggc29tZSBtYXhpbXVtIHZhbHVlIHNlZW1zIGFib3V0IHRoZQ0KPiByaWdo dA0KPiA+PiBsZXZlbCBvZiBkZXRhaWwgaGVyZS4NCj4gPj4NCj4gPj4gU0lHLTAwOToNCj4gPj4g LSBUbyBiZSBjbGVhciwgdGhlIGNvbmZsaWN0cyBvbmx5IGFwcGx5IHdpdGhpbiBhIHNpbmdsZSBh ZG1pbmlzdHJhdGl2ZQ0KPiA+PiBkb21haW4sIHJpZ2h0ID8gRm9yIGV4YW1wbGUsIGlmIGEgY2xp ZW50IHRlbGxzIHRoZSBzYW1lIGRvbWFpbiB0bw0KPiA+PiBhbHRlcm5hdGVseSB0dXJuIG9uL29m ZiBtaXRpZ2F0aW9uIGZvciBhIGdpdmVuIHByZWZpeCwgcm91dGUgZmxhcHBpbmcNCj4gbWF5DQo+ ID4+IG9jY3VyLiBUaGUgc2FtZSBjb25jZXJuIGRvZXMgbm90IGFwcGx5IGlmIGEgY2xpZW50IHRl bGxzIHR3byBkaWZmZXJlbnQNCj4gPj4gYWRtaW5pc3RyYXRpdmUgZG9tYWlucyB0byByZXNwZWN0 aXZlIHR1cm4gbWl0aWdhdGlvbiBvbiAoZG9tYWluIDEpIGFuZA0KPiBvZmYNCj4gPj4gKGRvbWFp biAyKS4gSWYgc28sIGNhbiB3ZSBjbGFyaWZ5IHRoYXQgKGFsc28gaW4gbGlldSBvZiBzb21lIG9m IHRoZQ0KPiBtdWx0aS0NCj4gPj4gaG9taW5nIGNvbW1lbnRzIHJhaXNlZCBwcmV2aW91c2x5KSA/ DQo+ID4+DQo+ID4+IFNJRy0wMTA6DQo+ID4+IC0gRE9UUyBDbGllbnQgYmVoaW5kIE5BVC4gT24g b25lIGhhbmQsIGl0IHNlZW1zIHJlYXNvbmFibGUgdG8gaGF2ZSB0aGlzDQo+ID4+IHJlcXVpcmVt ZW50IHNpbmNlIGNsaWVudHMgZm9yIHN1cmUgY2FuIGJlIGJlaGluZCBOQVRzLCBhbmQgd2l0aCB0 aGluZ3MNCj4gPj4gbGlrZSBkeW5hbWljIEROUywgdGhleSBjYW4gICAgIGNlcnRhaW5seSBiZSBy ZWFjaGFibGUuIEhvd2V2ZXIsIGlmIHdlDQo+IGRvDQo+ID4+IHdhbnQgdG8gYWxsb3cgZm9yIHRo aXMgc2NlbmFyaW8sIGFuZCBpbiBwYXJ0aWN1bGFyIGZvciB0aGUgRE9UUyBjbGllbnQNCj4gdG8N Cj4gPj4gaGF2ZSBhIHByaXZhdGUgSVAtYWRkcmVzcyAocG90ZW50aWFsbHkgYmVoaW5kIG11bHRp cGxlIE5BVHMpLCB0aGVuIHdlDQo+IGhhdmUNCj4gPj4gbW9yZSB3b3JrIHRvIGRvIGJlY2F1c2Ug aXQgd29uJ3QgZG8gdGhlIERPVFMgc2VydmVyIGFueSBnb29kIHRvIGdldCBhDQo+ID4+IG1pdGln YXRpb24gcmVxdWVzdCByZWZlcnJpbmcgdG8gdGhhdCBwcml2YXRlIElQLWFkZHJlc3MgKG9yIHBy ZWZpeCkuDQo+ID4+DQo+ID4+DQo+ID4+IFRoYW5rcw0KPiA+Pg0KPiA+PiAtLSBGbGVtbWluZw0K PiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+PiBEb3RzQGlldGYub3JnDQo+ID4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+Pg0KPiA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBEb3RzIG1haWxp bmcgbGlzdA0KPiA+PiBEb3RzQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG90cw0KPiA+IC4NCj4gPg0KDQo= From nobody Tue Oct 24 14:54:05 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FE513A8A1; Tue, 24 Oct 2017 14:53:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150888203847.25249.11590483174597116578@ietfa.amsl.com> Date: Tue, 24 Oct 2017 14:53:58 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 21:53:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Use cases for DDoS Open Threat Signaling Authors : Roland Dobbins Daniel Migault Stefan Fouant Robert Moskowitz Nik Teague Liang Xia Kaname Nishizuka Filename : draft-ietf-dots-use-cases-08.txt Pages : 22 Date : 2017-10-24 Abstract: The DDoS Open Threat Signaling (DOTS) effort is intended to provide a protocol that facilitates interoperability between multivendor solutions/services. This document presents use cases to evaluate the interactions expected between the DOTS components as well as DOTS messaging exchanges. The purpose of describing use cases is to identify the interacting DOTS components, how they collaborate and what are the types of information to be exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-use-cases-08 https://datatracker.ietf.org/doc/html/draft-ietf-dots-use-cases-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 24 15:00:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA34013F895 for ; Tue, 24 Oct 2017 15:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 itAB80eHP11d for ; Tue, 24 Oct 2017 15:00:03 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0134.outbound.protection.outlook.com [104.47.37.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DFC013F884 for ; Tue, 24 Oct 2017 15:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oWvPrYci2zYp6tDu7rFw4x2NEneYfbLGd1Zi/m9UIBw=; b=MueVI7gBQ5ofaS1iBQyn7wg/jL8CsFZrlyAZ3hNqCiVHHb2hsI0COQcMEQrfuh04f/fQXWzokljmjcfTOw6aYLYrguo+m8oLemOoffJ6Drlmm4LgnLN0uQ5AaZ0dhfLelB/elSFFjcjN+bL2mq5yFMUJMMRNlMNuXLwMgZ0tITQ= Received: from [172.19.254.109] (184.82.228.131) by DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 24 Oct 2017 22:00:00 +0000 From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 25 Oct 2017 04:59:47 +0700 Message-ID: <97BBC935-0E42-47B4-8678-02354E7454B7@arbor.net> In-Reply-To: <150888203847.25249.11590483174597116578@ietfa.amsl.com> References: <150888203847.25249.11590483174597116578@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) X-Originating-IP: [184.82.228.131] X-ClientProxiedBy: SG2PR0601CA0015.apcprd06.prod.outlook.com (2603:1096:3::25) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fc4b9bda-d1e7-491e-5d2c-08d51b2a938e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603233); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:5pHo+PqM4VSL9G6/UviN3us7w9a45i8/bM2WysTfePVmX6B0cfWYPUqCz7GoExZxuLC5IjdtLPAkcsX3XAp8VhEj2WY4lqIE/UX7fgNitxKFQ6e6C0tENIpC+lNlCbrRMI3z7eMtZ5gqvwusUzOG3MZ7pd8vjEWyJMmGUEgLDu4dlbdB9J+IjCopWbjythYh83oo612mqnnsLVMKLLe8OuSiSbkeq4T+Ag8F7tCgS3/c7rAD7tnao60iDesh3FUZ; 25:nGyX7LwN1b7wljp2c0LKsDCLxDghy8+Wd5YHsXSSY+G9XmtjdBb0P2bin9tR6aCeFnum3KcHwECQqOnxzz3bLpY8zy/4I2hgZdBNHTeo+oO3Yqk7MH+L3UceQ8o4N4ZLFHCnWezkkQmRdFpz16YUxPnGoG4W99ZAEml1sl0UaAqkBPSdcgxTLDTBJjiqROq9lqZlmMVF+SDsKgymgheprq7kG06NHazI+ZDfvn1Zvihpb8o/AwKfXQTxEXV4ZwjPVCBG35rEIjzr/hYB6qs+uqCO7XeCEIFDezh+y1IjZ86EQisbSkAQYM0OsD0tK3t4MEvQ/B6OvdUtDr7S7DHGfqyDqrltaIANe5r8Fjhj8mU=; 31:ixaq+86sc1MXTa7L6Dzdhn7wbKuRw+x5ia7ez1fupJLDZZqDMto/nkWINKc2oQrJO2aKOI/ZKg1whxYHfD2yilWrSpf1py/h2sEom4iYM4xJXM6C0x5dVCX6RIXcoxC12y6U+kwi7FKlt40L+5EJ6Gl/sJyJfAz+JRMY7LFRCC/sh5mXLR6sgUf9q+JIEBpyl8hCe6WhHPQZCpPbTqR1CgGDQh+plCRc4Y5l7uPOxYk= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:sgHOyspSy/LnMz2XeSRNQ/VOFPTxkTj/g6TMlnEzUGwOOqfrvEKuigpuXqtencrCZQzp2ywlw0979YEMTXrK+bHGDQM9sT/xIlGnZ4hLGAq9Q0WDIKdKfQYfX0ACB7kc8PUge7iYoHBijdgDzUZXB3bzxsJUUdNui+3BISzlrN2NpMrU/C1EYs55RUnlzH/seRZs/B/YKEpVFaDXduEJVyd75Aj6tJtFP7dFVcJ9y/KuXpXElLkRwy3lJFK2zR80qaY+QgdfH5jKtQ9DHO33t7/K0o5pFOuoXGvMGP1HMvdDtL3ePpjunNFuClwINIKlgx0D5xSdZXrqjo3NuUtEB9uKx1n36AQAyD+6MxbQV45n4bO8udmR+XhLbr5UMSjH80dZcMnOSYurPi8ajUO3SS8MP6797PquwDccRUVXFBFN5kdYEbW0cQbA9uO/jMVRUoHxeQxwTDSCK4xKDMkpzROfkveROTExr2Wf83u5Rci8yGEqyO58jlppIQs1of/d; 4:fsMN2nAyXWl4MBhXWyTLEKHq6ESQ5+OBrkC7DrCUNej8qT6eh/g6F4jFqbnOnsb8RCXGobWN/LN+dw0U/PRlBvL3bWjIRTdOo67Y8ftY1sPwTmCP+GKuGeBz/44hyogDVTw4ANbBjQ33UMhOL4p7zl8J8Yg+3UmubJXMBWpQPty8lAO927sLxYBXwjdPpPVvAGwtiqQdantCIkf6lKeztlH/MUFWtqPOgwq3U7mBwcue2PlxbibHFtZX1RJ3E6aq1w7FZUcSLb57b7B4f8WlL3dIA9wAFN7mA1ERxc/rRGI= X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3231020)(10201501046)(3002001)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; X-Forefront-PRVS: 047001DADA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(346002)(376002)(189002)(199003)(24454002)(6666003)(97736004)(86362001)(2361001)(2351001)(105586002)(478600001)(106356001)(68736007)(76176999)(5003940100001)(50986999)(101416001)(50466002)(6486002)(53546010)(33656002)(77096006)(50226002)(36756003)(6116002)(3846002)(230783001)(189998001)(25786009)(5660300001)(316002)(16576012)(6916009)(2950100002)(229853002)(83716003)(16526018)(16586007)(7736002)(66066001)(8676002)(81156014)(47776003)(305945005)(53936002)(8936002)(81166006)(82746002)(2906002)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.19.254.109]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 23:Ifk3PicsHToO/HM47CmlTEZr4K3+ha7qDcIh7Ow?= =?us-ascii?Q?3otulqeojqtLR3e+MUAS7s1mCWxYrnQiR47pqaYussvXCbvRVhl5uP56miFK?= =?us-ascii?Q?JikWgdM1dfW3L9PBcNf9drQmaTqDwkHLlr8cRY74zJve4iRXHxZeQ5IhoL2W?= =?us-ascii?Q?WFFVLbIeJQ9niF7J024P+pjzjOyfp6pSU/sXuZkSs9x/SO7IuSO7P5Q/YV2x?= =?us-ascii?Q?aeLEy92fmVMMNBwMYK+/BMmEp0Rzt1altJk89RW+1UVyTWXYdBxTmdX+jKyi?= =?us-ascii?Q?4eKdbhPRis+P1pldI47JXi1EsAlJgH3zTR2SyFRAjdSxlmT9PUXiv8+lgVeP?= =?us-ascii?Q?s2hOtjGjRcgTxd2oCh6ngxjCTKo9JDqEYxqS9C8JTuImtHVW5+CjsllRgJqa?= =?us-ascii?Q?w0Q4eX6RpuqCMcAvY1gOiyJtdW9dkrSu9065UR99XbD9kCkaxJoojrNTq6md?= =?us-ascii?Q?yGUq1PlU9CTchuuYeeKVBH84fwXw2OfGzEb7+OIiC1K69VO4TzL7GCCIwCWB?= =?us-ascii?Q?DOP7hdxiLg/T5DLmcpPRwhabLh8g2tX5QV+pzwmFsPmEGFgvzu3+HNPKAHbk?= =?us-ascii?Q?zDeyZ/xFIZ8FDNl2PcyeNMZeAVqxmQlE/wlE/W2Wh0+EREXyXlyH6lSU2SKK?= =?us-ascii?Q?AWGFBps0mJZZbJ2L+xpr2/wfNkQBOolkG63zOjvills2OsLhf/G2xGWy89Se?= =?us-ascii?Q?NCiTte11L28gMNn251P3h4E2RkSoaglXeeVWpBth+UkEpyOgz1q+7NGCy6Dt?= =?us-ascii?Q?i0FruLCUolSHVALL3hCBGn3ww0SfABF3/ZElcfgSkKQcv/asQQYe8ooLVU5G?= =?us-ascii?Q?HPFALIFod58YBNMW5+DK+aOR+0xBKkI9qcpUcaOMTk+KrrDXll59btC+5/jm?= =?us-ascii?Q?qXlSwVJOC78Ci0L1LwXIenlpT8U7Zln6vrD+W+F93gowBWykkSJE4Zn7oH5K?= =?us-ascii?Q?qeJP6nj9XZ3A4usGpzfXLiIgkkgzklbWue1rJCZqEDRKXrO+LgdbsnIATIBt?= =?us-ascii?Q?O43xFY0su5GQlXGB7QYqCVyuca79YyneY5eCFxIoNkYZ1tfqBvg8dW8jyp5X?= =?us-ascii?Q?hgVhdhdWUXLg3UjdnPtLN36A9TYeQo/ytuCeta4jsAmbShF1KNPldLOHhbJ7?= =?us-ascii?Q?wQRVIKciFKN+P00h7lp6r8RRw33Du/wjFzhTMUvM6qavqq52NvlbfgTR40hj?= =?us-ascii?Q?lV3vcp4RpxynwxImZBsoY48/9boid1y8xghKSb/gezgadjiuynn5F6gEG9Q?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 6:xNs+mjelpvXvw0VeddchjQIEVhsy4K+z49J73NoDzsshJOVwq8xL8t19IApVOhDRiUwWH7kdPQQbP7zgNSS6iVfyTm0gKc7gq9aZjMGAHy4iTt5UBGDk/4QWDIheliLJuYyfRNPGAWHXx29ymi7YJiJawQ3YDqj90XGe+pDg3RZv64g/78ClRgoErT2xAGzuetToT6J8YKBrBdOdHNQpKtc2e3VceH6Z1XxWT2OqKZtHWnGcrAK7ccNUv+Qu3md6aLdaZtPuE08b+fogMa+Glf3Fey1Z5JRgVbdaxBRgUyKN80JJHQk5UjwzwEbYmcziHoVbFgEDp8d4kkb36iNQ5A==; 5:yh5SKc0PubSNhJIZEC19c+fjui8ghUdVOUSf9FrRpBK4igw8n5hdP4Fy4L3VfNzAyUUwf+ed/zJ2ujQIAulH320fINeKrqopYyOtyca0tF28LC1D6oMZKD73DmW9QsGP5qw2X8VsHRNkfCqYierI/w==; 24:zGUwINBUeBdHRS064vtiaNM0LqVEc+CodTBTwJqa4PwyxajBtZpw1EkYHP5zRx7hOXwITtUa5GEdMv+39OPoHKZbGvaTOD/kRQgQBaHYeoY=; 7:3GPIPFN2etds66TsOteYqzYdQL6dGwm4xikkpfrq4OT1dFo1BfCfv9IDRgcZ253TJfSFwxy+P3dvEZQeQfG2aIKpslc0IjoJu1sBtlb+Z7ZN7S5tVRNX+NRNBO1pkbx1Mb6qsqlODK5L53P+4YvY6faNH5wcAsxQT4xNwEdUHfoCMar8AZkmhE57nt/RI11k9jhB0rpn2agMg/zlasNZX7yiQMS2HuaCvXsdZ7UCjnQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2017 22:00:00.8762 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-use-cases-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 22:00:05 -0000 On 25 Oct 2017, at 4:53, internet-drafts@ietf.org wrote: > Filename : draft-ietf-dots-use-cases-08.txt Comments and suggestions welcome; in particular, the WG's consensus on the Home Network use-case in Section 3.2.2 and the relative value it adds as compared to the other use cases would be greatly appreciated. We'd like to rev the draft at least one more time prior to the pre-meeting cutoff, so please don't be shy! ;> ----------------------------------- Roland Dobbins From nobody Tue Oct 24 18:48:54 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CD31395ED for ; Tue, 24 Oct 2017 18:48:53 -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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 dDI1xhGTsPU7 for ; Tue, 24 Oct 2017 18:48:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0EEF139507 for ; Tue, 24 Oct 2017 18:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70522; q=dns/txt; s=iport; t=1508896128; x=1510105728; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=8b7nqwxF/xX+Z6GUFyUQ2O9cJ3DpB9f4pZWO+mQAcUQ=; b=jm/mPXMM3ier7BnmFlAYAnkHrSuP6KjQP6nffj+n5R7m/xOSFn4dCGKR ylKqrzBDhTXamC+8QmNq+pKzpVGtHzdXQefLULgSZbY1ph6Zetk/tn1id cNAvmTQzACDjgFZKbzjIx1Z4Y+nTzJrFPNvf9FwAS8Z8QtLAELtlVPGWn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAACQ7O9Z/4YNJK1YAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvQi5kbieOGY9JgXqWOhCBfgMKGAEMhRYChGE/GAECAQEBAQE?= =?us-ascii?q?BAWsohR0BAQEBAQEBAQEYDQY7BhALCxEBAwEBASABBgcnHwMGCAYBDAYCAQGKD?= =?us-ascii?q?wUIEKofOiaKbAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DKgSCB4FQgWkpgwGETSA?= =?us-ascii?q?CNxURhS4FihaBB4ggjjCHZY0QghVdhR2DXYc5lX+BOR84T4EMVSUVSYJkCYJQA?= =?us-ascii?q?xyCAyQ2AQGLaAEBAQ?= X-IronPort-AV: E=Sophos;i="5.43,430,1503360000"; d="scan'208,217";a="301505476" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Oct 2017 01:48:46 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v9P1mjD7022711; Wed, 25 Oct 2017 01:48:46 GMT To: "Konda, Tirumaleswar Reddy" , Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com> From: Flemming Andreasen Message-ID: <9f4e7915-6de7-c815-4a8a-f636e7853823@cisco.com> Date: Tue, 24 Oct 2017 21:49:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1ECD0D64167B9EB5ADDD2B34" Content-Language: en-US Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 01:48:53 -0000 This is a multi-part message in MIME format. --------------1ECD0D64167B9EB5ADDD2B34 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 10/10/17 7:47 AM, Konda, Tirumaleswar Reddy wrote: > > Hi Flemming, > > Please see inline > > *From:*Flemming Andreasen [mailto:fandreas@cisco.com] > *Sent:* Monday, October 9, 2017 10:06 PM > *To:* Konda, Tirumaleswar Reddy ; > Jon Shallow ; mohamed.boucadair@orange.com; > dots@ietf.org > *Subject:* Re: [Dots] Minimum heartbeat-interval > > On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote: > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Flemming > Andreasen > *Sent:* Monday, October 9, 2017 9:12 PM > *To:* Konda, Tirumaleswar Reddy > > ; Jon Shallow > ; > mohamed.boucadair@orange.com > ; dots@ietf.org > > *Subject:* Re: [Dots] Minimum heartbeat-interval > > On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: > > http://conferences.sigcomm.org/imc/2010/papers/p260.pdfreferenced > by https://tools.ietf.org/html/rfc7925has tested NAT behavior > with various routers and lists the timeout results. The > majority of the devices (62%) have a timeout between 2 and 2.5 > minutes and the minimum timeout value observed when packets > are exchanged b/w peers in both directions is 54 seconds. > > I'm getting different data-points for at least the minimum value. > There still seems to be a lot of NATs out there with a timeout > value of ~30 seconds for UDP traffic (and in rare cases even > lower), which suggests that a timeout value slightly lower than 30 > seconds is what you would want. Google did a lot of testing around > this and decided they were happy with the values in > https://tools.ietf.org/html/rfc7675(i.e. 30 seconds). > > Consent freshness has nothing to do with NAT/FW timeouts. > > You are missing the point Tiru - testing has been done (in the past > and more recently) and a value of ~30 seconds seems to be what works > for the majority of devices. I'll trust Google on this one. > > [TR] > > I see that QUIC is using 15 to 30 seconds keepalives to handle > middlebox idle timeout > (https://tools.ietf.org/html/draft-ietf-quic-transport-06#section-8.7) > but I dont see any reference to the results published by Google, Can > you please point to the test results by Google to refer in the DOTS > signal channel draft? > Sorry for the delay. In any case, if you look at slide 10 in https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf you will see a nice graph of the test results Google ran. There is a small bump at the 30 second mark and hence that's where the value comes from. > (http://conferences.sigcomm.org/imc/2010/papers/p260.pdfresults > indicate 30 seconds is only applicable when there is only outbound > traffic > > and no incoming traffic). > Makes sense - as long as traffic is flowing in either direction, I would not expect the binding to time-out. Thanks -- Flemming > -Tiru > > > -- Flemming > > > > -Tiru > > > > Thanks > > -- Flemming > > > > > Responses to the questions below > > 1) The max-retransmit parameter is negotiable and > configurable, DOTS agents can pick suitable values for > max-retransmit parameter based on the heartbeat-interval (e.g. > use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to > 45 seconds). > > 2) No, if the DOTS agent wants to change the default heartbeat > interval then the other message transmission parameters will > also have to be modified. > > 3) The client will have to assume the session is disconnected > (see the discussion in > https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) > and initiate (D)TLS session resumption > > 4) If heartbeat expires then the DOTS server will close the > (D)TLS session, the client will have to initiate (D)TLS > session resumption. The heartbeat expires only after 273 > seconds (3 CoAP ping confirmable messages, each > CoAP ping re-transmitted 4 times). > > Med In the below text, recommended value should be 93 > seconds instead of 90 seconds (see > https://tools.ietf.org/html/rfc7252#section-4.8.2). > > -Tiru > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Jon > Shallow > *Sent:* Wednesday, October 4, 2017 5:36 PM > *To:* mohamed.boucadair@orange.com > ; dots@ietf.org > > *Subject:* Re: [Dots] Minimum heartbeat-interval > > Hi Mohamed, > > In principal I agree with your suggested updates the minimum > of 10s was an off the cuff response, to handle the broken > NAT timing implementations out there. > > The Heartbeat mechanism does raise a few questions in my mind > which do need to be thought through. On a DOTS server, using > a heartbeat interval of 15 secs, with the client going away > circa 10:54:30, I get > > Oct 04 10:53:51 DEBG sending CoAP ping: > > Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS: sent 41 bytes > > Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29548 added to retransmit > queue (2281ms) > > Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS: received 41 bytes > > Oct 04 10:53:51 ALRT got RST for message 29548 > > Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29548: removed > > Oct 04 10:54:07 DEBG sending CoAP ping: > > Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS: sent 41 bytes > > Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29549 added to retransmit > queue (2938ms) > > Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS: received 41 bytes > > Oct 04 10:54:07 ALRT got RST for message 29549 > > Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29549: removed > > Oct 04 10:54:23 DEBG sending CoAP ping: > > Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS: sent 41 bytes > > Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29550 added to retransmit > queue (2156ms) > > Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS: received 41 bytes > > Oct 04 10:54:23 ALRT got RST for message 29550 > > Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29550: removed > > Oct 04 10:54:39 DEBG sending CoAP ping: > > Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS: sent 41 bytes > > Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29551 added to retransmit > queue (2813ms) > > Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #1 > > Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS: sent 41 bytes > > Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #2 > > Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS: sent 41 bytes > > Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #3 > > Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS: sent 41 bytes > > Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #4 > > Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS: sent 41 bytes > > Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> > 192.168.0.1:54477 (if1) DTLS tid=29551: give up after 4 attempts > > Here we see the 91 seconds (dependant on the max-retransmit > value being 4) 10:56:09 10:54:39. There is 46 seconds after > transmission #4 before the confirmable ping request times out > (12 seconds for transmission #3 before retry transmission #4). > > Question 1 > > ========== > > Should the max-retransmit actually be 3, not 4 for CON > requests so that we do not get this 46 second gap? > > - CON is only used for signal configuration (infrequent, > likely only to be in peace time) and heartbeats, not > mitigation requests > > Question 2 > > ========= > > If the heartbeat interval is less than 91 seconds say 60 > seconds and the first heartbeat ping is still active, should a > second heartbeat be fired off? > > - I think not, but the text then needs to get updated to state > the interval is used whenever there is not a pending heartbeat > response outstanding. > > Question 3 > > ========= > > Heartbeat checks are being initiated by the client. The > client gets a heartbeat timeout on the session. The client > subsequently needs to send a PUT mitigate request. > > Does the client set up a new session? > > - Difficult as we are unlikely to be in peace time > > - PKI exchanges are likely to fail > > - the client just needs to send a non-confirmable PUT. > > Question 4 > > ========= > > Scenario as Q3 > > Does the client re-use the old session that the heartbeats are > failing on? > > - The server may have sent a session close, but it never got > through > > Question 4 > > ========== > > When the heartbeats are initiated by the server, and the > heartbeat times out, the session is bad, but the current > mitigation request continues until it expires. > > The client may have kicked off his heartbeats at a different > time, and there likely will be a sending frequency drift over > time, so the client may think the session is still active, the > server not, and the client decides it is time to send a > non-confirmable PUT to refresh the mitigation as it is about > to expire or possibly another PUT for a different IP that has > just started to get hammered hence heartbeat failures. > > Alternatively the client decides that the reason for bad > session (from the clients perspective) is an attack stopping > traffic getting through and needs to do a PUT on the existing > session. > > So server receives a PUT (refresh or for a new IP) on a > session that has heartbeat expired. The session contained all > the negotiated PKI session keys etc. What should happen here? > > - as the heartbeats are failing, it is safe to assume we are > not in peace time. > > - I believe the session on the server needs to be kept hanging > around for some time post heartbeat time-out. For how long? > > - the server may be seeing the client heartbeat messages [this > may answer how to keep bad session hanging around] > > ========== > > Regards > > Jon > > *From:*Dots [mailto:ietf-supjps-dots-bounces@ietf.org] *On > Behalf Of *ietf-supjps-mohamed.boucadair@orange.com > > *Sent:* 04 October 2017 09:35 > *To:* dots@ietf.org ; Jon Shallow > (supjps-ietf@jpshallow.com ) > *Subject:* [Dots] Minimum heartbeat-interval > > Dear all, > > Jon made the following comment during the interim meeting: A: > (Jon Shallow): The minimum for the heartbeat should be 10s > > Actually, the use of 10s is not aligned with RFC8085 which > says the following: > > An application that needs to employ keep-alive messages to deliver > > useful service over UDP in the presence of middleboxes SHOULD NOT > > ^^^^^^^^^^^^^^^^^^^^^^ > > transmit them more frequently than once every 15 seconds and SHOULD > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > use longer intervals when possible. > > I suggest to add this NEW text to the signal-channel draft to > clarify the rationale for the recommended values: > > NEW: > > Note: heartbeat-interval should be tweaked to also > assist DOTS > > messages for NAT traversal (SIG-010 of > > [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive > > messages must not be sent more frequently than once every 15 > > seconds and should use longer intervals when possible. > > Furthermore, [RFC4787] recommends NATs to use a state > timeout of 2 > > minutes or longer. From that standpoint, this specification > > recommends a minimum heartbeat-interval of 15 seconds and a > > maximum heartbeat-interval of 240 seconds. The > recommended value > > of 90 seconds is selected to anticipate the expiry of > NAT states, > > while avoiding overloading the network with frequent > keepalives > > for NAT state maintenance purposes. Note that this > recommended > > value is close to the one recommended for > MAX_TRANSMIT_WAIT, whose > > value is derived from transmission parameters (Section > 4.8.2 of > > [RFC7252]). > > Thoughts? > > Cheers, > > Med > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > --------------1ECD0D64167B9EB5ADDD2B34 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 10/10/17 7:47 AM, Konda, Tirumaleswar Reddy wrote:

Hi Flemming,

Please see inline

From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Monday, October 9, 2017 10:06 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote:

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote:

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout value observed when packets are exchanged b/w peers in both directions is 54 seconds.

I'm getting different data-points for at least the minimum value. There still seems to be a lot of NATs out there with a timeout value of ~30 seconds for UDP traffic (and in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what you would want. Google did a lot of testing around this and decided they were happy with the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds).

Consent freshness has nothing to do with NAT/FW timeouts.

You are missing the point Tiru - testing has been done (in the past and more recently) and a value of ~30 seconds seems to be what works for the majority of devices. I'll trust Google on this one.

[TR]

I see that QUIC is using 15 to 30 seconds keepalives to handle middlebox idle timeout (https://tools.ietf.org/html/draft-ietf-quic-transport-06#section-8.7) but I dont see any reference to the results published by Google, Can you please point to the test results by Google to refer in the DOTS signal channel draft?

Sorry for the delay. In any case, if you look at slide 10 in https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf you will see a nice graph of the test results Google ran. There is a small bump at the 30 second mark and hence that's where the value comes from.

(http://conferences.sigcomm.org/imc/2010/papers/p260.pdf results indicate 30 seconds is only applicable when there is only outbound traffic

and no incoming traffic).

Makes sense - as long as traffic is flowing in either direction, I would not expect the binding to time-out.

Thanks

-- Flemming

-Tiru


-- Flemming



-Tiru



Thanks

-- Flemming




Responses to the questions below

1) The max-retransmit parameter is negotiable and configurable, DOTS agents can pick suitable values for max-retransmit parameter based on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds).

2) No, if the DOTS agent wants to change the default heartbeat interval then the other message transmission parameters will also have to be modified.

3) The client will have to assume the session is disconnected (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS session, the client will have to initiate (D)TLS session resumption. The heartbeat expires only after 273 seconds (3 CoAP ping confirmable messages, each
CoAP ping re-transmitted 4 times).

Med In the below text, recommended value should be 93 seconds instead of 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2).

-Tiru

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

Hi Mohamed,

In principal I agree with your suggested updates the minimum of 10s was an off the cuff response, to handle the broken NAT timing implementations out there.

The Heartbeat mechanism does raise a few questions in my mind which do need to be thought through. On a DOTS server, using a heartbeat interval of 15 secs, with the client going away circa 10:54:30, I get

Oct 04 10:53:51 DEBG sending CoAP ping:

Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548 added to retransmit queue (2281ms)

Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message 29548

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29548: removed

Oct 04 10:54:07 DEBG sending CoAP ping:

Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549 added to retransmit queue (2938ms)

Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message 29549

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29549: removed

Oct 04 10:54:23 DEBG sending CoAP ping:

Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550 added to retransmit queue (2156ms)

Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message 29550

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29550: removed

Oct 04 10:54:39 DEBG sending CoAP ping:

Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551 added to retransmit queue (2813ms)

Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #1

Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #2

Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #3

Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: retransmission #4

Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes

Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS tid=29551: give up after 4 attempts

Here we see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:09 10:54:39. There is 46 seconds after transmission #4 before the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

Question 1

==========

Should the max-retransmit actually be 3, not 4 for CON requests so that we do not get this 46 second gap?

- CON is only used for signal configuration (infrequent, likely only to be in peace time) and heartbeats, not mitigation requests

Question 2

=========

If the heartbeat interval is less than 91 seconds say 60 seconds and the first heartbeat ping is still active, should a second heartbeat be fired off?

- I think not, but the text then needs to get updated to state the interval is used whenever there is not a pending heartbeat response outstanding.

Question 3

=========

Heartbeat checks are being initiated by the client. The client gets a heartbeat timeout on the session. The client subsequently needs to send a PUT mitigate request.

Does the client set up a new session?

- Difficult as we are unlikely to be in peace time

- PKI exchanges are likely to fail

- the client just needs to send a non-confirmable PUT.

Question 4

=========

Scenario as Q3

Does the client re-use the old session that the heartbeats are failing on?

- The server may have sent a session close, but it never got through

Question 4

==========

When the heartbeats are initiated by the server, and the heartbeat times out, the session is bad, but the current mitigation request continues until it expires.

The client may have kicked off his heartbeats at a different time, and there likely will be a sending frequency drift over time, so the client may think the session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh the mitigation as it is about to expire or possibly another PUT for a different IP that has just started to get hammered hence heartbeat failures.

Alternatively the client decides that the reason for bad session (from the clients perspective) is an attack stopping traffic getting through and needs to do a PUT on the existing session.

So server receives a PUT (refresh or for a new IP) on a session that has heartbeat expired. The session contained all the negotiated PKI session keys etc. What should happen here?

- as the heartbeats are failing, it is safe to assume we are not in peace time.

- I believe the session on the server needs to be kept hanging around for some time post heartbeat time-out. For how long?

- the server may be seeing the client heartbeat messages [this may answer how to keep bad session hanging around]

==========

Regards

Jon

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com)
Subject: [Dots] Minimum heartbeat-interval

Dear all,

Jon made the following comment during the interim meeting: A: (Jon Shallow): The minimum for the heartbeat should be 10s

Actually, the use of 10s is not aligned with RFC8085 which says the following: 

 An application that needs to employ keep-alive messages to deliver
 useful service over UDP in the presence of middleboxes SHOULD NOT
 ^^^^^^^^^^^^^^^^^^^^^^
 transmit them more frequently than once every 15 seconds and SHOULD
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 use longer intervals when possible.

I suggest to add this NEW text to the signal-channel draft to clarify the rationale for the recommended values:

NEW:

Note: heartbeat-interval should be tweaked to also assist DOTS

messages for NAT traversal (SIG-010 of

[I-D.ietf-dots-requirements]). According to [RFC8085], keepalive

messages must not be sent more frequently than once every 15

seconds and should use longer intervals when possible.

Furthermore, [RFC4787] recommends NATs to use a state timeout of 2

minutes or longer. From that standpoint, this specification

recommends a minimum heartbeat-interval of 15 seconds and a

maximum heartbeat-interval of 240 seconds. The recommended value

of 90 seconds is selected to anticipate the expiry of NAT states,

while avoiding overloading the network with frequent keepalives

for NAT state maintenance purposes. Note that this recommended

value is close to the one recommended for MAX_TRANSMIT_WAIT, whose

value is derived from transmission parameters (Section 4.8.2 of

[RFC7252]).

Thoughts?

Cheers,

Med





_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots


--------------1ECD0D64167B9EB5ADDD2B34-- From nobody Tue Oct 24 23:07:07 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C6713B13E for ; Tue, 24 Oct 2017 23:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAevRFdRAzZX for ; Tue, 24 Oct 2017 23:07:01 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5239813942F for ; Tue, 24 Oct 2017 23:07:01 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id AA03716137C; Wed, 25 Oct 2017 08:06:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 7B8E518006A; Wed, 25 Oct 2017 08:06:59 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Wed, 25 Oct 2017 08:06:59 +0200 From: To: Flemming Andreasen , "Konda, Tirumaleswar Reddy" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Minimum heartbeat-interval Thread-Index: AQHTTVd3wiQm/3EfPEqh0XPQYtwdDw== Date: Wed, 25 Oct 2017 06:06:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05D87F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A04DF59@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <06db01d33d09$22e04740$68a0d5c0$@jpshallow.com> <142a7542-f20a-0f97-f22c-5f3f7a47720d@cisco.com> <9f4e7915-6de7-c815-4a8a-f636e7853823@cisco.com> In-Reply-To: <9f4e7915-6de7-c815-4a8a-f636e7853823@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A05D87FOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Minimum heartbeat-interval X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 06:07:07 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A05D87FOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Flemming, Thank you for the pointers. FWIW, we have included this text in the latest version of the signal draft = as per the outcome of this discussion: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8= 085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommend= s NATs to use a state timeout of 2 minutes or longer, but experience shows that sending packets every 15 to 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows. From that standpoint, this specification recommends a minimum heartbeat- interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 30 seconds is selected to anticipate the expiry of NAT state. A heartbeat-interval of 30 second may be seen as too chatty in some deployments. For such deployments, DOTS agents may negotiate longer heartbeat-interval values to avoid overloading the network with too frequent keepalives. Please let us know if changes are still required to address your comment. T= hanks. Cheers, Med De : Flemming Andreasen [mailto:fandreas@cisco.com] Envoy=E9 : mercredi 25 octobre 2017 03:49 =C0 : Konda, Tirumaleswar Reddy; Jon Shallow; BOUCADAIR Mohamed IMT/OLN; do= ts@ietf.org Objet : Re: [Dots] Minimum heartbeat-interval On 10/10/17 7:47 AM, Konda, Tirumaleswar Reddy wrote: Hi Flemming, Please see inline From: Flemming Andreasen [mailto:fandreas@cisco.com] Sent: Monday, October 9, 2017 10:06 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow = ; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote: From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Flemming Andreasen Sent: Monday, October 9, 2017 9:12 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow = ; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Minimum heartbeat-interval On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote: http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https= ://tools.ietf.org/html/rfc7925 has tested NAT behavior with various routers= and lists the timeout results. The majority of the devices (62%) have a ti= meout between 2 and 2.5 minutes and the minimum timeout value observed when= packets are exchanged b/w peers in both directions is 54 seconds. I'm getting different data-points for at least the minimum value. There sti= ll seems to be a lot of NATs out there with a timeout value of ~30 seconds = for UDP traffic (and in rare cases even lower), which suggests that a timeo= ut value slightly lower than 30 seconds is what you would want. Google did = a lot of testing around this and decided they were happy with the values in= https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds). Consent freshness has nothing to do with NAT/FW timeouts. You are missing the point Tiru - testing has been done (in the past and mor= e recently) and a value of ~30 seconds seems to be what works for the major= ity of devices. I'll trust Google on this one. [TR] I see that QUIC is using 15 to 30 seconds keepalives to handle middlebox id= le timeout (https://tools.ietf.org/html/draft-ietf-quic-transport-06#sectio= n-8.7) but I don't see any reference to the results published by Google, C= an you please point to the test results by Google to refer in the DOTS sign= al channel draft? Sorry for the delay. In any case, if you look at slide 10 in https://www.ie= tf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf you will see a nice g= raph of the test results Google ran. There is a small bump at the 30 second= mark and hence that's where the value comes from. (http://conferences.sigcomm.org/imc/2010/papers/p260.pdf results indicate 3= 0 seconds is only applicable when there is only outbound traffic and no incoming traffic). Makes sense - as long as traffic is flowing in either direction, I would no= t expect the binding to time-out. Thanks -- Flemming -Tiru -- Flemming -Tiru Thanks -- Flemming Responses to the questions below 1) The max-retransmit parameter is negotiable and configurable, DOTS agent= s can pick suitable values for max-retransmit parameter based on the heartb= eat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WA= IT to 45 seconds). 2) No, if the DOTS agent wants to change the default heartbeat interval the= n the other message transmission parameters will also have to be modified. 3) The client will have to assume the session is disconnected (see the disc= ussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#secti= on-2.2.1) and initiate (D)TLS session resumption 4) If heartbeat expires then the DOTS server will close the (D)TLS session,= the client will have to initiate (D)TLS session resumption. The heartbeat = expires only after 273 seconds (3 "CoAP ping" confirmable messages, each "CoAP ping" re-transmitted 4 times). Med - In the below text, recommended value should be 93 seconds instead of = 90 seconds (see https://tools.ietf.org/html/rfc7252#section-4.8.2). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, October 4, 2017 5:36 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Minimum heartbeat-interval Hi Mohamed, In principal I agree with your suggested updates - the minimum of 10s was a= n off the cuff response, to handle the "broken" NAT timing implementations = out there. The Heartbeat mechanism does raise a few questions in my mind which do need= to be thought through. On a DOTS server, using a heartbeat interval of 15= secs, with the client going away circa 10:54:30, I get Oct 04 10:53:51 DEBG sending CoAP ping: Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548 added to retransmit queue (2281ms) Oct 04 10:53:51 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:53:51 ALRT got RST for message 29548 Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29548: removed Oct 04 10:54:07 DEBG sending CoAP ping: Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549 added to retransmit queue (2938ms) Oct 04 10:54:07 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:07 ALRT got RST for message 29549 Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29549: removed Oct 04 10:54:23 DEBG sending CoAP ping: Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550 added to retransmit queue (2156ms) Oct 04 10:54:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : received 41 bytes Oct 04 10:54:23 ALRT got RST for message 29550 Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29550: removed Oct 04 10:54:39 DEBG sending CoAP ping: Oct 04 10:54:39 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551 added to retransmit queue (2813ms) Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #1 Oct 04 10:54:42 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #2 Oct 04 10:54:48 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #3 Oct 04 10:55:00 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: retransmission #4 Oct 04 10:55:23 DEBG * 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= : sent 41 bytes Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 <-> 192.168.0.1:54477 (if1) DTLS= tid=3D29551: give up after 4 attempts Here we see the 91 seconds (dependant on the max-retransmit value being 4) = 10:56:09 - 10:54:39. There is 46 seconds after transmission #4 before the = confirmable ping request times out (12 seconds for transmission #3 before r= etry transmission #4). Question 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should the max-retransmit actually be 3, not 4 for CON requests so that we = do not get this 46 second gap? - CON is only used for signal configuration (infrequent, likely only to be = in peace time) and heartbeats, not mitigation requests Question 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D If the heartbeat interval is less than 91 seconds - say 60 seconds and the = first heartbeat ping is still active, should a second heartbeat be fired of= f? - I think not, but the text then needs to get updated to state the interval= is used whenever there is not a pending heartbeat response outstanding. Question 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Heartbeat checks are being initiated by the client. The client gets a hear= tbeat timeout on the session. The client subsequently needs to send a PUT = mitigate request. Does the client set up a new session? - Difficult as we are unlikely to be in peace time - PKI exchanges are likely to fail - the client just needs to send a non-confirmable PUT. Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Scenario as Q3 Does the client re-use the old session that the heartbeats are failing on? - The server may have sent a session close, but it never got through Question 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When the heartbeats are initiated by the server, and the heartbeat times ou= t, the session is "bad", but the current mitigation request continues until= it expires. The client may have kicked off his heartbeats at a different time, and ther= e likely will be a sending frequency drift over time, so the client may thi= nk the session is still active, the server not, and the client decides it i= s time to send a non-confirmable PUT to refresh the mitigation as it is abo= ut to expire or possibly another PUT for a different IP that has just start= ed to get hammered - hence heartbeat failures. Alternatively the client decides that the reason for "bad" session (from th= e client's perspective) is an attack stopping traffic getting through and n= eeds to do a PUT on the existing session. So server receives a PUT (refresh or for a new IP) on a session that has he= artbeat expired. The session contained all the negotiated PKI session keys= etc. What should happen here? - as the heartbeats are failing, it is safe to assume we are not in peace t= ime. - I believe the session on the server needs to be kept hanging around for s= ome time post heartbeat time-out. For how long? - the server may be seeing the client heartbeat messages [this may answer h= ow to keep "bad" session hanging around] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 04 October 2017 09:35 To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow= .com) Subject: [Dots] Minimum heartbeat-interval Dear all, Jon made the following comment during the interim meeting: "A: (Jon Shallow= ): The minimum for the heartbeat should be 10s" Actually, the use of 10s is not aligned with RFC8085 which says the followi= ng: An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT ^^^^^^^^^^^^^^^^^^^^^^ transmit them more frequently than once every 15 seconds and SHOULD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use longer intervals when possible. I suggest to add this NEW text to the signal-channel draft to clarify the r= ationale for the recommended values: NEW: Note: heartbeat-interval should be tweaked to also assist DOTS messages for NAT traversal (SIG-010 of [I-D.ietf-dots-requirements]). According to [RFC8085], keepalive messages must not be sent more frequently than once every 15 seconds and should use longer intervals when possible. Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 minutes or longer. From that standpoint, this specification recommends a minimum heartbeat-interval of 15 seconds and a maximum heartbeat-interval of 240 seconds. The recommended value of 90 seconds is selected to anticipate the expiry of NAT states, while avoiding overloading the network with frequent keepalives for NAT state maintenance purposes. Note that this recommended value is close to the one recommended for MAX_TRANSMIT_WAIT, whose value is derived from transmission parameters (Section 4.8.2 of [RFC7252]). Thoughts? Cheers, Med _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_787AE7BB302AE849A7480A190F8B93300A05D87FOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Flemming,

 

Thank you for the pointers.

 

FWIW, we have included this tex= t in the latest version of the signal draft as per the outcome of this disc= ussion:

 

&n= bsp;     Note: heartbeat-interval should be tweaked to = also assist DOTS

&n= bsp;     messages for NAT traversal (SIG-010 of

&n= bsp;     [I-D.ietf-dots-requirements<= /span>]). = ; According to [RFC8085], keepalive

&n= bsp;     messages must not be sent more frequently than= once every 15

&n= bsp;     seconds and should use longer intervals when p= ossible.

 

&n= bsp;     Furthermore, [RFC4787] recommends NATs to use a state timeout of 2

&n= bsp;     minutes or longer, but experience shows that s= ending packets every

&n= bsp;     15 to 30 seconds is necessary to prevent the m= ajority of

&n= bsp;     middleboxes from losing state for UDP flows.&n= bsp; From that

&n= bsp;     standpoint, this specification recommends a mi= nimum heartbeat-

&n= bsp;     interval of 15 seconds and a maximum heartbeat= -interval of 240

&n= bsp;     seconds.  The recommended value of 30 sec= onds is selected to

&n= bsp;     anticipate the expiry of NAT state.=

 

&n= bsp;     A heartbeat-interval of 30 second may be seen = as too chatty in

&n= bsp;     some deployments.  For such deployments, = DOTS agents may negotiate

&n= bsp;     longer heartbeat-interval values to avoid over= loading the network

&n= bsp;     with too frequent keepalives.

 

Please let us know if changes a= re still required to address your comment. Thanks.

 

Cheers,

Med

 

De : 

 

On 10/10/17 7:47 AM, Konda, Tirumaleswar Reddy wrote= :

Hi Flemming,

 

Please see inline

 

From: Flemming Andreasen [mail= to:fandreas@cisco.com]
Sent: Monday, October 9, 2017 10:06 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

 

On 10/9/17 11:55 AM, Konda, Tirumaleswar Reddy wrote= :

From: Dots [mailto:dots-bounces@ietf.org<= span style=3D"color:windowtext;mso-fareast-language:ZH-CN">] On Behalf Of Flemming Andreasen
Sent: Monday, October 9, 2017 9:12 PM
To: Konda, Tirumaleswar Reddy <Tirum= aleswarReddy_Konda@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Minimum heartbeat-interval

 

 

On 10/5/17 6:54 AM, Konda, Tirumaleswar Reddy wrote:=

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf referenced by https://tools.ietf.o= rg/html/rfc7925 has tested NAT behavior with various routers and lists the timeout results. The majority of the devices= (62%) have a timeout between 2 and 2.5 minutes and the minimum timeout val= ue observed when packets are exchanged b/w peers in both directions is 54 s= econds.

 

I'm getting differe= nt data-points for at least the minimum value. There still seems to be a lo= t of NATs out there with a timeout value of ~30 seconds for UDP traffic (an= d in rare cases even lower), which suggests that a timeout value slightly lower than 30 seconds is what you would want= . Google did a lot of testing around this and decided they were happy with = the values in https://tools.ietf.org/html/rfc7675 (i.e. 30 seconds).

 

Consent freshness has nothing to do with NAT/FW timeouts.

You are missing the= point Tiru - testing has been done (in the past and more recently) and a v= alue of ~30 seconds seems to be what works for the majority of devices. I'l= l trust Google on this one.

 

[TR]

I see that QUIC is using 15 to 30 seconds keepalives to handle midd= lebox idle timeout (https://tools.ietf.org/html/draft-ietf-quic-transport-06#section-8.7) but I don’t see any reference to the results published by Google,  Can you please point to the test result= s by Google to refer in the DOTS signal channel draft?

Sorry for th= e delay. In any case, if you look at slide 10 in https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf you will see a nice graph of the test results Google ran. There is a smal= l bump at the 30 second mark and hence that's where the value comes from.


(http://conferences.sigcomm.org/im= c/2010/papers/p260.pdf results indicate 30 seconds is only applicable when there is only outbound traffic

and no incoming traffic).

Makes sense = - as long as traffic is flowing in either direction, I would not expect the= binding to time-out.

Thanks

-- Flemming


 

-Tiru


-- Flemming




 

-Tiru



Thanks

-- Flemming





Responses to the questions below

 

1) The max-retransmit parameter is negotiable and configurable,&nbs= p; DOTS agents can pick suitable values for max-retransmit parameter based = on the heartbeat-interval (e.g. use 3 instead of default 4 to reduce the MAX_TRANSMIT_WAIT to 45 seconds). <= /o:p>

2) No, if the DOTS agent wants to change the default heartbeat inte= rval then the other message transmission parameters will also have to be mo= dified.

3) The client will have to assume the session is disconnected (see = the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-03#section-2.2.= 1) and initiate (D)TLS session resumption

4) If heartbeat expires then the DOTS server will close the (D)TLS = session, the client will have to initiate (D)TLS session resumption. The he= artbeat expires only after 273 seconds (3 “CoAP ping” confirmable messages, each
“CoAP ping” re-transmitted 4 times).

 

Med – In the below text, recommended value should be 93 secon= ds instead of 90 seconds (see https://tools.ietf.or= g/html/rfc7252#section-4.8.2).

 

-Tiru

 

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, October 4, 2017 5:36 PM
To: mohamed.boucadair@orange.com; dots@ietf.org=
Subject: Re: [Dots] Minimum heartbeat-interval

 

Hi Moha= med,

 <= /span>

In prin= cipal I agree with your suggested updates – the minimum of 10s was an= off the cuff response, to handle the “broken” NAT timing imple= mentations out there. 

 <= /span>

The Hea= rtbeat mechanism does raise a few questions in my mind which do need to be = thought through.  On a DOTS server, using a heartbeat interval of 15 s= ecs, with the client going away circa 10:54:30, I get

 <= /span>

Oct 04 10:53:51 DEBG sending CoAP ping:

Oct 04 10:53:51 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29548 added to retransmit queue= (2281ms)

Oct 04 10:53:51 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:53:51 ALRT got RST for message 295= 48

Oct 04 10:53:51 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29548: removed

Oct 04 10:54:07 DEBG sending CoAP ping:

Oct 04 10:54:07 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29549 added to retransmit queue= (2938ms)

Oct 04 10:54:07 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:07 ALRT got RST for message 295= 49

Oct 04 10:54:07 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29549: removed

Oct 04 10:54:23 DEBG sending CoAP ping:

Oct 04 10:54:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29550 added to retransmit queue= (2156ms)

Oct 04 10:54:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: received 41 bytes

Oct 04 10:54:23 ALRT got RST for message 295= 50

Oct 04 10:54:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29550: removed

Oct 04 10:54:39 DEBG sending CoAP ping:

Oct 04 10:54:39 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:39 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551 added to retransmit queue= (2813ms)

Oct 04 10:54:42 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #1=

Oct 04 10:54:42 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:54:48 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #2=

Oct 04 10:54:48 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:55:00 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #3=

Oct 04 10:55:00 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:55:23 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: retransmission #4=

Oct 04 10:55:23 DEBG *  192.168.0.189:5= 684 <-> 192.168.0.1:54477 (if1) DTLS: sent 41 bytes=

Oct 04 10:56:09 DEBG ** 192.168.0.189:5684 &= lt;-> 192.168.0.1:54477 (if1) DTLS tid=3D29551: give up after 4 attempts=

 <= /span>

Here we= see the 91 seconds (dependant on the max-retransmit value being 4) 10:56:0= 9 – 10:54:39.  There is 46 seconds after transmission #4 before = the confirmable ping request times out (12 seconds for transmission #3 before retry transmission #4).

 <= /span>

Questio= n 1

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Should = the max-retransmit actually be 3, not 4 for CON requests so that we do not = get this 46 second gap?

- CON i= s only used for signal configuration (infrequent, likely only to be in peac= e time) and heartbeats, not mitigation requests

 <= /span>

Questio= n 2

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

If the = heartbeat interval is less than 91 seconds – say 60 seconds and the f= irst heartbeat ping is still active, should a second heartbeat be fired off= ?

- I thi= nk not, but the text then needs to get updated to state the interval is use= d whenever there is not a pending heartbeat response outstanding.

 <= /span>

Questio= n 3

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Heartbe= at checks are being initiated by the client.  The client gets a heartb= eat timeout on the session.  The client subsequently needs to send a P= UT mitigate request.

 <= /span>

Does th= e client set up a new session?

- Diffi= cult as we are unlikely to be in peace time

- PKI e= xchanges are likely to fail

- the c= lient just needs to send a non-confirmable PUT.

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 <= /span>

Scenari= o as Q3

 <= /span>

Does th= e client re-use the old session that the heartbeats are failing on?<= o:p>

- The s= erver may have sent a session close, but it never got through

 <= /span>

Questio= n 4

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

When th= e heartbeats are initiated by the server, and the heartbeat times out, the = session is “bad”, but the current mitigation request continues = until it expires.

The cli= ent may have kicked off his heartbeats at a different time, and there likel= y will be a sending frequency drift over time, so the client may think the = session is still active, the server not, and the client decides it is time to send a non-confirmable PUT to refresh= the mitigation as it is about to expire or possibly another PUT for a diff= erent IP that has just started to get hammered – hence heartbeat fail= ures. 

Alterna= tively the client decides that the reason for “bad” session (fr= om the client’s perspective) is an attack stopping traffic getting th= rough and needs to do a PUT on the existing session.

 <= /span>

So serv= er receives a PUT (refresh or for a new IP) on a session that has heartbeat= expired.  The session contained all the negotiated PKI session keys e= tc.  What should happen here?

- as th= e heartbeats are failing, it is safe to assume we are not in peace time.

- I bel= ieve the session on the server needs to be kept hanging around for some tim= e post heartbeat time-out. For how long?

- the s= erver may be seeing the client heartbeat messages [this may answer how to k= eep “bad” session hanging around]

 <= /span>

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

Regards=

 <= /span>

Jon

 <= /span>

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.bouc= adair@orange.com
Sent: 04 October 2017 09:35
To: dots@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com)
Subject: [Dots] Minimum heartbeat-interval

 

Dear all,

 

Jon made the following comment during the interim meeting:= “A: (Jon Shallow): The minim= um for the heartbeat should be 10s”

 

Actually, the use of 10s is not aligned with RFC8085 which= says the following:

 

   An application that needs to employ kee=
p-alive messages to deliver
   useful service over UDP in the presence=
 of middleboxes SHOULD NOT
        &nbs=
p;            &=
nbsp;           &nbs=
p;            ^^^^^^=
^^^^^^^^^^^^^^^^
   transmit them more frequently than once=
 every 15 seconds and SHOULD
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   use longer intervals when possible.&nbs=
p;

 

I suggest to add this NEW text to the signal-channel draft= to clarify the rationale for the recommended values:

 

NEW:

    &= nbsp; Note: heartbeat-interval should be tweaked to also assist DOTS=

    &= nbsp; messages for NAT traversal (SIG-010 of

  &= nbsp;   [I-D.ietf-dots-requirements]).  According to [RFC8085], keepalive<= /span>

    &= nbsp; messages must not be sent more frequently than once every 15

    &= nbsp; seconds and should use longer intervals when possible.

    &= nbsp; Furthermore, [RFC4787] recommends NATs to use a state timeout of 2

    &= nbsp; minutes or longer.  From that standpoint, this specification

    &= nbsp; recommends a minimum heartbeat-interval of 15 seconds and a

    &= nbsp; maximum heartbeat-interval of 240 seconds.  The recommended valu= e

    &= nbsp; of 90 seconds is selected to anticipate the expiry of NAT states,

    &= nbsp; while avoiding overloading the network with frequent keepalives

    &= nbsp; for NAT state maintenance purposes.  Note that this recommended<= /span>

    &= nbsp; value is close to the one recommended for MAX_TRANSMIT_WAIT, whose

    &= nbsp; value is derived from transmission parameters (Section 4.8.2 of

      [RFC7252]).<= /o:p>

 

Thoughts?

 

Cheers,

Med






_______________________________________________=

Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

 <= /o:p>

 <= /o:p>

 <= /o:p>

--_000_787AE7BB302AE849A7480A190F8B93300A05D87FOPEXCLILMA3corp_-- From nobody Wed Oct 25 13:42:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2D013A039 for ; Wed, 25 Oct 2017 13:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 RzW3xRSPxpVv for ; Wed, 25 Oct 2017 13:42:03 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04AB6139B9F for ; Wed, 25 Oct 2017 13:42:02 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v9PKg1Qe027634 for ; Wed, 25 Oct 2017 16:42:01 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu v9PKg1Qe027634 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1508964122; bh=r9n/8K029BU564yxYs8YGhM8lYb5eLpM1XyXfsr/zqw=; h=From:To:Subject:Date:From; b=QurA5klzOzf0x5Tjfk+T/cYWWAJGJ9zwoMbRGW8Nz651TJ/3Rs68mm21l8qyPShQW WwvuaRMVH9v9UK6PrywquMeTc1nFPb+gKAC684bTJUSsJrY5rw07ffmdmiEdesVhiA 6uBB4DqCIbULmtZcDKwle085bUBfNKBXkPORKG/Q= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v9PKg0HZ004062 for ; Wed, 25 Oct 2017 16:42:00 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Wed, 25 Oct 2017 16:42:00 -0400 From: Roman Danyliw To: "'dots@ietf.org'" Thread-Topic: Open issues in use case draft? Thread-Index: AdNN0Z6QcQype5fKRBSmosNUsTiHTg== Date: Wed, 25 Oct 2017 20:41:59 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104FF1CA1@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Open issues in use case draft? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 20:42:05 -0000 Hello Use Case Team! Thanks for publishing a -08 draft. In reviewing the diffs, I could use your help in understanding what issues = got closed with this update and what is outstanding. >From the mailing list/meeting minutes, I see a few threads of feedback for = -06 and -07. My cursory review shows that some of these are not reflected = in the -08 version or acknowledged. I'm tracking on these references as containing feedback: October 2, 2017 (from: Artyom Gavrichenkov) https://www.ietf.org/mail-archive/web/dots/current/msg01427.html October 2, 2017: Virtual Interim Meeting Notes https://datatracker.ietf.org/meeting/interim-2017-dots-03/materials/minutes= -interim-2017-dots-03-201710021000/ July 18, 2017 (from: Andrea Mortensen) https://www.ietf.org/mail-archive/web/dots/current/msg01315.html Jul 18, 2017 (from: me/Roman Danyliw, no hat) https://www.ietf.org/mail-archive/web/dots/current/msg01314.html Can the team provide an update relative to this feedback. To anyone else whose provided feedback: If I missed a pointer to your feedb= ack on the draft above, can you please correct me. Roman From nobody Wed Oct 25 19:22:15 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B79F11387BC; Wed, 25 Oct 2017 19:22:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150898453370.24100.3817489045491387456@ietfa.amsl.com> Date: Wed, 25 Oct 2017 19:22:13 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-architecture-05.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 02:22:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Authors : Andrew Mortensen Flemming Andreasen Tirumaleswar Reddy Christopher Gray Rich Compton Nik Teague Filename : draft-ietf-dots-architecture-05.txt Pages : 30 Date : 2017-10-25 Abstract: This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-architecture-05 https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-architecture-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 25 19:26:48 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B91F139689; Wed, 25 Oct 2017 19:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 mxbnbuhynppK; Wed, 25 Oct 2017 19:26:45 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0099.outbound.protection.outlook.com [104.47.36.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3030C138FA0; Wed, 25 Oct 2017 19:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MCfsckBWjb/NRxO0iaoELNGP+uW4wkdYAy+z8kM6EYc=; b=HfJfD/U9I2XMhSjQy6GZIMsHleXmCK3yhZdc5ekhDVDEs3Ld0bljTTIi12NY09ufZhmQkwe10nUsF9JTGRtbVSpGggolWSXCKx3R8jrKpAyONj9pYlvQNbyl+oatBXVG4wH4qctmfelRVdaGznUJ6GnbhSafkrG0dptEPyZtP0E= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1986.prod.exchangelabs.com (10.166.71.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Thu, 26 Oct 2017 02:26:42 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0178.007; Thu, 26 Oct 2017 02:26:42 +0000 From: "Mortensen, Andrew" To: "internet-drafts@ietf.org" CC: "i-d-announce@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-architecture-05.txt Thread-Index: AQHTTgFB7mYo+n2Ut0mmCGP0chlw2aL1Z7MA Date: Thu, 26 Oct 2017 02:26:42 +0000 Message-ID: References: <150898453370.24100.3817489045491387456@ietfa.amsl.com> In-Reply-To: <150898453370.24100.3817489045491387456@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.49.167.203] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1986; 6:o7d/MJZJ65nT/+hU+QvsjznJsQLLw0DP7OAwvpDyuc5mSB50D11vX8FNr/vnk+t7pKj6LCgL4Ev5nwozsTpF1LQTDqoaR7wQm/tne0crnBp+lkA8MglEepsiFj/GnYiRJk6gIJ9X8m+aUDmy6QxwfBPlA/GOSuAI1v3cmQplSf9yJXLfuBesHFbUo87ZWlDvZPqeCZ5jHLuIEGMx8M9PFPVs1sBKRV0xb7ncSE6Ea97fU0wry29MXBDNEaQQa9bZwsEIC9Ae65eIIQe83K8iJt0mAZrLeGSDx/BbTsFc6vWjLfwLTAROfANS/wct/NBfqRnGMRuLC3gAhFeUFyTZIhQc5z5v6hVS3FoYvfiW5zY=; 5:Bzw2uSBMJG789woFv/+VVDyKAnpzW3DQmAuoSBCTQrvJr7Mfv+GZebIJdUVhJOUK9ccU/3cHwYZOYxMGfCaMCvl/GixoOMU+hkUcsIbWoSYfj17x2XrrrMGosj9+vCXEVddtOXvDtwV7HD0Sh2W0UwR1OBJCHny2Pw1T2aBtoQQ=; 24:bGztQwX3tvJidfzvRBegal+1qI6pLo6V4MhGfy2Ub3+RKe7Z5ACX8VDg4wyiupDK6UebrQdldkUi3pNUEOOB5l9gMWJwfj8Wg6OkxgHByJs=; 7:yp0paFXHUkzGCbutOIAhyPFUacwd8m/yYuEShgl8tC8EkdLoG2rG2NwmPqnozfwZrX1iBOCA+qkNiN5VMMn0AOgZ6eq/VJqNW6YZEfWidJz9ntkF7bWcWdwYPIDqv93SY3NZ3UCpd89Ifq9Pjxcfa8kebJjzvIs/Iu4HjQlxwIN6i1q0+JzsmBnB5Mi+wnDlV/4uFcNFFyQqXF4Rq6gmuenbrjtU/aG9DLMkF8oKg+bVzt+VnecCubJNgnqvcpvS x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0f5970f9-66ab-4ca4-bfbb-08d51c18ff36 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603238); SRVR:BN3PR01MB1986; x-ms-traffictypediagnostic: BN3PR01MB1986: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231020)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR01MB1986; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR01MB1986; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39830400002)(346002)(377424004)(199003)(189002)(24454002)(4326008)(81156014)(316002)(6306002)(6506006)(5660300001)(229853002)(86362001)(36756003)(106356001)(4001150100001)(6436002)(2906002)(105586002)(83716003)(3660700001)(97736004)(5640700003)(77096006)(3280700002)(66066001)(2351001)(2900100001)(6486002)(53546010)(966005)(53936002)(54906003)(82746002)(102836003)(6116002)(3846002)(7736002)(305945005)(6246003)(50986999)(189998001)(14454004)(33656002)(81166006)(450100002)(8936002)(478600001)(101416001)(2950100002)(76176999)(6512007)(230783001)(25786009)(99286003)(6916009)(68736007)(8676002)(2501003)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1986; H:BN3PR01MB1987.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <46E05B02A2FE81418F4CFEDEB2F8BC3B@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 0f5970f9-66ab-4ca4-bfbb-08d51c18ff36 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 02:26:42.8270 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1986 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-architecture-05.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 02:26:47 -0000 This update to the architecture draft marks the data channel as optional, a= nd fixes a number of minor editorial concerns turned up by an end-to-end sc= rub from Flemming. The update does not include content from pull request of= a proposed appendix on multihoming, and does not address the one very rece= ntly opened issue requesting a section on NAT considerations in the DOTS ar= chitecture. After resolving what to do with those two issues, the architecture draft te= am believes the document is ready for WGLC. andrew > On Oct 25, 2017, at 10:22 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed-Denial-of-Service Open Threat Signal= ing (DOTS) Architecture > Authors : Andrew Mortensen > Flemming Andreasen > Tirumaleswar Reddy > Christopher Gray > Rich Compton > Nik Teague > Filename : draft-ietf-dots-architecture-05.txt > Pages : 30 > Date : 2017-10-25 >=20 > Abstract: > This document describes an architecture for establishing and > maintaining Distributed Denial of Service (DDoS) Open Threat > Signaling (DOTS) within and between domains. The document does not > specify protocols or protocol extensions, instead focusing on > defining architectural relationships, components and concepts used in > a DOTS deployment. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-architecture-05 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-architecture-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Oct 26 00:44:24 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CF91394E4 for ; Thu, 26 Oct 2017 00:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 F7lrG8p5o2JT for ; Thu, 26 Oct 2017 00:44:20 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 315D8138726 for ; Thu, 26 Oct 2017 00:44:20 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509003848; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=v yK/Tb28RjF2NmuHbQVNR8KYPB1k7hv4ncgiSKVZKO o=; b=KUlyUtGxzKPq9LFo448U/jbnKoJmdUnATUXgM49Ooh92 bvAgXAZsXqeZjxpTbeHxk9EnjbS718kNyTyLpFcGscAsHniJts sl7W4RGXgjDqQspUH/BLss3olhLMlP+bbZcZ61WRTjEDzqf4Ky WO+rjbQiIoMmSSGigLZBT7dDwJk= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c1b_5730_fd4ecbd1_6290_49e5_a983_4b299ff80a6f; Thu, 26 Oct 2017 02:44:07 -0500 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 01:44:05 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 01:44:05 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 26 Oct 2017 01:44:05 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 01:44:04 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 26 Oct 2017 07:44:03 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0156.007; Thu, 26 Oct 2017 07:44:03 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Flemming Andreasen" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAGjp6AACQhAAAAYgT5UA== Date: Thu, 26 Oct 2017 07:44:03 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:fveqQgKjofO5wBc2bo6shIEL0TSTEIsQXdYnPsvVTRuZok/7bziJmEgWlZhVZcRP6oFtUWS/xSyTZkjQAOzBGQZIVt4nuTlt27EyzEqqQaqJY7SaWq6QkzzcdNjqOJeE/oZVbbTf1Z2ZQj54WXYybSi5O8GWmPxtuh4d9DwsscZtza/PLPQlChN2qBfNMEfWzdQgq6n950xUNB3iS3Rav0vakrw1PSQz3tFysjVgHR6O5xdAac9EdM466F0JR/UWlSog2yHs0dk2Nl8ODdU+ZOOK5ppgYR1MG3aexSw/sUBwVJFfitozCNB43sq4rexbxHmQPSt4txuEFoqgBL5XFg==; 5:F+HCXioHyd/pN0BlDjLTWMoxIjyCrSTsK54+2owx04d86VYakdRpHUHODAYm9AeEVDzDAF8xQGGQ1fyTzpxBKJ2dckznubHZPqf/AGVg/w/q4nJ+Eh7BRbI99R1cso+4h753CP98jnoGdxv8hew4cw==; 24:/5haaQvTrXSQMKpN7fmLWV8okYwNrcgBxcO4Bx9l6pVxWPIN0y8NQfAZXb9/N5VQ3zkuKSETH3r+vjzVmikSGtqVgmGsi1PhL8zIdWiXsLk=; 7:Tk5w1TLlQ/NdX0P5IWJreEe6kg8C8qT7WYnLmBlJwAoCYkulinmV1GHFEqYp8WKKYphJkHBD11jNVtK0mRNdkoFpC+fAs309trkSLsJTH7c5NZ1bTOiecF3OUcFReWoZgBwxLcxgFcxeqhUo/IDPX8LJ8cnq35mCbao1l1XsvuBwv8ZmEhZmjDlctN33vGZhRTvgsZ+lFwRFrGDCTER56HWrtHKD8wvZ+MKunxObP2Q= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 607ba997-808d-4b09-bb94-08d51c45542a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603238); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(788757137089)(95692535739014)(18271650672692); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3231020)(6041248)(20161123560025)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(55784002)(13464003)(24454002)(32952001)(189002)(199003)(6246003)(966005)(3660700001)(72206003)(6436002)(53546010)(478600001)(8936002)(3846002)(6116002)(102836003)(6506006)(77096006)(86362001)(101416001)(2906002)(74316002)(229853002)(7736002)(305945005)(66066001)(3280700002)(76176999)(14454004)(106356001)(105586002)(81156014)(81166006)(189998001)(7696004)(80792005)(110136005)(50986999)(68736007)(97736004)(33656002)(2900100001)(316002)(2950100002)(6306002)(99286003)(8676002)(9686003)(53936002)(25786009)(55016002)(5660300001)(2501003)(54356999)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 607ba997-808d-4b09-bb94-08d51c45542a X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 07:44:03.1482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6144> : inlines <6146> : streams <1768451> : uri <2522593> Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 07:44:23 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbQ0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI0LCAyMDE3IDI6MjAgUE0NCj4gVG86IEZs ZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPjsgSm9uIFNoYWxsb3cgPHN1cGpw cy0NCj4gaWV0ZkBqcHNoYWxsb3cuY29tPjsgZG90c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYp KQ0KPiANCj4gSGkgRmxlbW1pbmcsIGFsbCwNCj4gDQo+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiAN Cj4gQ2hlZXJzLA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ ID4gRGXCoDogRmxlbW1pbmcgQW5kcmVhc2VuIFttYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tXSBF bnZvecOpwqA6IGx1bmRpIDIzDQo+ID4gb2N0b2JyZSAyMDE3IDE3OjM2IMOAwqA6IEJPVUNBREFJ UiBNb2hhbWVkIElNVC9PTE47IEpvbiBTaGFsbG93Ow0KPiA+IGRvdHNAaWV0Zi5vcmcgT2JqZXTC oDogUmU6IERPVFMgJiBOQVQgKHdhcyBSRTogW0RvdHNdIERPVFMgUmVxdWlyZW1lbnRzDQo+ID4g cmV2aWV3ICgtMDYpKQ0KPiA+DQo+ID4NCj4gPg0KPiA+IE9uIDEwLzIzLzE3IDg6MjggQU0sIG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gPiBIaSBKb24sIGFsbCwNCj4g PiA+DQo+ID4gPiBJIGFncmVlIHdpdGggRmxlbW1pbmcgdGhhdCAic29tZSBtb3JlIHdvcmsiIGlz IG5lZWRlZC4gSU1ITywgdGhpcyBpcw0KPiA+ID4gYQ0KPiA+IHR5cGljYWwgZGlzY3Vzc2lvbiB0 byBpbmNsdWRlIGluIGEgZGVkaWNhdGVkIHNlY3Rpb24gaW4gdGhlIERPVFMNCj4gPiBhcmNoaXRl Y3R1cmUgSS1ELg0KPiA+IEFncmVlZC4NCj4gPiA+ID5Gcm9tIGEgcmVxdWlyZW1lbnQgc3RhbmRw b2ludCwgd2UgZG9uJ3QgbmVlZCB0byBlbGFib3JhdGUgaG93IHRoZQ0KPiA+IHByb3RvY29scyB3 aWxsIGZ1bGZpbCBpdC4gU0lHLTEwIGRvZXMgZXZlbiBhIG5pY2Ugam9iIGJ5IGNpdGluZw0KPiA+ IFJGQzgwODUgd2hpY2ggcG9pbnRzIHRvIE5BVCB0cmF2ZXJzYWwgbWVjaGFuaXNtcy4gT25lIGNv dWxkIHBpY2sNCj4gPiBoaXMvaGVyIGZhdm9yaXRlIHByb3RvY29sIGZyb20gdGhlIGxpc3QgaW4g ODA4NSB0byBkaXNjb3ZlciB0aGUNCj4gPiBleHRlcm5hbCBJUCBhZGRyZXNzL3ByZWZpeCwgaWYg bmVlZGVkLiBFeHRlcm5hbCBJUCBhZGRyZXNzZXMvcHJlZml4ZXMNCj4gPiBjYW4gYmUgSVB2NCBm b3IgYSBOQVQ0NCBvciBOQVQ2NCwgYnV0IGNhbiBiZSBJUHY2IHByZWZpeGVzIGZvcg0KPiA+IGVu dGVycHJpc2VzIGRlcGxveWluZyBOUFR2NiwgYW5kIHNvIG9uLg0KPiA+IFBhcnQgb2YgdGhlIGNo YWxsZW5nZSBoZXJlIGlzIHRoYXQgdGhlIGF0dGFjayB0YXJnZXQgYW5kIHRoZSBET1RTDQo+ID4g Y2xpZW50IGFyZSBub3QgbmVjZXNzYXJpbHkgb25lIGFuZCB0aGUgc2FtZSwgd2hpY2ggbWFrZXMg aXQgbW9yZQ0KPiA+IGRpZmZpY3VsdCB0byBkZXRlcm1pbmUgdGhlIHB1YmxpYy1mYWNpbmcgSVAt YWRkcmVzcy9wb3J0IHVuZGVyIGF0dGFjaw0KPiA+IChhdCBsZWFzdCBpZiB0aGUgRE9UUyBjbGll bnQgaXMgZ29pbmcgdG8gZG8gaXQpLg0KPiANCj4gW01lZF0gVGhpcyBpcyBleGFjdGx5IHRoZSBr aW5kIG9mIHRoZSBkaXNjdXNzaW9uIHRvIGhhdmUuIFRoYW5rcy4NCj4gDQo+IFdpdGggb3Igd2l0 aG91dCBOQVQsIERPVFMgY2xpZW50cyBhcmUgYXNzdW1lZCB0byBiZSBmZWQgd2l0aCB0aGUgaW50 ZXJuYWwNCj4gdGFyZ2V0KHMpLiBUaGlzIGNhbiBiZSBhY2hpZXZlZCBieSBwcm92aXNpb25pbmcg KGxpa2VseSkgb3IgYnkgZGlzY292ZXJ5IG1lYW5zDQo+IChlLmcuLCByZXNpZGVudGlhbCBvciBz bWFsbCBlbnRlcnByaXNlIG5ldHdvcmtzKS4NCj4gDQo+IENhbiB3ZSBhc3N1bWUgdGhhdCB0aGUg ZGlzY292ZXJ5IG9mIHRoZSBleHRlcm5hbCBJUCBhZGRyZXNzL3ByZWZpeC8uLiBpcyBkb25lDQo+ IGJ5IGEgRE9UUyBjbGllbnQgb25seSBpZiBpdCBpcyBleHBsaWNpdGx5IGluc3RydWN0ZWQgdG8g ZG8gc28/DQo+IA0KPiANCj4gPiA+IEluIHNvbWUgZGVwbG95bWVudHMsIERPVFMgY2xpZW50cyBt YXkgYmUgcHJvdmlzaW9uZWQgd2l0aCB0aGUgc2V0IG9mDQo+ID4gaW50ZXJuYWwgcmVzb3VyY2Vz LCBzbyB0aGVyZSBpcyBubyBuZWVkIGZvciBkaXNjb3ZlcnkuDQo+ID4gPg0KPiA+ID4gQWxzbywg YXMgSm9uIG1lbnRpb25lZCwgRE9UUyBnYXRld2F5cyBjYW4gYmUgb2YgaGVscCB0byBzZXQgdGhl DQo+ID4gYXBwcm9wcmlhdGUgSVAgYWRkcmVzc2VzL3ByZWZpeGVzL3BvcnQgbnVtYmVycyBpbiB0 aGUgcHJlc2VuY2Ugb2YNCj4gPiB0cmFuc2xhdG9ycy4NCj4gPiBBZ3JlZWQgLSBidXQgdGhleSBz dGlsbCBuZWVkIGEgd2F5IHRvIGZpZ3VyZSBvdXQgdGhlIHByaXZhdGUvcHVibGljDQo+ID4gbWFw cGluZyBmb3IgYSBnaXZlbiBhdHRhY2sgdGFyZ2V0Lg0KPiANCj4gW01lZF0gQmVjYXVzZSBhIERE b1MgYXR0YWNrIGlzIG9ic2VydmVkIGZyb20gdGhlIGludGVybmFsIG5ldHdvcmssDQo+IG1hcHBp bmcocykgYXJlIG5lY2Vzc2FyaWx5IG1haW50YWluZWQgYnkgdGhlIG9uLXBhdGggdHJhbnNsYXRv cihzKS4NCj4gT3RoZXJ3aXNlLCB0aGUgaW5jb21pbmcgYXR0YWNrIHRyYWZmaWMgY291bGRuJ3Qg YmUgZm9yd2FyZGVkIHRvIGludGVybmFsIGhvc3RzLg0KPiBUaGlzIG1vZGVsIGFzc3VtZXMgdGhh dCB0aGUgZ2F0ZXdheSBpcyBjb2xsb2NhdGVkIHdpdGggdGhlIE5BVC4gU28sIHRoZQ0KPiBnYXRl d2F5IGNhbiByZXBsYWNlIHRoZSBpbnRlcm5hbCBJUCBhZGRyZXNzL3ByZWZpeCB3aXRoIHRoZSBv bmUgcmV0cmlldmVzDQo+IGZyb20gdGhlIE5BVCBtYXBwaW5nIHRhYmxlLg0KPiANCj4gRG8geW91 IHNlZSBhbnkgaXNzdWUgd2l0aCB0aGlzIHNjaGVtZT8NCj4gDQo+ID4gPiBBbiBvcGVuIHF1ZXN0 aW9uIHRob3VnaCB3b3VsZCBiZSB0byBkaXNjdXNzIGlmIHRoZXJlIGlzIGEgdmFsdWUgaW4NCj4g PiBoYXZpbmcgYSBmZWF0dXJlIGluIHRoZSBET1RTIHByb3RvY29sIHRvIGluZm9ybSBhIERPVFMg Y2xpZW50IHRoYXQgYQ0KPiA+IE5BVCBpcyBkZXRlY3RlZCBvbi1wYXRoLiBUaGlzIGNhbiBiZSBw cmVzZW50ZWQgYXMgYW4gaW5mb3JtYXRpb24NCj4gPiBlbGVtZW50IHJldHVybmVkIGJ5IHRoZSBz ZXJ2ZXIgdG8gdGhlIGNsaWVudC4gVGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUsDQo+ID4gZm9yIGV4 YW1wbGUsIHVzZWQgYnkgdGhlIGNsaWVudCB0byBhZGp1c3QgaXRzIEhUIGludGVydmFsLCBhZGp1 c3QgdGhlDQo+ID4gaW50ZXJuYWwgSVAgYWRkcmVzc2VzL3ByZWZpeGVzIHRvIGJlIHByb3RlY3Rl ZCwgZXRjLiBPcGluaW9ucz8NCj4gPiBJdCBzb3VuZHMgYXBwZWFsaW5nLCBidXQgaXQncyB2ZXJ5 IGRpZmZpY3VsdCB0byBkbyB0aGlzIHJlbGlhYmx5LCBhbmQNCj4gPiBpdCdzIG5vdCBqdXN0IE5B VHMgdGhhdCBhcmUgYW4gaXNzdWUgaGVyZTsgRmlyZXdhbGxzIHByZXNlbnQgc2ltaWxhcg0KPiA+ IGNoYWxsZW5nZXMgKGFuZCB0aGV5IG1heSBvciBtYXkgbm90IGJlIE5BVCdpbmcgaW5kaXZpZHVh bCBmbG93cykuDQo+ID4NCj4gDQo+IFtNZWRdIEkgZnVsbHkgYWdyZWUgdGhhdCBmaXJld2FsbHMg ZGV0ZWN0IGlzIG1vcmUgY29tcGxleC4gTGV0J3MgcHV0IGl0IGFzaWRlDQo+IGFuZCBmb2N1cyBv biB0aGUgTkFUIGNhc2UuDQoNClRoZSBwcmVzZW5jZSBhbmQgYmVoYXZpb3Igb2YgTkFUIGFuZCBG aXJld2FsbCwgYW5kIGtlZXBhbGl2ZSBpbnRlcnZhbCBjYW4gYmUgZGV0ZXJtaW5lZCB1c2luZyBT VFVOIChkaXNjdXNzZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3ODApLiAN Cg0KLVRpcnUNCg0KPiANCj4gV2UgY2FuIGNvbnNpZGVyIG1hbnkgYXBwcm9hY2hlcyB0byBkZXRl Y3QgYSBOQVQsIGUuZy4sDQo+IA0KPiAoMSkgVGhlIERPVFMgY2xpZW50IGluc2VydHMgaW4gdGhl IGNvcmUgbWVzc2FnZSB0aGUgSVAgYWRkcmVzcy9wb3J0IGl0IHVzZXMgdG8NCj4gc2VuZCB0aGUg cmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuIFVwb24gcmVjZWlwdCBvZiB0aGUgcmVxdWVzdCBi eSB0aGUNCj4gRE9UUyBzZXJ2ZXIsIGl0IGNoZWNrcyBpZiB0aGUgZW5jbG9zZWQgSVAgYWRkcmVz cy9wb3J0IG1hdGNoIHRoZSBzb3VyY2UgSVANCj4gYWRkcmVzcy9wb3J0IG9mIHRoZSByZWNlaXZl ZCBwYWNrZXQuIElmIHllcywgdGhlIHNlcnZlciBzZXRzIGluIHRoZSByZXNwb25zZSBhDQo+IGRl ZGljYXRlZCBwYXJhbWV0ZXIgdG8gaW5kaWNhdGUgdGhhdCBhIHRyYW5zbGF0b3IgaXMgZGV0ZWN0 ZWQgb24tcGF0aC4NCj4gDQo+ICgyKSBUaGUgRE9UUyBzZXJ2ZXIgaW5zZXJ0cyBzeXN0ZW1hdGlj YWxseSB0aGUgc291cmNlIElQIGFkZHJlc3MvcG9ydCBpbiBhDQo+IHJlc3BvbnNlIHRvIGEgbWVz c2FnZSBmcm9tIGEgRE9UUyBjbGllbnQuIFVwb24gcmVjZWlwdCBvZiB0aGF0IHJlc3BvbnNlLA0K PiB0aGUgRE9UUyBjbGllbnQgY29tcGFyZXMgdGhlIGVuY2xvc2VkIGFkZHJlc3MvcG9ydCB3aXRo IHRoZSBvbmVzIGl0IHVzZWQgdG8NCj4gc2VuZCB0aGUgcmVxdWVzdCB0byBkZXRlY3QgYW55IG1p c21hdGNoLg0KPiANCj4gDQo+ID4gLS0gRmxlbW1pbmcNCj4gPg0KPiA+DQo+ID4gPiBDaGVlcnMs DQo+ID4gPiBNZWQNCj4gPiA+DQo+ID4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ ID4gPj4gRGXCoDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFy dCBkZSBKb24gU2hhbGxvdw0KPiA+ID4+IEVudm95w6nCoDogbHVuZGkgMjMgb2N0b2JyZSAyMDE3 IDEzOjE4IMOAwqA6ICdGbGVtbWluZyBBbmRyZWFzZW4nOw0KPiA+ID4+IGRvdHNAaWV0Zi5vcmcg T2JqZXTCoDogUmU6IFtEb3RzXSBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikNCj4gPiA+ Pg0KPiA+ID4+IEhpIEZsZW1taW5nLA0KPiA+ID4+DQo+ID4gPj4gVGhlIHdheSBteSBtaW5kIHdv cmtzIGlzIHRvIHRoaW5rIG9mIGEgcHJhY3RpY2FsIHNpdHVhdGlvbiBhbmQgc2VlDQo+ID4gPj4g aWYgdGhpbmdzIGZpdC4NCj4gPiA+Pg0KPiA+ID4+IEFzIEkgcmVhZCBTSUctMDEwLCB0aGVyZSBj b3VsZCBiZSBhIERPVFMgY2xpZW50IHdpdGggYSBtYW5hZ2VtZW50DQo+ID4gPj4gSVAgYWRkcmVz cyB0aGF0IGlzIFJGQzE5MTggLSB0aGlzIGNsaWVudCBjb3VsZCBiZSBtb25pdG9yaW5nDQo+ID4g Pj4gTmV0ZmxvdyBpbmZvcm1hdGlvbiBhbmQgY2FuIHJlcXVlc3QgbWl0aWdhdGlvbiBmb3IgdGhl IGFwcHJvcHJpYXRlDQo+ID4gPj4gcHVibGljIElQcw0KPiA+IHRoYXQNCj4gPiA+PiBhcmUgYmVp bmcgbW9uaXRvcmVkLiAgU28gU0lHLTAxMCBpcyBuZWVkZWQgZm9yIHRoaXMgdXNlIGNhc2UuDQo+ ID4gPj4NCj4gPiA+PiBJdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIERPVFMgc2VydmVy IGFzIHRvIHdoZXRoZXIgaXQNCj4gPiA+PiBhY2NlcHRzIGEgbWl0aWdhdGlvbiByZXF1ZXN0IGZv ciBhIHBhcnRpY3VsYXIgdGFyZ2V0IGlwIChvciBkb21haW4gZXRjLikgb3INCj4gbm90Lg0KPiA+ ID4+DQo+ID4gPj4gSWYgdGhlcmUgaXMgZ29pbmcgdG8gYmUgYSBOQVQgYm9yZGVyIHdoZXJlIHB1 YmxpYyBJUHMgYXJlIG1hcHBlZA0KPiA+ID4+IGludG8gcHJpdmF0ZSBJUHMgKGFuZCB2aWNlIHZl cnNhKSwgSSB3b3VsZCB0aGVuIGV4cGVjdCB0aGVyZSB0byBiZQ0KPiA+ID4+IGEgRE9UUyBnYXRl d2F5IGJldHdlZW4gdGhlc2UgMiB6b25lcywgYW5kIGl0IGlzIHRoZSByZXNwb25zaWJpbGl0eQ0K PiA+ID4+IG9mIHRoZSBET1RTIGdhdGV3YXkgdG8gZG8gYW55IHRhcmdldC1pcCBtYXBwaW5ncy4N Cj4gPiA+Pg0KPiA+ID4+IFJlZ2FyZHMNCj4gPiA+Pg0KPiA+ID4+IEpvbg0KPiA+ID4+DQo+ID4g Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+PiBGcm9tOiBEb3RzIFttYWlsdG86 aWV0Zi1zdXBqcHMtZG90cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiA+PiBG bGVtbWluZyBBbmRyZWFzZW4NCj4gPiA+PiBTZW50OiAyMiBPY3RvYmVyIDIwMTcgMjA6MTcNCj4g PiA+PiBUbzogZG90czsgZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50c0BpZXRmLm9yZw0KPiA+ ID4+IFN1YmplY3Q6IFtEb3RzXSBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikNCj4gPiA+ Pg0KPiA+ID4+IEdyZWV0aW5ncw0KPiA+ID4+DQo+ID4gPj4gSSBoYXZlIHJldmlld2VkIHRoZSBs YXRlc3QgdmVyc2lvbiBvZiB0aGUgRE9UUyByZXF1aXJlbWVudHMgZHJhZnQNCj4gPiA+PiAoaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0wNi50eHQp LiBJbg0KPiA+IGdlbmVyYWwsDQo+ID4gPj4gSSB0aGluayB0aGUgZHJhZnQgaXMgaW4gZ29vZCBz aGFwZSB3aXRoIG9ubHkgYSBmZXcgZWRpdHMgcmVxdWlyZWQsDQo+ID4gPj4gc28gSSBob3BlIHdl IGNhbiBtb3ZlIHRvIFdHTEMgc29vbi4gSSBoYXZlIGEgZmV3IGNvbW1lbnRzIGJlbG93IChvZg0K PiA+ID4+IHdoaWNoDQo+ID4gdGhlDQo+ID4gPj4gTkFUIG9uZSBpcyB0aGUgb25seSByZWFsIHN1 YnN0YW50aWFsIG9uZSkuIEkgaGF2ZSBhbHNvIHN1Ym1pdHRlZCBhDQo+ID4gPj4gcHVsbCByZXF1 ZXN0IHdpdGggYSBmZXcgbml0IGZpeGVzIG9uIEdpdEh1YjoNCj4gPiA+Pg0KPiA+ID4+DQo+ID4g Pj4gU2VjdGlvbiAxLjINCj4gPiA+PiAtIFRoZSBkZWZpbml0aW9uIG9mICJET1RTIFNpZ25hbCIg aXMgc2xpZ2h0bHkgaW5jb25zaXN0ZW50IHdpdGggdGhlDQo+ID4gPj4gcmVzcGVjdGl2ZSAiQ2xp ZW50IFNpZ25hbCIgYW5kICJTZXJ2ZXIgU2lnbmFsIiBkZWZpbml0aW9ucy4NCj4gPiA+Pg0KPiA+ ID4+IFNJRy0wMDU6DQo+ID4gPj4gLSBOb3QgY2xlYXIgdGhhdCBhbHdheXMgcmVxdWlyaW5nICJu dW1iZXIgb2YgcGFja2V0cyIgbWV0cmljcyBpcw0KPiA+ID4+IG1lYW5pbmdmdWwuIENvbnNpZGVy IFRDUC1iYXNlZCBhdHRhY2tzIGZvciBleGFtcGxlLiBOdW1iZXIgb2YgYnl0ZXMNCj4gPiA+PiBt YXkgYWx3YXlzIGJlIG9rIC0gYWJvdmUgYW5kIGJleW9uZCB0aGF0IGl0IHNob3VsZCBwcm9iYWJs eSBiZQ0KPiA+ID4+IGV4dGVuc2libGUgYW5kL29yIGF0dGFjayBkZXBlbmRlbnQuDQo+ID4gPj4g LSBJIGRvbid0IHRoaW5rIHRoZSByZXF1aXJlbWVudHMgZG9jdW1lbnQgc2hvdWxkIGdldCBpbnRv DQo+ID4gPj4gc3BlY2lmeWluZw0KPiA+IHRpbWVyDQo+ID4gPj4gdmFsdWVzIC0gZXhwb250aWFs IGJhY2tvZmYgd2l0aCBzb21lIG1heGltdW0gdmFsdWUgc2VlbXMgYWJvdXQgdGhlDQo+ID4gcmln aHQNCj4gPiA+PiBsZXZlbCBvZiBkZXRhaWwgaGVyZS4NCj4gPiA+Pg0KPiA+ID4+IFNJRy0wMDk6 DQo+ID4gPj4gLSBUbyBiZSBjbGVhciwgdGhlIGNvbmZsaWN0cyBvbmx5IGFwcGx5IHdpdGhpbiBh IHNpbmdsZQ0KPiA+ID4+IGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgcmlnaHQgPyBGb3IgZXhhbXBs ZSwgaWYgYSBjbGllbnQgdGVsbHMgdGhlDQo+ID4gPj4gc2FtZSBkb21haW4gdG8gYWx0ZXJuYXRl bHkgdHVybiBvbi9vZmYgbWl0aWdhdGlvbiBmb3IgYSBnaXZlbg0KPiA+ID4+IHByZWZpeCwgcm91 dGUgZmxhcHBpbmcNCj4gPiBtYXkNCj4gPiA+PiBvY2N1ci4gVGhlIHNhbWUgY29uY2VybiBkb2Vz IG5vdCBhcHBseSBpZiBhIGNsaWVudCB0ZWxscyB0d28NCj4gPiA+PiBkaWZmZXJlbnQgYWRtaW5p c3RyYXRpdmUgZG9tYWlucyB0byByZXNwZWN0aXZlIHR1cm4gbWl0aWdhdGlvbiBvbg0KPiA+ID4+ IChkb21haW4gMSkgYW5kDQo+ID4gb2ZmDQo+ID4gPj4gKGRvbWFpbiAyKS4gSWYgc28sIGNhbiB3 ZSBjbGFyaWZ5IHRoYXQgKGFsc28gaW4gbGlldSBvZiBzb21lIG9mIHRoZQ0KPiA+IG11bHRpLQ0K PiA+ID4+IGhvbWluZyBjb21tZW50cyByYWlzZWQgcHJldmlvdXNseSkgPw0KPiA+ID4+DQo+ID4g Pj4gU0lHLTAxMDoNCj4gPiA+PiAtIERPVFMgQ2xpZW50IGJlaGluZCBOQVQuIE9uIG9uZSBoYW5k LCBpdCBzZWVtcyByZWFzb25hYmxlIHRvIGhhdmUNCj4gPiA+PiB0aGlzIHJlcXVpcmVtZW50IHNp bmNlIGNsaWVudHMgZm9yIHN1cmUgY2FuIGJlIGJlaGluZCBOQVRzLCBhbmQgd2l0aA0KPiB0aGlu Z3MNCj4gPiA+PiBsaWtlIGR5bmFtaWMgRE5TLCB0aGV5IGNhbiAgICAgY2VydGFpbmx5IGJlIHJl YWNoYWJsZS4gSG93ZXZlciwgaWYgd2UNCj4gPiBkbw0KPiA+ID4+IHdhbnQgdG8gYWxsb3cgZm9y IHRoaXMgc2NlbmFyaW8sIGFuZCBpbiBwYXJ0aWN1bGFyIGZvciB0aGUgRE9UUw0KPiA+ID4+IGNs aWVudA0KPiA+IHRvDQo+ID4gPj4gaGF2ZSBhIHByaXZhdGUgSVAtYWRkcmVzcyAocG90ZW50aWFs bHkgYmVoaW5kIG11bHRpcGxlIE5BVHMpLCB0aGVuDQo+ID4gPj4gd2UNCj4gPiBoYXZlDQo+ID4g Pj4gbW9yZSB3b3JrIHRvIGRvIGJlY2F1c2UgaXQgd29uJ3QgZG8gdGhlIERPVFMgc2VydmVyIGFu eSBnb29kIHRvIGdldA0KPiA+ID4+IGEgbWl0aWdhdGlvbiByZXF1ZXN0IHJlZmVycmluZyB0byB0 aGF0IHByaXZhdGUgSVAtYWRkcmVzcyAob3IgcHJlZml4KS4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4g Pj4gVGhhbmtzDQo+ID4gPj4NCj4gPiA+PiAtLSBGbGVtbWluZw0KPiA+ID4+DQo+ID4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+PiBEb3Rz IG1haWxpbmcgbGlzdA0KPiA+ID4+IERvdHNAaWV0Zi5vcmcNCj4gPiA+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4gPiA+Pg0KPiA+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4gRG90cyBtYWlsaW5n IGxpc3QNCj4gPiA+PiBEb3RzQGlldGYub3JnDQo+ID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4gPiAuDQo+ID4gPg0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QN Cj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHMNCg== From nobody Thu Oct 26 01:22:25 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2184C13A5CF for ; Thu, 26 Oct 2017 01:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh4bl4N2VnWX for ; Thu, 26 Oct 2017 01:22:22 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D569013A25A for ; Thu, 26 Oct 2017 01:22:21 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 742431C068B; Thu, 26 Oct 2017 10:22:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 481B4180040; Thu, 26 Oct 2017 10:22:20 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0361.001; Thu, 26 Oct 2017 10:22:20 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Flemming Andreasen" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAGjp6AACQhAAAAYgT5UAABUQNg Date: Thu, 26 Oct 2017 08:22:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 08:22:25 -0000 VGlydSwgDQoNClllcywgU1RVTiBjYW4gYmUgbGlzdGVkIGFzIHBhcnQgb2YgdGhlIGV4aXN0aW5n IHRvb2xzIGJveCAoYW1vbmcgdGhlIGxpbmVzIG9mIHdoYXQgaXMgYWxyZWFkeSBkaXNjdXNzZWQg aW4gODA4NSkuDQoNCkkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBtYWtlcyBzZW5zZSB0byByZXF1aXJl IFNUVU4gc3VwcG9ydCBieSBET1RTIGNsaWVudHMuDQoNClRoZSBwcm9wb3NhbCBpcyB0byBpbmNs dWRlIGEgc2ltcGxlIGJ1aWx0LWluIGZlYXR1cmUgaW4gdGhlIERPVFMgcHJvdG9jb2wgaXRzZWxm IHRoYXQgY2FuIGhlbHAgdG8gZGV0ZWN0IE5BVHMuIFRoZSBzdXBwb3J0IG9mIHN1Y2ggZmVhdHVy ZSB3aWxsLCBlLmcuLCBlYXNlIHRyb3VibGVzaG9vdGluZyB3aGVuIGNvbm5lY3Rpdml0eSBwcm9i bGVtcyBhcmUgZXhwZXJpZW5jZWQgb24gdGhlIHBhdGggYmV0d2VlbiBhIGNsaWVudCBhbmQgYSBz ZXJ2ZXIuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZcKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IFttYWlsdG86VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbV0NCj4gRW52b3nDqcKgOiBqZXVkaSAyNiBvY3RvYnJlIDIwMTcg MDk6NDQNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgRmxlbW1pbmcgQW5kcmVh c2VuOyBKb24gU2hhbGxvdzsNCj4gZG90c0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSRTogW0RvdHNd IERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKQ0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERvdHMgW21haWx0bzpk b3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+IG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20NCj4gPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI0LCAyMDE3IDI6MjAgUE0N Cj4gPiBUbzogRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0BjaXNjby5jb20+OyBKb24gU2hh bGxvdyA8c3VwanBzLQ0KPiA+IGlldGZAanBzaGFsbG93LmNvbT47IGRvdHNAaWV0Zi5vcmcNCj4g PiBTdWJqZWN0OiBSZTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVu dHMgcmV2aWV3ICgtMDYpKQ0KPiA+DQo+ID4gSGkgRmxlbW1pbmcsIGFsbCwNCj4gPg0KPiA+IFBs ZWFzZSBzZWUgaW5saW5lLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4gPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERlwqA6IEZsZW1taW5nIEFuZHJlYXNl biBbbWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbV0gRW52b3nDqcKgOiBsdW5kaSAyMw0KPiA+ID4g b2N0b2JyZSAyMDE3IDE3OjM2IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEpvbiBT aGFsbG93Ow0KPiA+ID4gZG90c0BpZXRmLm9yZyBPYmpldMKgOiBSZTogRE9UUyAmIE5BVCAod2Fz IFJFOiBbRG90c10gRE9UUyBSZXF1aXJlbWVudHMNCj4gPiA+IHJldmlldyAoLTA2KSkNCj4gPiA+ DQo+ID4gPg0KPiA+ID4NCj4gPiA+IE9uIDEwLzIzLzE3IDg6MjggQU0sIG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gPiA+IEhpIEpvbiwgYWxsLA0KPiA+ID4gPg0KPiA+ ID4gPiBJIGFncmVlIHdpdGggRmxlbW1pbmcgdGhhdCAic29tZSBtb3JlIHdvcmsiIGlzIG5lZWRl ZC4gSU1ITywgdGhpcyBpcw0KPiA+ID4gPiBhDQo+ID4gPiB0eXBpY2FsIGRpc2N1c3Npb24gdG8g aW5jbHVkZSBpbiBhIGRlZGljYXRlZCBzZWN0aW9uIGluIHRoZSBET1RTDQo+ID4gPiBhcmNoaXRl Y3R1cmUgSS1ELg0KPiA+ID4gQWdyZWVkLg0KPiA+ID4gPiA+RnJvbSBhIHJlcXVpcmVtZW50IHN0 YW5kcG9pbnQsIHdlIGRvbid0IG5lZWQgdG8gZWxhYm9yYXRlIGhvdyB0aGUNCj4gPiA+IHByb3Rv Y29scyB3aWxsIGZ1bGZpbCBpdC4gU0lHLTEwIGRvZXMgZXZlbiBhIG5pY2Ugam9iIGJ5IGNpdGlu Zw0KPiA+ID4gUkZDODA4NSB3aGljaCBwb2ludHMgdG8gTkFUIHRyYXZlcnNhbCBtZWNoYW5pc21z LiBPbmUgY291bGQgcGljaw0KPiA+ID4gaGlzL2hlciBmYXZvcml0ZSBwcm90b2NvbCBmcm9tIHRo ZSBsaXN0IGluIDgwODUgdG8gZGlzY292ZXIgdGhlDQo+ID4gPiBleHRlcm5hbCBJUCBhZGRyZXNz L3ByZWZpeCwgaWYgbmVlZGVkLiBFeHRlcm5hbCBJUCBhZGRyZXNzZXMvcHJlZml4ZXMNCj4gPiA+ IGNhbiBiZSBJUHY0IGZvciBhIE5BVDQ0IG9yIE5BVDY0LCBidXQgY2FuIGJlIElQdjYgcHJlZml4 ZXMgZm9yDQo+ID4gPiBlbnRlcnByaXNlcyBkZXBsb3lpbmcgTlBUdjYsIGFuZCBzbyBvbi4NCj4g PiA+IFBhcnQgb2YgdGhlIGNoYWxsZW5nZSBoZXJlIGlzIHRoYXQgdGhlIGF0dGFjayB0YXJnZXQg YW5kIHRoZSBET1RTDQo+ID4gPiBjbGllbnQgYXJlIG5vdCBuZWNlc3NhcmlseSBvbmUgYW5kIHRo ZSBzYW1lLCB3aGljaCBtYWtlcyBpdCBtb3JlDQo+ID4gPiBkaWZmaWN1bHQgdG8gZGV0ZXJtaW5l IHRoZSBwdWJsaWMtZmFjaW5nIElQLWFkZHJlc3MvcG9ydCB1bmRlciBhdHRhY2sNCj4gPiA+IChh dCBsZWFzdCBpZiB0aGUgRE9UUyBjbGllbnQgaXMgZ29pbmcgdG8gZG8gaXQpLg0KPiA+DQo+ID4g W01lZF0gVGhpcyBpcyBleGFjdGx5IHRoZSBraW5kIG9mIHRoZSBkaXNjdXNzaW9uIHRvIGhhdmUu IFRoYW5rcy4NCj4gPg0KPiA+IFdpdGggb3Igd2l0aG91dCBOQVQsIERPVFMgY2xpZW50cyBhcmUg YXNzdW1lZCB0byBiZSBmZWQgd2l0aCB0aGUNCj4gaW50ZXJuYWwNCj4gPiB0YXJnZXQocykuIFRo aXMgY2FuIGJlIGFjaGlldmVkIGJ5IHByb3Zpc2lvbmluZyAobGlrZWx5KSBvciBieSBkaXNjb3Zl cnkNCj4gbWVhbnMNCj4gPiAoZS5nLiwgcmVzaWRlbnRpYWwgb3Igc21hbGwgZW50ZXJwcmlzZSBu ZXR3b3JrcykuDQo+ID4NCj4gPiBDYW4gd2UgYXNzdW1lIHRoYXQgdGhlIGRpc2NvdmVyeSBvZiB0 aGUgZXh0ZXJuYWwgSVAgYWRkcmVzcy9wcmVmaXgvLi4gaXMNCj4gZG9uZQ0KPiA+IGJ5IGEgRE9U UyBjbGllbnQgb25seSBpZiBpdCBpcyBleHBsaWNpdGx5IGluc3RydWN0ZWQgdG8gZG8gc28/DQo+ ID4NCj4gPg0KPiA+ID4gPiBJbiBzb21lIGRlcGxveW1lbnRzLCBET1RTIGNsaWVudHMgbWF5IGJl IHByb3Zpc2lvbmVkIHdpdGggdGhlIHNldCBvZg0KPiA+ID4gaW50ZXJuYWwgcmVzb3VyY2VzLCBz byB0aGVyZSBpcyBubyBuZWVkIGZvciBkaXNjb3ZlcnkuDQo+ID4gPiA+DQo+ID4gPiA+IEFsc28s IGFzIEpvbiBtZW50aW9uZWQsIERPVFMgZ2F0ZXdheXMgY2FuIGJlIG9mIGhlbHAgdG8gc2V0IHRo ZQ0KPiA+ID4gYXBwcm9wcmlhdGUgSVAgYWRkcmVzc2VzL3ByZWZpeGVzL3BvcnQgbnVtYmVycyBp biB0aGUgcHJlc2VuY2Ugb2YNCj4gPiA+IHRyYW5zbGF0b3JzLg0KPiA+ID4gQWdyZWVkIC0gYnV0 IHRoZXkgc3RpbGwgbmVlZCBhIHdheSB0byBmaWd1cmUgb3V0IHRoZSBwcml2YXRlL3B1YmxpYw0K PiA+ID4gbWFwcGluZyBmb3IgYSBnaXZlbiBhdHRhY2sgdGFyZ2V0Lg0KPiA+DQo+ID4gW01lZF0g QmVjYXVzZSBhIEREb1MgYXR0YWNrIGlzIG9ic2VydmVkIGZyb20gdGhlIGludGVybmFsIG5ldHdv cmssDQo+ID4gbWFwcGluZyhzKSBhcmUgbmVjZXNzYXJpbHkgbWFpbnRhaW5lZCBieSB0aGUgb24t cGF0aCB0cmFuc2xhdG9yKHMpLg0KPiA+IE90aGVyd2lzZSwgdGhlIGluY29taW5nIGF0dGFjayB0 cmFmZmljIGNvdWxkbid0IGJlIGZvcndhcmRlZCB0byBpbnRlcm5hbA0KPiBob3N0cy4NCj4gPiBU aGlzIG1vZGVsIGFzc3VtZXMgdGhhdCB0aGUgZ2F0ZXdheSBpcyBjb2xsb2NhdGVkIHdpdGggdGhl IE5BVC4gU28sIHRoZQ0KPiA+IGdhdGV3YXkgY2FuIHJlcGxhY2UgdGhlIGludGVybmFsIElQIGFk ZHJlc3MvcHJlZml4IHdpdGggdGhlIG9uZQ0KPiByZXRyaWV2ZXMNCj4gPiBmcm9tIHRoZSBOQVQg bWFwcGluZyB0YWJsZS4NCj4gPg0KPiA+IERvIHlvdSBzZWUgYW55IGlzc3VlIHdpdGggdGhpcyBz Y2hlbWU/DQo+ID4NCj4gPiA+ID4gQW4gb3BlbiBxdWVzdGlvbiB0aG91Z2ggd291bGQgYmUgdG8g ZGlzY3VzcyBpZiB0aGVyZSBpcyBhIHZhbHVlIGluDQo+ID4gPiBoYXZpbmcgYSBmZWF0dXJlIGlu IHRoZSBET1RTIHByb3RvY29sIHRvIGluZm9ybSBhIERPVFMgY2xpZW50IHRoYXQgYQ0KPiA+ID4g TkFUIGlzIGRldGVjdGVkIG9uLXBhdGguIFRoaXMgY2FuIGJlIHByZXNlbnRlZCBhcyBhbiBpbmZv cm1hdGlvbg0KPiA+ID4gZWxlbWVudCByZXR1cm5lZCBieSB0aGUgc2VydmVyIHRvIHRoZSBjbGll bnQuIFRoaXMgaW5mb3JtYXRpb24gY2FuIGJlLA0KPiA+ID4gZm9yIGV4YW1wbGUsIHVzZWQgYnkg dGhlIGNsaWVudCB0byBhZGp1c3QgaXRzIEhUIGludGVydmFsLCBhZGp1c3QgdGhlDQo+ID4gPiBp bnRlcm5hbCBJUCBhZGRyZXNzZXMvcHJlZml4ZXMgdG8gYmUgcHJvdGVjdGVkLCBldGMuIE9waW5p b25zPw0KPiA+ID4gSXQgc291bmRzIGFwcGVhbGluZywgYnV0IGl0J3MgdmVyeSBkaWZmaWN1bHQg dG8gZG8gdGhpcyByZWxpYWJseSwgYW5kDQo+ID4gPiBpdCdzIG5vdCBqdXN0IE5BVHMgdGhhdCBh cmUgYW4gaXNzdWUgaGVyZTsgRmlyZXdhbGxzIHByZXNlbnQgc2ltaWxhcg0KPiA+ID4gY2hhbGxl bmdlcyAoYW5kIHRoZXkgbWF5IG9yIG1heSBub3QgYmUgTkFUJ2luZyBpbmRpdmlkdWFsIGZsb3dz KS4NCj4gPiA+DQo+ID4NCj4gPiBbTWVkXSBJIGZ1bGx5IGFncmVlIHRoYXQgZmlyZXdhbGxzIGRl dGVjdCBpcyBtb3JlIGNvbXBsZXguIExldCdzIHB1dCBpdA0KPiBhc2lkZQ0KPiA+IGFuZCBmb2N1 cyBvbiB0aGUgTkFUIGNhc2UuDQo+IA0KPiBUaGUgcHJlc2VuY2UgYW5kIGJlaGF2aW9yIG9mIE5B VCBhbmQgRmlyZXdhbGwsIGFuZCBrZWVwYWxpdmUgaW50ZXJ2YWwgY2FuDQo+IGJlIGRldGVybWlu ZWQgdXNpbmcgU1RVTiAoZGlzY3Vzc2VkIGluDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM1NzgwKS4NCj4gDQo+IC1UaXJ1DQo+IA0KPiA+DQo+ID4gV2UgY2FuIGNvbnNpZGVyIG1h bnkgYXBwcm9hY2hlcyB0byBkZXRlY3QgYSBOQVQsIGUuZy4sDQo+ID4NCj4gPiAoMSkgVGhlIERP VFMgY2xpZW50IGluc2VydHMgaW4gdGhlIGNvcmUgbWVzc2FnZSB0aGUgSVAgYWRkcmVzcy9wb3J0 IGl0DQo+IHVzZXMgdG8NCj4gPiBzZW5kIHRoZSByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4g VXBvbiByZWNlaXB0IG9mIHRoZSByZXF1ZXN0IGJ5IHRoZQ0KPiA+IERPVFMgc2VydmVyLCBpdCBj aGVja3MgaWYgdGhlIGVuY2xvc2VkIElQIGFkZHJlc3MvcG9ydCBtYXRjaCB0aGUgc291cmNlDQo+ IElQDQo+ID4gYWRkcmVzcy9wb3J0IG9mIHRoZSByZWNlaXZlZCBwYWNrZXQuIElmIHllcywgdGhl IHNlcnZlciBzZXRzIGluIHRoZQ0KPiByZXNwb25zZSBhDQo+ID4gZGVkaWNhdGVkIHBhcmFtZXRl ciB0byBpbmRpY2F0ZSB0aGF0IGEgdHJhbnNsYXRvciBpcyBkZXRlY3RlZCBvbi1wYXRoLg0KPiA+ DQo+ID4gKDIpIFRoZSBET1RTIHNlcnZlciBpbnNlcnRzIHN5c3RlbWF0aWNhbGx5IHRoZSBzb3Vy Y2UgSVAgYWRkcmVzcy9wb3J0IGluDQo+IGENCj4gPiByZXNwb25zZSB0byBhIG1lc3NhZ2UgZnJv bSBhIERPVFMgY2xpZW50LiBVcG9uIHJlY2VpcHQgb2YgdGhhdCByZXNwb25zZSwNCj4gPiB0aGUg RE9UUyBjbGllbnQgY29tcGFyZXMgdGhlIGVuY2xvc2VkIGFkZHJlc3MvcG9ydCB3aXRoIHRoZSBv bmVzIGl0IHVzZWQNCj4gdG8NCj4gPiBzZW5kIHRoZSByZXF1ZXN0IHRvIGRldGVjdCBhbnkgbWlz bWF0Y2guDQo+ID4NCj4gPg0KPiA+ID4gLS0gRmxlbW1pbmcNCj4gPiA+DQo+ID4gPg0KPiA+ID4g PiBDaGVlcnMsDQo+ID4gPiA+IE1lZA0KPiA+ID4gPg0KPiA+ID4gPj4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+ID4gPiA+PiBEZcKgOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGll dGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvbiBTaGFsbG93DQo+ID4gPiA+PiBFbnZvecOpwqA6IGx1 bmRpIDIzIG9jdG9icmUgMjAxNyAxMzoxOCDDgMKgOiAnRmxlbW1pbmcgQW5kcmVhc2VuJzsNCj4g PiA+ID4+IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFtEb3RzXSBET1RTIFJlcXVpcmVtZW50 cyByZXZpZXcgKC0wNikNCj4gPiA+ID4+DQo+ID4gPiA+PiBIaSBGbGVtbWluZywNCj4gPiA+ID4+ DQo+ID4gPiA+PiBUaGUgd2F5IG15IG1pbmQgd29ya3MgaXMgdG8gdGhpbmsgb2YgYSBwcmFjdGlj YWwgc2l0dWF0aW9uIGFuZCBzZWUNCj4gPiA+ID4+IGlmIHRoaW5ncyBmaXQuDQo+ID4gPiA+Pg0K PiA+ID4gPj4gQXMgSSByZWFkIFNJRy0wMTAsIHRoZXJlIGNvdWxkIGJlIGEgRE9UUyBjbGllbnQg d2l0aCBhIG1hbmFnZW1lbnQNCj4gPiA+ID4+IElQIGFkZHJlc3MgdGhhdCBpcyBSRkMxOTE4IC0g dGhpcyBjbGllbnQgY291bGQgYmUgbW9uaXRvcmluZw0KPiA+ID4gPj4gTmV0ZmxvdyBpbmZvcm1h dGlvbiBhbmQgY2FuIHJlcXVlc3QgbWl0aWdhdGlvbiBmb3IgdGhlIGFwcHJvcHJpYXRlDQo+ID4g PiA+PiBwdWJsaWMgSVBzDQo+ID4gPiB0aGF0DQo+ID4gPiA+PiBhcmUgYmVpbmcgbW9uaXRvcmVk LiAgU28gU0lHLTAxMCBpcyBuZWVkZWQgZm9yIHRoaXMgdXNlIGNhc2UuDQo+ID4gPiA+Pg0KPiA+ ID4gPj4gSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBET1RTIHNlcnZlciBhcyB0byB3 aGV0aGVyIGl0DQo+ID4gPiA+PiBhY2NlcHRzIGEgbWl0aWdhdGlvbiByZXF1ZXN0IGZvciBhIHBh cnRpY3VsYXIgdGFyZ2V0IGlwIChvciBkb21haW4NCj4gZXRjLikgb3INCj4gPiBub3QuDQo+ID4g PiA+Pg0KPiA+ID4gPj4gSWYgdGhlcmUgaXMgZ29pbmcgdG8gYmUgYSBOQVQgYm9yZGVyIHdoZXJl IHB1YmxpYyBJUHMgYXJlIG1hcHBlZA0KPiA+ID4gPj4gaW50byBwcml2YXRlIElQcyAoYW5kIHZp Y2UgdmVyc2EpLCBJIHdvdWxkIHRoZW4gZXhwZWN0IHRoZXJlIHRvIGJlDQo+ID4gPiA+PiBhIERP VFMgZ2F0ZXdheSBiZXR3ZWVuIHRoZXNlIDIgem9uZXMsIGFuZCBpdCBpcyB0aGUgcmVzcG9uc2li aWxpdHkNCj4gPiA+ID4+IG9mIHRoZSBET1RTIGdhdGV3YXkgdG8gZG8gYW55IHRhcmdldC1pcCBt YXBwaW5ncy4NCj4gPiA+ID4+DQo+ID4gPiA+PiBSZWdhcmRzDQo+ID4gPiA+Pg0KPiA+ID4gPj4g Sm9uDQo+ID4gPiA+Pg0KPiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ ID4+IEZyb206IERvdHMgW21haWx0bzppZXRmLXN1cGpwcy1kb3RzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZg0KPiA+ID4gPj4gRmxlbW1pbmcgQW5kcmVhc2VuDQo+ID4gPiA+PiBTZW50 OiAyMiBPY3RvYmVyIDIwMTcgMjA6MTcNCj4gPiA+ID4+IFRvOiBkb3RzOyBkcmFmdC1pZXRmLWRv dHMtcmVxdWlyZW1lbnRzQGlldGYub3JnDQo+ID4gPiA+PiBTdWJqZWN0OiBbRG90c10gRE9UUyBS ZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpDQo+ID4gPiA+Pg0KPiA+ID4gPj4gR3JlZXRpbmdzDQo+ ID4gPiA+Pg0KPiA+ID4gPj4gSSBoYXZlIHJldmlld2VkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0 aGUgRE9UUyByZXF1aXJlbWVudHMgZHJhZnQNCj4gPiA+ID4+IChodHRwczovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTA2LnR4dCkuIEluDQo+ID4gPiBnZW5l cmFsLA0KPiA+ID4gPj4gSSB0aGluayB0aGUgZHJhZnQgaXMgaW4gZ29vZCBzaGFwZSB3aXRoIG9u bHkgYSBmZXcgZWRpdHMgcmVxdWlyZWQsDQo+ID4gPiA+PiBzbyBJIGhvcGUgd2UgY2FuIG1vdmUg dG8gV0dMQyBzb29uLiBJIGhhdmUgYSBmZXcgY29tbWVudHMgYmVsb3cgKG9mDQo+ID4gPiA+PiB3 aGljaA0KPiA+ID4gdGhlDQo+ID4gPiA+PiBOQVQgb25lIGlzIHRoZSBvbmx5IHJlYWwgc3Vic3Rh bnRpYWwgb25lKS4gSSBoYXZlIGFsc28gc3VibWl0dGVkIGENCj4gPiA+ID4+IHB1bGwgcmVxdWVz dCB3aXRoIGEgZmV3IG5pdCBmaXhlcyBvbiBHaXRIdWI6DQo+ID4gPiA+Pg0KPiA+ID4gPj4NCj4g PiA+ID4+IFNlY3Rpb24gMS4yDQo+ID4gPiA+PiAtIFRoZSBkZWZpbml0aW9uIG9mICJET1RTIFNp Z25hbCIgaXMgc2xpZ2h0bHkgaW5jb25zaXN0ZW50IHdpdGggdGhlDQo+ID4gPiA+PiByZXNwZWN0 aXZlICJDbGllbnQgU2lnbmFsIiBhbmQgIlNlcnZlciBTaWduYWwiIGRlZmluaXRpb25zLg0KPiA+ ID4gPj4NCj4gPiA+ID4+IFNJRy0wMDU6DQo+ID4gPiA+PiAtIE5vdCBjbGVhciB0aGF0IGFsd2F5 cyByZXF1aXJpbmcgIm51bWJlciBvZiBwYWNrZXRzIiBtZXRyaWNzIGlzDQo+ID4gPiA+PiBtZWFu aW5nZnVsLiBDb25zaWRlciBUQ1AtYmFzZWQgYXR0YWNrcyBmb3IgZXhhbXBsZS4gTnVtYmVyIG9m IGJ5dGVzDQo+ID4gPiA+PiBtYXkgYWx3YXlzIGJlIG9rIC0gYWJvdmUgYW5kIGJleW9uZCB0aGF0 IGl0IHNob3VsZCBwcm9iYWJseSBiZQ0KPiA+ID4gPj4gZXh0ZW5zaWJsZSBhbmQvb3IgYXR0YWNr IGRlcGVuZGVudC4NCj4gPiA+ID4+IC0gSSBkb24ndCB0aGluayB0aGUgcmVxdWlyZW1lbnRzIGRv Y3VtZW50IHNob3VsZCBnZXQgaW50bw0KPiA+ID4gPj4gc3BlY2lmeWluZw0KPiA+ID4gdGltZXIN Cj4gPiA+ID4+IHZhbHVlcyAtIGV4cG9udGlhbCBiYWNrb2ZmIHdpdGggc29tZSBtYXhpbXVtIHZh bHVlIHNlZW1zIGFib3V0IHRoZQ0KPiA+ID4gcmlnaHQNCj4gPiA+ID4+IGxldmVsIG9mIGRldGFp bCBoZXJlLg0KPiA+ID4gPj4NCj4gPiA+ID4+IFNJRy0wMDk6DQo+ID4gPiA+PiAtIFRvIGJlIGNs ZWFyLCB0aGUgY29uZmxpY3RzIG9ubHkgYXBwbHkgd2l0aGluIGEgc2luZ2xlDQo+ID4gPiA+PiBh ZG1pbmlzdHJhdGl2ZSBkb21haW4sIHJpZ2h0ID8gRm9yIGV4YW1wbGUsIGlmIGEgY2xpZW50IHRl bGxzIHRoZQ0KPiA+ID4gPj4gc2FtZSBkb21haW4gdG8gYWx0ZXJuYXRlbHkgdHVybiBvbi9vZmYg bWl0aWdhdGlvbiBmb3IgYSBnaXZlbg0KPiA+ID4gPj4gcHJlZml4LCByb3V0ZSBmbGFwcGluZw0K PiA+ID4gbWF5DQo+ID4gPiA+PiBvY2N1ci4gVGhlIHNhbWUgY29uY2VybiBkb2VzIG5vdCBhcHBs eSBpZiBhIGNsaWVudCB0ZWxscyB0d28NCj4gPiA+ID4+IGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2 ZSBkb21haW5zIHRvIHJlc3BlY3RpdmUgdHVybiBtaXRpZ2F0aW9uIG9uDQo+ID4gPiA+PiAoZG9t YWluIDEpIGFuZA0KPiA+ID4gb2ZmDQo+ID4gPiA+PiAoZG9tYWluIDIpLiBJZiBzbywgY2FuIHdl IGNsYXJpZnkgdGhhdCAoYWxzbyBpbiBsaWV1IG9mIHNvbWUgb2YgdGhlDQo+ID4gPiBtdWx0aS0N Cj4gPiA+ID4+IGhvbWluZyBjb21tZW50cyByYWlzZWQgcHJldmlvdXNseSkgPw0KPiA+ID4gPj4N Cj4gPiA+ID4+IFNJRy0wMTA6DQo+ID4gPiA+PiAtIERPVFMgQ2xpZW50IGJlaGluZCBOQVQuIE9u IG9uZSBoYW5kLCBpdCBzZWVtcyByZWFzb25hYmxlIHRvIGhhdmUNCj4gPiA+ID4+IHRoaXMgcmVx dWlyZW1lbnQgc2luY2UgY2xpZW50cyBmb3Igc3VyZSBjYW4gYmUgYmVoaW5kIE5BVHMsIGFuZA0K PiB3aXRoDQo+ID4gdGhpbmdzDQo+ID4gPiA+PiBsaWtlIGR5bmFtaWMgRE5TLCB0aGV5IGNhbiAg ICAgY2VydGFpbmx5IGJlIHJlYWNoYWJsZS4gSG93ZXZlciwgaWYNCj4gd2UNCj4gPiA+IGRvDQo+ ID4gPiA+PiB3YW50IHRvIGFsbG93IGZvciB0aGlzIHNjZW5hcmlvLCBhbmQgaW4gcGFydGljdWxh ciBmb3IgdGhlIERPVFMNCj4gPiA+ID4+IGNsaWVudA0KPiA+ID4gdG8NCj4gPiA+ID4+IGhhdmUg YSBwcml2YXRlIElQLWFkZHJlc3MgKHBvdGVudGlhbGx5IGJlaGluZCBtdWx0aXBsZSBOQVRzKSwg dGhlbg0KPiA+ID4gPj4gd2UNCj4gPiA+IGhhdmUNCj4gPiA+ID4+IG1vcmUgd29yayB0byBkbyBi ZWNhdXNlIGl0IHdvbid0IGRvIHRoZSBET1RTIHNlcnZlciBhbnkgZ29vZCB0byBnZXQNCj4gPiA+ ID4+IGEgbWl0aWdhdGlvbiByZXF1ZXN0IHJlZmVycmluZyB0byB0aGF0IHByaXZhdGUgSVAtYWRk cmVzcyAob3INCj4gcHJlZml4KS4NCj4gPiA+ID4+DQo+ID4gPiA+Pg0KPiA+ID4gPj4gVGhhbmtz DQo+ID4gPiA+Pg0KPiA+ID4gPj4gLS0gRmxlbW1pbmcNCj4gPiA+ID4+DQo+ID4gPiA+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPj4gRG90 cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4+IERvdHNAaWV0Zi5vcmcNCj4gPiA+ID4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+ID4gPj4NCj4gPiA+ID4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+PiBE b3RzIG1haWxpbmcgbGlzdA0KPiA+ID4gPj4gRG90c0BpZXRmLm9yZw0KPiA+ID4gPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4gPiA+IC4NCj4gPiA+ID4N Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiBEb3RzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo= From nobody Thu Oct 26 01:37:28 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DDA13F44E for ; Thu, 26 Oct 2017 01:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 USBw09YUVZ88 for ; Thu, 26 Oct 2017 01:37:24 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 C57CD13AB34 for ; Thu, 26 Oct 2017 01:37:23 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509007032; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=B /NdAATJ8SQb2z7+/8lGs2B9a0P5bpN2PMH9WzA2ys k=; b=RZxnj4v4W02mScPL8tuyRPc801zA7iIcolcpvvuKpgwm L8AH9/j5UJETd68x443WeRiPKMbAM2zDzaM3d/xjQoRcTG/Uj6 z9ydiYd4XWC1Gyug6Ly3X+GvND+eGso0AQmnwqJPUAiCRxFmH1 KeJzYfMaCV+jECcznzxIqEolycc= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c1b_63b2_fd2b068c_f664_4085_b119_197bac0260e8; Thu, 26 Oct 2017 03:37:11 -0500 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 02:36:29 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 02:36:28 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 26 Oct 2017 02:36:27 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 02:36:27 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 26 Oct 2017 08:36:26 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0156.007; Thu, 26 Oct 2017 08:36:26 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Flemming Andreasen" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAGjp6AACQhAAAAYgT5UAABUQNgAACCGwA= Date: Thu, 26 Oct 2017 08:36:25 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:HYCE8c/XzAzeBgqnPBQoWq68srkiaWWUwLiZx55HS0GhA6U1mGLMftfIpKX8mN2XsyuAIC3dpzOKHcFa4IaRwQLlR1XtgSA0mUPGP3OAjqPPYq0mhkgroq51DPvEXtFWUnzNCJRfyhPe4at3ze45yhojtJYTWteSr92Ye0kIn+1YPOhr9m3aKNzANBC3+1wQ6e8AmABG9a7x+FJd1Ne7Tcq4dYoshwCmJv0dunEMl5g7CI5Rr8NkOcSRXYCw6eiKJ4LLPXs2imL04xSYpbNZ32cvH7CpFsVbo8J/OOMHTqASoORzS3L3VebE6cVQJgdyyvYN8SsfNkn2xmQ/z/H5Mw==; 5:/jRSQG4xh8g3QQAXRmqY5tgSzkLAPvhE5TZyhV60Jm4qvIr45ufogmAVv5w2I/rmrL3RQzPYsRC9rGKlgglXC16CAjNv3+mPlvSJqDPjNwiNdTP/JTj2vggt0dN+aECDvl34lgy1K0fYr6oN1X0NIA==; 24:C+s8FoIJ2/YOa7skPhG+Sl+sqehS9G22omcCTk12KluG9WMcRIUEy9XV1OdUrjQS8sTmrwvWvYYVa7K5uZp3+9ZZSAxBPQXJgTuu/Y8ZbVU=; 7:tGcIR5ZsG2r67wU9yxCyRm5BMR7h7uGid6Kn5TBF1Ku96xMMPYizxuySZtxgfGOgBrJVNYowUbpZ54XpoiU/GMowDaMIDpMFIB9BJBKyAsryEQNYYYy69TcW0xsA2CEPNztkl8twwNv46dQsUnYFKVxSzv5lqX+uBnSyOGLKGPE1cwKE5mUjtUyh75kO3JIkmVlaB5l2gtMmeUoAvx7cm7LEp5X+JFL2iCo6A8nhsbg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 792de679-9089-4fac-ec74-08d51c4ca565 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603238); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(788757137089)(95692535739014)(18271650672692)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3231020)(6041248)(20161123560025)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(55784002)(13464003)(24454002)(32952001)(189002)(199003)(6246003)(966005)(3660700001)(72206003)(6436002)(53546010)(478600001)(8936002)(3846002)(6116002)(102836003)(6506006)(77096006)(101416001)(74316002)(2906002)(229853002)(7736002)(305945005)(66066001)(3280700002)(86362001)(76176999)(14454004)(106356001)(105586002)(81166006)(81156014)(561944003)(189998001)(80792005)(7696004)(50986999)(110136005)(97736004)(68736007)(33656002)(2900100001)(2950100002)(316002)(6306002)(99286003)(8676002)(55016002)(93886005)(9686003)(53936002)(25786009)(5660300001)(2501003)(54356999)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 792de679-9089-4fac-ec74-08d51c4ca565 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 08:36:25.9711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6144> : inlines <6146> : streams <1768454> : uri <2522613> Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 08:37:27 -0000 QnV0IE5BVHMgYXJlIG5vdCB0aGUgb25seSBwcm9ibGVtLCBmaXJld2FsbHMgd2lsbCBhbHNvIGJl IG1vc3QgbGlrZWx5IHByZXNlbnQsIGFuZCBTVFVOIGhlbHBzIGRpc2NvdmVyIGJvdGggTkFUcyBh bmQgZmlyZXdhbGxzIGFuZCB1c2VmdWwgZXZlbiBpbiBJUHY2IG5ldHdvcmtzIHRvIGRldGVybWlu ZSB0aGUga2VlcGFsaXZlIGludGVydmFsIG9mIGZpcmV3YWxsLg0KDQotVGlydQ0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20NCj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPiBTZW50OiBUaHVy c2RheSwgT2N0b2JlciAyNiwgMjAxNyAxOjUyIFBNDQo+IFRvOiBLb25kYSwgVGlydW1hbGVzd2Fy IFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsNCj4gRmxlbW1pbmcg QW5kcmVhc2VuIDxmYW5kcmVhc0BjaXNjby5jb20+OyBKb24gU2hhbGxvdyA8c3VwanBzLQ0KPiBp ZXRmQGpwc2hhbGxvdy5jb20+OyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbRG90c10g RE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQo+IA0K PiBUaXJ1LA0KPiANCj4gWWVzLCBTVFVOIGNhbiBiZSBsaXN0ZWQgYXMgcGFydCBvZiB0aGUgZXhp c3RpbmcgdG9vbHMgYm94IChhbW9uZyB0aGUgbGluZXMgb2YNCj4gd2hhdCBpcyBhbHJlYWR5IGRp c2N1c3NlZCBpbiA4MDg1KS4NCj4gDQo+IEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBtYWtlcyBzZW5z ZSB0byByZXF1aXJlIFNUVU4gc3VwcG9ydCBieSBET1RTIGNsaWVudHMuDQo+IA0KPiBUaGUgcHJv cG9zYWwgaXMgdG8gaW5jbHVkZSBhIHNpbXBsZSBidWlsdC1pbiBmZWF0dXJlIGluIHRoZSBET1RT IHByb3RvY29sIGl0c2VsZg0KPiB0aGF0IGNhbiBoZWxwIHRvIGRldGVjdCBOQVRzLiBUaGUgc3Vw cG9ydCBvZiBzdWNoIGZlYXR1cmUgd2lsbCwgZS5nLiwgZWFzZQ0KPiB0cm91Ymxlc2hvb3Rpbmcg d2hlbiBjb25uZWN0aXZpdHkgcHJvYmxlbXMgYXJlIGV4cGVyaWVuY2VkIG9uIHRoZSBwYXRoDQo+ IGJldHdlZW4gYSBjbGllbnQgYW5kIGEgc2VydmVyLg0KPiANCj4gQ2hlZXJzLA0KPiBNZWQNCj4g DQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGXCoDogS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeQ0KPiA+IFttYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVl LmNvbV0NCj4gPiBFbnZvecOpwqA6IGpldWRpIDI2IG9jdG9icmUgMjAxNyAwOTo0NA0KPiA+IMOA wqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNo YWxsb3c7DQo+ID4gZG90c0BpZXRmLm9yZyBPYmpldMKgOiBSRTogW0RvdHNdIERPVFMgJiBOQVQg KHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMNCj4gPiByZXZpZXcgKC0wNikpDQo+ID4NCj4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBEb3RzIFttYWlsdG86ZG90 cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiA+IG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20NCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjQsIDIwMTcgMjoyMCBQ TQ0KPiA+ID4gVG86IEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPjsgSm9u IFNoYWxsb3cgPHN1cGpwcy0NCj4gPiA+IGlldGZAanBzaGFsbG93LmNvbT47IGRvdHNAaWV0Zi5v cmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJl cXVpcmVtZW50cyByZXZpZXcNCj4gPiA+ICgtMDYpKQ0KPiA+ID4NCj4gPiA+IEhpIEZsZW1taW5n LCBhbGwsDQo+ID4gPg0KPiA+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPg0KPiA+ID4gQ2hl ZXJzLA0KPiA+ID4gTWVkDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gPiA+ID4gRGXCoDogRmxlbW1pbmcgQW5kcmVhc2VuIFttYWlsdG86ZmFuZHJlYXNAY2lz Y28uY29tXSBFbnZvecOpwqA6IGx1bmRpDQo+ID4gPiA+IDIzIG9jdG9icmUgMjAxNyAxNzozNiDD gMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBKb24gU2hhbGxvdzsNCj4gPiA+ID4gZG90 c0BpZXRmLm9yZyBPYmpldMKgOiBSZTogRE9UUyAmIE5BVCAod2FzIFJFOiBbRG90c10gRE9UUw0K PiA+ID4gPiBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ ID4gPg0KPiA+ID4gPiBPbiAxMC8yMy8xNyA4OjI4IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIHdyb3RlOg0KPiA+ID4gPiA+IEhpIEpvbiwgYWxsLA0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gSSBhZ3JlZSB3aXRoIEZsZW1taW5nIHRoYXQgInNvbWUgbW9yZSB3b3JrIiBpcyBuZWVkZWQu IElNSE8sDQo+ID4gPiA+ID4gdGhpcyBpcyBhDQo+ID4gPiA+IHR5cGljYWwgZGlzY3Vzc2lvbiB0 byBpbmNsdWRlIGluIGEgZGVkaWNhdGVkIHNlY3Rpb24gaW4gdGhlIERPVFMNCj4gPiA+ID4gYXJj aGl0ZWN0dXJlIEktRC4NCj4gPiA+ID4gQWdyZWVkLg0KPiA+ID4gPiA+ID5Gcm9tIGEgcmVxdWly ZW1lbnQgc3RhbmRwb2ludCwgd2UgZG9uJ3QgbmVlZCB0byBlbGFib3JhdGUgaG93DQo+ID4gPiA+ ID4gPnRoZQ0KPiA+ID4gPiBwcm90b2NvbHMgd2lsbCBmdWxmaWwgaXQuIFNJRy0xMCBkb2VzIGV2 ZW4gYSBuaWNlIGpvYiBieSBjaXRpbmcNCj4gPiA+ID4gUkZDODA4NSB3aGljaCBwb2ludHMgdG8g TkFUIHRyYXZlcnNhbCBtZWNoYW5pc21zLiBPbmUgY291bGQgcGljaw0KPiA+ID4gPiBoaXMvaGVy IGZhdm9yaXRlIHByb3RvY29sIGZyb20gdGhlIGxpc3QgaW4gODA4NSB0byBkaXNjb3ZlciB0aGUN Cj4gPiA+ID4gZXh0ZXJuYWwgSVAgYWRkcmVzcy9wcmVmaXgsIGlmIG5lZWRlZC4gRXh0ZXJuYWwg SVANCj4gPiA+ID4gYWRkcmVzc2VzL3ByZWZpeGVzIGNhbiBiZSBJUHY0IGZvciBhIE5BVDQ0IG9y IE5BVDY0LCBidXQgY2FuIGJlDQo+ID4gPiA+IElQdjYgcHJlZml4ZXMgZm9yIGVudGVycHJpc2Vz IGRlcGxveWluZyBOUFR2NiwgYW5kIHNvIG9uLg0KPiA+ID4gPiBQYXJ0IG9mIHRoZSBjaGFsbGVu Z2UgaGVyZSBpcyB0aGF0IHRoZSBhdHRhY2sgdGFyZ2V0IGFuZCB0aGUgRE9UUw0KPiA+ID4gPiBj bGllbnQgYXJlIG5vdCBuZWNlc3NhcmlseSBvbmUgYW5kIHRoZSBzYW1lLCB3aGljaCBtYWtlcyBp dCBtb3JlDQo+ID4gPiA+IGRpZmZpY3VsdCB0byBkZXRlcm1pbmUgdGhlIHB1YmxpYy1mYWNpbmcg SVAtYWRkcmVzcy9wb3J0IHVuZGVyDQo+ID4gPiA+IGF0dGFjayAoYXQgbGVhc3QgaWYgdGhlIERP VFMgY2xpZW50IGlzIGdvaW5nIHRvIGRvIGl0KS4NCj4gPiA+DQo+ID4gPiBbTWVkXSBUaGlzIGlz IGV4YWN0bHkgdGhlIGtpbmQgb2YgdGhlIGRpc2N1c3Npb24gdG8gaGF2ZS4gVGhhbmtzLg0KPiA+ ID4NCj4gPiA+IFdpdGggb3Igd2l0aG91dCBOQVQsIERPVFMgY2xpZW50cyBhcmUgYXNzdW1lZCB0 byBiZSBmZWQgd2l0aCB0aGUNCj4gPiBpbnRlcm5hbA0KPiA+ID4gdGFyZ2V0KHMpLiBUaGlzIGNh biBiZSBhY2hpZXZlZCBieSBwcm92aXNpb25pbmcgKGxpa2VseSkgb3IgYnkNCj4gPiA+IGRpc2Nv dmVyeQ0KPiA+IG1lYW5zDQo+ID4gPiAoZS5nLiwgcmVzaWRlbnRpYWwgb3Igc21hbGwgZW50ZXJw cmlzZSBuZXR3b3JrcykuDQo+ID4gPg0KPiA+ID4gQ2FuIHdlIGFzc3VtZSB0aGF0IHRoZSBkaXNj b3Zlcnkgb2YgdGhlIGV4dGVybmFsIElQDQo+ID4gPiBhZGRyZXNzL3ByZWZpeC8uLiBpcw0KPiA+ IGRvbmUNCj4gPiA+IGJ5IGEgRE9UUyBjbGllbnQgb25seSBpZiBpdCBpcyBleHBsaWNpdGx5IGlu c3RydWN0ZWQgdG8gZG8gc28/DQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gPiBJbiBzb21lIGRlcGxv eW1lbnRzLCBET1RTIGNsaWVudHMgbWF5IGJlIHByb3Zpc2lvbmVkIHdpdGggdGhlDQo+ID4gPiA+ ID4gc2V0IG9mDQo+ID4gPiA+IGludGVybmFsIHJlc291cmNlcywgc28gdGhlcmUgaXMgbm8gbmVl ZCBmb3IgZGlzY292ZXJ5Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQWxzbywgYXMgSm9uIG1lbnRp b25lZCwgRE9UUyBnYXRld2F5cyBjYW4gYmUgb2YgaGVscCB0byBzZXQgdGhlDQo+ID4gPiA+IGFw cHJvcHJpYXRlIElQIGFkZHJlc3Nlcy9wcmVmaXhlcy9wb3J0IG51bWJlcnMgaW4gdGhlIHByZXNl bmNlIG9mDQo+ID4gPiA+IHRyYW5zbGF0b3JzLg0KPiA+ID4gPiBBZ3JlZWQgLSBidXQgdGhleSBz dGlsbCBuZWVkIGEgd2F5IHRvIGZpZ3VyZSBvdXQgdGhlDQo+ID4gPiA+IHByaXZhdGUvcHVibGlj IG1hcHBpbmcgZm9yIGEgZ2l2ZW4gYXR0YWNrIHRhcmdldC4NCj4gPiA+DQo+ID4gPiBbTWVkXSBC ZWNhdXNlIGEgRERvUyBhdHRhY2sgaXMgb2JzZXJ2ZWQgZnJvbSB0aGUgaW50ZXJuYWwgbmV0d29y aywNCj4gPiA+IG1hcHBpbmcocykgYXJlIG5lY2Vzc2FyaWx5IG1haW50YWluZWQgYnkgdGhlIG9u LXBhdGggdHJhbnNsYXRvcihzKS4NCj4gPiA+IE90aGVyd2lzZSwgdGhlIGluY29taW5nIGF0dGFj ayB0cmFmZmljIGNvdWxkbid0IGJlIGZvcndhcmRlZCB0bw0KPiA+ID4gaW50ZXJuYWwNCj4gPiBo b3N0cy4NCj4gPiA+IFRoaXMgbW9kZWwgYXNzdW1lcyB0aGF0IHRoZSBnYXRld2F5IGlzIGNvbGxv Y2F0ZWQgd2l0aCB0aGUgTkFULiBTbywNCj4gPiA+IHRoZSBnYXRld2F5IGNhbiByZXBsYWNlIHRo ZSBpbnRlcm5hbCBJUCBhZGRyZXNzL3ByZWZpeCB3aXRoIHRoZSBvbmUNCj4gPiByZXRyaWV2ZXMN Cj4gPiA+IGZyb20gdGhlIE5BVCBtYXBwaW5nIHRhYmxlLg0KPiA+ID4NCj4gPiA+IERvIHlvdSBz ZWUgYW55IGlzc3VlIHdpdGggdGhpcyBzY2hlbWU/DQo+ID4gPg0KPiA+ID4gPiA+IEFuIG9wZW4g cXVlc3Rpb24gdGhvdWdoIHdvdWxkIGJlIHRvIGRpc2N1c3MgaWYgdGhlcmUgaXMgYSB2YWx1ZQ0K PiA+ID4gPiA+IGluDQo+ID4gPiA+IGhhdmluZyBhIGZlYXR1cmUgaW4gdGhlIERPVFMgcHJvdG9j b2wgdG8gaW5mb3JtIGEgRE9UUyBjbGllbnQgdGhhdA0KPiA+ID4gPiBhIE5BVCBpcyBkZXRlY3Rl ZCBvbi1wYXRoLiBUaGlzIGNhbiBiZSBwcmVzZW50ZWQgYXMgYW4gaW5mb3JtYXRpb24NCj4gPiA+ ID4gZWxlbWVudCByZXR1cm5lZCBieSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQuIFRoaXMgaW5m b3JtYXRpb24gY2FuDQo+ID4gPiA+IGJlLCBmb3IgZXhhbXBsZSwgdXNlZCBieSB0aGUgY2xpZW50 IHRvIGFkanVzdCBpdHMgSFQgaW50ZXJ2YWwsDQo+ID4gPiA+IGFkanVzdCB0aGUgaW50ZXJuYWwg SVAgYWRkcmVzc2VzL3ByZWZpeGVzIHRvIGJlIHByb3RlY3RlZCwgZXRjLiBPcGluaW9ucz8NCj4g PiA+ID4gSXQgc291bmRzIGFwcGVhbGluZywgYnV0IGl0J3MgdmVyeSBkaWZmaWN1bHQgdG8gZG8g dGhpcyByZWxpYWJseSwNCj4gPiA+ID4gYW5kIGl0J3Mgbm90IGp1c3QgTkFUcyB0aGF0IGFyZSBh biBpc3N1ZSBoZXJlOyBGaXJld2FsbHMgcHJlc2VudA0KPiA+ID4gPiBzaW1pbGFyIGNoYWxsZW5n ZXMgKGFuZCB0aGV5IG1heSBvciBtYXkgbm90IGJlIE5BVCdpbmcgaW5kaXZpZHVhbA0KPiBmbG93 cykuDQo+ID4gPiA+DQo+ID4gPg0KPiA+ID4gW01lZF0gSSBmdWxseSBhZ3JlZSB0aGF0IGZpcmV3 YWxscyBkZXRlY3QgaXMgbW9yZSBjb21wbGV4LiBMZXQncyBwdXQNCj4gPiA+IGl0DQo+ID4gYXNp ZGUNCj4gPiA+IGFuZCBmb2N1cyBvbiB0aGUgTkFUIGNhc2UuDQo+ID4NCj4gPiBUaGUgcHJlc2Vu Y2UgYW5kIGJlaGF2aW9yIG9mIE5BVCBhbmQgRmlyZXdhbGwsIGFuZCBrZWVwYWxpdmUgaW50ZXJ2 YWwNCj4gPiBjYW4gYmUgZGV0ZXJtaW5lZCB1c2luZyBTVFVOIChkaXNjdXNzZWQgaW4NCj4gPiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc4MCkuDQo+ID4NCj4gPiAtVGlydQ0KPiA+ DQo+ID4gPg0KPiA+ID4gV2UgY2FuIGNvbnNpZGVyIG1hbnkgYXBwcm9hY2hlcyB0byBkZXRlY3Qg YSBOQVQsIGUuZy4sDQo+ID4gPg0KPiA+ID4gKDEpIFRoZSBET1RTIGNsaWVudCBpbnNlcnRzIGlu IHRoZSBjb3JlIG1lc3NhZ2UgdGhlIElQIGFkZHJlc3MvcG9ydA0KPiA+ID4gaXQNCj4gPiB1c2Vz IHRvDQo+ID4gPiBzZW5kIHRoZSByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4gVXBvbiByZWNl aXB0IG9mIHRoZSByZXF1ZXN0IGJ5DQo+ID4gPiB0aGUgRE9UUyBzZXJ2ZXIsIGl0IGNoZWNrcyBp ZiB0aGUgZW5jbG9zZWQgSVAgYWRkcmVzcy9wb3J0IG1hdGNoIHRoZQ0KPiA+ID4gc291cmNlDQo+ ID4gSVANCj4gPiA+IGFkZHJlc3MvcG9ydCBvZiB0aGUgcmVjZWl2ZWQgcGFja2V0LiBJZiB5ZXMs IHRoZSBzZXJ2ZXIgc2V0cyBpbiB0aGUNCj4gPiByZXNwb25zZSBhDQo+ID4gPiBkZWRpY2F0ZWQg cGFyYW1ldGVyIHRvIGluZGljYXRlIHRoYXQgYSB0cmFuc2xhdG9yIGlzIGRldGVjdGVkIG9uLXBh dGguDQo+ID4gPg0KPiA+ID4gKDIpIFRoZSBET1RTIHNlcnZlciBpbnNlcnRzIHN5c3RlbWF0aWNh bGx5IHRoZSBzb3VyY2UgSVANCj4gPiA+IGFkZHJlc3MvcG9ydCBpbg0KPiA+IGENCj4gPiA+IHJl c3BvbnNlIHRvIGEgbWVzc2FnZSBmcm9tIGEgRE9UUyBjbGllbnQuIFVwb24gcmVjZWlwdCBvZiB0 aGF0DQo+ID4gPiByZXNwb25zZSwgdGhlIERPVFMgY2xpZW50IGNvbXBhcmVzIHRoZSBlbmNsb3Nl ZCBhZGRyZXNzL3BvcnQgd2l0aA0KPiA+ID4gdGhlIG9uZXMgaXQgdXNlZA0KPiA+IHRvDQo+ID4g PiBzZW5kIHRoZSByZXF1ZXN0IHRvIGRldGVjdCBhbnkgbWlzbWF0Y2guDQo+ID4gPg0KPiA+ID4N Cj4gPiA+ID4gLS0gRmxlbW1pbmcNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gPiBDaGVlcnMs DQo+ID4gPiA+ID4gTWVkDQo+ID4gPiA+ID4NCj4gPiA+ID4gPj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+ID4gPiA+ID4+IERlwqA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0 Zi5vcmddIERlIGxhIHBhcnQgZGUgSm9uDQo+ID4gPiA+ID4+IFNoYWxsb3cgRW52b3nDqcKgOiBs dW5kaSAyMyBvY3RvYnJlIDIwMTcgMTM6MTggw4DCoDogJ0ZsZW1taW5nDQo+ID4gPiA+ID4+IEFu ZHJlYXNlbic7IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFtEb3RzXSBET1RTIFJlcXVpcmVt ZW50cw0KPiA+ID4gPiA+PiByZXZpZXcgKC0wNikNCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gSGkg RmxlbW1pbmcsDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFRoZSB3YXkgbXkgbWluZCB3b3JrcyBp cyB0byB0aGluayBvZiBhIHByYWN0aWNhbCBzaXR1YXRpb24gYW5kDQo+ID4gPiA+ID4+IHNlZSBp ZiB0aGluZ3MgZml0Lg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBBcyBJIHJlYWQgU0lHLTAxMCwg dGhlcmUgY291bGQgYmUgYSBET1RTIGNsaWVudCB3aXRoIGENCj4gPiA+ID4gPj4gbWFuYWdlbWVu dCBJUCBhZGRyZXNzIHRoYXQgaXMgUkZDMTkxOCAtIHRoaXMgY2xpZW50IGNvdWxkIGJlDQo+ID4g PiA+ID4+IG1vbml0b3JpbmcgTmV0ZmxvdyBpbmZvcm1hdGlvbiBhbmQgY2FuIHJlcXVlc3QgbWl0 aWdhdGlvbiBmb3INCj4gPiA+ID4gPj4gdGhlIGFwcHJvcHJpYXRlIHB1YmxpYyBJUHMNCj4gPiA+ ID4gdGhhdA0KPiA+ID4gPiA+PiBhcmUgYmVpbmcgbW9uaXRvcmVkLiAgU28gU0lHLTAxMCBpcyBu ZWVkZWQgZm9yIHRoaXMgdXNlIGNhc2UuDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEl0IGlzIHRo ZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgRE9UUyBzZXJ2ZXIgYXMgdG8gd2hldGhlciBpdA0KPiA+ ID4gPiA+PiBhY2NlcHRzIGEgbWl0aWdhdGlvbiByZXF1ZXN0IGZvciBhIHBhcnRpY3VsYXIgdGFy Z2V0IGlwIChvcg0KPiA+ID4gPiA+PiBkb21haW4NCj4gPiBldGMuKSBvcg0KPiA+ID4gbm90Lg0K PiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBJZiB0aGVyZSBpcyBnb2luZyB0byBiZSBhIE5BVCBib3Jk ZXIgd2hlcmUgcHVibGljIElQcyBhcmUNCj4gPiA+ID4gPj4gbWFwcGVkIGludG8gcHJpdmF0ZSBJ UHMgKGFuZCB2aWNlIHZlcnNhKSwgSSB3b3VsZCB0aGVuIGV4cGVjdA0KPiA+ID4gPiA+PiB0aGVy ZSB0byBiZSBhIERPVFMgZ2F0ZXdheSBiZXR3ZWVuIHRoZXNlIDIgem9uZXMsIGFuZCBpdCBpcyB0 aGUNCj4gPiA+ID4gPj4gcmVzcG9uc2liaWxpdHkgb2YgdGhlIERPVFMgZ2F0ZXdheSB0byBkbyBh bnkgdGFyZ2V0LWlwIG1hcHBpbmdzLg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBSZWdhcmRzDQo+ ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEpvbg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+PiBGcm9tOiBEb3RzIFttYWlsdG86aWV0Zi1z dXBqcHMtZG90cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiA+ID4gPj4gT2YgRmxl bW1pbmcgQW5kcmVhc2VuDQo+ID4gPiA+ID4+IFNlbnQ6IDIyIE9jdG9iZXIgMjAxNyAyMDoxNw0K PiA+ID4gPiA+PiBUbzogZG90czsgZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50c0BpZXRmLm9y Zw0KPiA+ID4gPiA+PiBTdWJqZWN0OiBbRG90c10gRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgt MDYpDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEdyZWV0aW5ncw0KPiA+ID4gPiA+Pg0KPiA+ID4g PiA+PiBJIGhhdmUgcmV2aWV3ZWQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBET1RTIHJlcXVp cmVtZW50cw0KPiA+ID4gPiA+PiBkcmFmdA0KPiA+ID4gPiA+PiAoaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0wNi50eHQpLg0KPiA+ID4gPiA+PiBJ bg0KPiA+ID4gPiBnZW5lcmFsLA0KPiA+ID4gPiA+PiBJIHRoaW5rIHRoZSBkcmFmdCBpcyBpbiBn b29kIHNoYXBlIHdpdGggb25seSBhIGZldyBlZGl0cw0KPiA+ID4gPiA+PiByZXF1aXJlZCwgc28g SSBob3BlIHdlIGNhbiBtb3ZlIHRvIFdHTEMgc29vbi4gSSBoYXZlIGEgZmV3DQo+ID4gPiA+ID4+ IGNvbW1lbnRzIGJlbG93IChvZiB3aGljaA0KPiA+ID4gPiB0aGUNCj4gPiA+ID4gPj4gTkFUIG9u ZSBpcyB0aGUgb25seSByZWFsIHN1YnN0YW50aWFsIG9uZSkuIEkgaGF2ZSBhbHNvDQo+ID4gPiA+ ID4+IHN1Ym1pdHRlZCBhIHB1bGwgcmVxdWVzdCB3aXRoIGEgZmV3IG5pdCBmaXhlcyBvbiBHaXRI dWI6DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFNlY3Rpb24gMS4yDQo+ID4g PiA+ID4+IC0gVGhlIGRlZmluaXRpb24gb2YgIkRPVFMgU2lnbmFsIiBpcyBzbGlnaHRseSBpbmNv bnNpc3RlbnQgd2l0aA0KPiA+ID4gPiA+PiB0aGUgcmVzcGVjdGl2ZSAiQ2xpZW50IFNpZ25hbCIg YW5kICJTZXJ2ZXIgU2lnbmFsIiBkZWZpbml0aW9ucy4NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4g U0lHLTAwNToNCj4gPiA+ID4gPj4gLSBOb3QgY2xlYXIgdGhhdCBhbHdheXMgcmVxdWlyaW5nICJu dW1iZXIgb2YgcGFja2V0cyIgbWV0cmljcw0KPiA+ID4gPiA+PiBpcyBtZWFuaW5nZnVsLiBDb25z aWRlciBUQ1AtYmFzZWQgYXR0YWNrcyBmb3IgZXhhbXBsZS4gTnVtYmVyDQo+ID4gPiA+ID4+IG9m IGJ5dGVzIG1heSBhbHdheXMgYmUgb2sgLSBhYm92ZSBhbmQgYmV5b25kIHRoYXQgaXQgc2hvdWxk DQo+ID4gPiA+ID4+IHByb2JhYmx5IGJlIGV4dGVuc2libGUgYW5kL29yIGF0dGFjayBkZXBlbmRl bnQuDQo+ID4gPiA+ID4+IC0gSSBkb24ndCB0aGluayB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50 IHNob3VsZCBnZXQgaW50bw0KPiA+ID4gPiA+PiBzcGVjaWZ5aW5nDQo+ID4gPiA+IHRpbWVyDQo+ ID4gPiA+ID4+IHZhbHVlcyAtIGV4cG9udGlhbCBiYWNrb2ZmIHdpdGggc29tZSBtYXhpbXVtIHZh bHVlIHNlZW1zIGFib3V0DQo+ID4gPiA+ID4+IHRoZQ0KPiA+ID4gPiByaWdodA0KPiA+ID4gPiA+ PiBsZXZlbCBvZiBkZXRhaWwgaGVyZS4NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gU0lHLTAwOToN Cj4gPiA+ID4gPj4gLSBUbyBiZSBjbGVhciwgdGhlIGNvbmZsaWN0cyBvbmx5IGFwcGx5IHdpdGhp biBhIHNpbmdsZQ0KPiA+ID4gPiA+PiBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIHJpZ2h0ID8gRm9y IGV4YW1wbGUsIGlmIGEgY2xpZW50IHRlbGxzDQo+ID4gPiA+ID4+IHRoZSBzYW1lIGRvbWFpbiB0 byBhbHRlcm5hdGVseSB0dXJuIG9uL29mZiBtaXRpZ2F0aW9uIGZvciBhDQo+ID4gPiA+ID4+IGdp dmVuIHByZWZpeCwgcm91dGUgZmxhcHBpbmcNCj4gPiA+ID4gbWF5DQo+ID4gPiA+ID4+IG9jY3Vy LiBUaGUgc2FtZSBjb25jZXJuIGRvZXMgbm90IGFwcGx5IGlmIGEgY2xpZW50IHRlbGxzIHR3bw0K PiA+ID4gPiA+PiBkaWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUgZG9tYWlucyB0byByZXNwZWN0aXZl IHR1cm4gbWl0aWdhdGlvbg0KPiA+ID4gPiA+PiBvbiAoZG9tYWluIDEpIGFuZA0KPiA+ID4gPiBv ZmYNCj4gPiA+ID4gPj4gKGRvbWFpbiAyKS4gSWYgc28sIGNhbiB3ZSBjbGFyaWZ5IHRoYXQgKGFs c28gaW4gbGlldSBvZiBzb21lIG9mDQo+ID4gPiA+ID4+IHRoZQ0KPiA+ID4gPiBtdWx0aS0NCj4g PiA+ID4gPj4gaG9taW5nIGNvbW1lbnRzIHJhaXNlZCBwcmV2aW91c2x5KSA/DQo+ID4gPiA+ID4+ DQo+ID4gPiA+ID4+IFNJRy0wMTA6DQo+ID4gPiA+ID4+IC0gRE9UUyBDbGllbnQgYmVoaW5kIE5B VC4gT24gb25lIGhhbmQsIGl0IHNlZW1zIHJlYXNvbmFibGUgdG8NCj4gPiA+ID4gPj4gaGF2ZSB0 aGlzIHJlcXVpcmVtZW50IHNpbmNlIGNsaWVudHMgZm9yIHN1cmUgY2FuIGJlIGJlaGluZA0KPiA+ ID4gPiA+PiBOQVRzLCBhbmQNCj4gPiB3aXRoDQo+ID4gPiB0aGluZ3MNCj4gPiA+ID4gPj4gbGlr ZSBkeW5hbWljIEROUywgdGhleSBjYW4gICAgIGNlcnRhaW5seSBiZSByZWFjaGFibGUuIEhvd2V2 ZXIsIGlmDQo+ID4gd2UNCj4gPiA+ID4gZG8NCj4gPiA+ID4gPj4gd2FudCB0byBhbGxvdyBmb3Ig dGhpcyBzY2VuYXJpbywgYW5kIGluIHBhcnRpY3VsYXIgZm9yIHRoZSBET1RTDQo+ID4gPiA+ID4+ IGNsaWVudA0KPiA+ID4gPiB0bw0KPiA+ID4gPiA+PiBoYXZlIGEgcHJpdmF0ZSBJUC1hZGRyZXNz IChwb3RlbnRpYWxseSBiZWhpbmQgbXVsdGlwbGUgTkFUcyksDQo+ID4gPiA+ID4+IHRoZW4gd2UN Cj4gPiA+ID4gaGF2ZQ0KPiA+ID4gPiA+PiBtb3JlIHdvcmsgdG8gZG8gYmVjYXVzZSBpdCB3b24n dCBkbyB0aGUgRE9UUyBzZXJ2ZXIgYW55IGdvb2QgdG8NCj4gPiA+ID4gPj4gZ2V0IGEgbWl0aWdh dGlvbiByZXF1ZXN0IHJlZmVycmluZyB0byB0aGF0IHByaXZhdGUgSVAtYWRkcmVzcw0KPiA+ID4g PiA+PiAob3INCj4gPiBwcmVmaXgpLg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ PiBUaGFua3MNCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gLS0gRmxlbW1pbmcNCj4gPiA+ID4gPj4N Cj4gPiA+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiA+ID4gPj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPj4gRG90c0BpZXRmLm9y Zw0KPiA+ID4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMN Cj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiA+ID4gPj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPj4g RG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RvdHMNCj4gPiA+ID4gPiAuDQo+ID4gPiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRG90cyBtYWls aW5nIGxpc3QNCj4gPiA+IERvdHNAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Thu Oct 26 01:50:40 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB5513F42A for ; Thu, 26 Oct 2017 01:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbzw9ogcZZed for ; Thu, 26 Oct 2017 01:50:37 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4C113ACAB for ; Thu, 26 Oct 2017 01:50:37 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id E3B07120551; Thu, 26 Oct 2017 10:50:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id C572F18006E; Thu, 26 Oct 2017 10:50:35 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0361.001; Thu, 26 Oct 2017 10:50:35 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Flemming Andreasen" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAGjp6AACQhAAAAYgT5UAABUQNgAACCGwAAAIl5gA== Date: Thu, 26 Oct 2017 08:50:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 08:50:39 -0000 UmUtLA0KDQpJIGhlYXIgeW91LiBNeSB0YWtlIGlzIHRoYXQgd2UgZG9uJ3QgbmVlZCB0byByZWNv bW1lbmQgd2hpY2ggY29tcGFuaW9uICJwcm90b2NvbHMvbWVjaGFuaXNtcyIgbmVlZCB0byBiZSBz dXBwb3J0ZWQgZm9yIE5BVC9GVyB0cmF2ZXJzYWwgcHVycG9zZXMuIEhhdmluZyBhIGRpc2N1c3Np b24gYXQgdGhlIHNhbWUgbGV2ZWwgaW4gODA4NSB3b3VsZCBiZSBzdWZmaWNpZW50LCBJTUhPLiAN Cg0KTGV0J3MgZm9jdXMgb24gdGhlIHNpbXBsZSBidWlsdC1pbiBmZWF0dXJlIGZvciBOQVQgZGV0 ZWN0LiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ IERlwqA6IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgW21haWx0bzpUaXJ1bWFsZXN3YXJSZWRk eV9Lb25kYUBNY0FmZWUuY29tXQ0KPiBFbnZvecOpwqA6IGpldWRpIDI2IG9jdG9icmUgMjAxNyAx MDozNg0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBGbGVtbWluZyBBbmRyZWFz ZW47IEpvbiBTaGFsbG93Ow0KPiBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJFOiBbRG90c10g RE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQo+IA0K PiBCdXQgTkFUcyBhcmUgbm90IHRoZSBvbmx5IHByb2JsZW0sIGZpcmV3YWxscyB3aWxsIGFsc28g YmUgbW9zdCBsaWtlbHkNCj4gcHJlc2VudCwgYW5kIFNUVU4gaGVscHMgZGlzY292ZXIgYm90aCBO QVRzIGFuZCBmaXJld2FsbHMgYW5kIHVzZWZ1bCBldmVuDQo+IGluIElQdjYgbmV0d29ya3MgdG8g ZGV0ZXJtaW5lIHRoZSBrZWVwYWxpdmUgaW50ZXJ2YWwgb2YgZmlyZXdhbGwuDQo+IA0KPiAtVGly dQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb21dDQo+ID4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjYsIDIwMTcgMTo1MiBQTQ0KPiA+ IFRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBN Y0FmZWUuY29tPjsNCj4gPiBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2NvLmNvbT47 IEpvbiBTaGFsbG93IDxzdXBqcHMtDQo+ID4gaWV0ZkBqcHNoYWxsb3cuY29tPjsgZG90c0BpZXRm Lm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJl cXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQo+ID4NCj4gPiBUaXJ1LA0KPiA+DQo+ID4gWWVzLCBT VFVOIGNhbiBiZSBsaXN0ZWQgYXMgcGFydCBvZiB0aGUgZXhpc3RpbmcgdG9vbHMgYm94IChhbW9u ZyB0aGUNCj4gbGluZXMgb2YNCj4gPiB3aGF0IGlzIGFscmVhZHkgZGlzY3Vzc2VkIGluIDgwODUp Lg0KPiA+DQo+ID4gSSBkb24ndCB0aGluayB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIHJlcXVpcmUg U1RVTiBzdXBwb3J0IGJ5IERPVFMNCj4gY2xpZW50cy4NCj4gPg0KPiA+IFRoZSBwcm9wb3NhbCBp cyB0byBpbmNsdWRlIGEgc2ltcGxlIGJ1aWx0LWluIGZlYXR1cmUgaW4gdGhlIERPVFMNCj4gcHJv dG9jb2wgaXRzZWxmDQo+ID4gdGhhdCBjYW4gaGVscCB0byBkZXRlY3QgTkFUcy4gVGhlIHN1cHBv cnQgb2Ygc3VjaCBmZWF0dXJlIHdpbGwsIGUuZy4sDQo+IGVhc2UNCj4gPiB0cm91Ymxlc2hvb3Rp bmcgd2hlbiBjb25uZWN0aXZpdHkgcHJvYmxlbXMgYXJlIGV4cGVyaWVuY2VkIG9uIHRoZSBwYXRo DQo+ID4gYmV0d2VlbiBhIGNsaWVudCBhbmQgYSBzZXJ2ZXIuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ ID4gTWVkDQo+ID4NCj4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gRGXC oDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+ID4gW21haWx0bzpUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KPiA+ID4gRW52b3nDqcKgOiBqZXVkaSAyNiBvY3RvYnJl IDIwMTcgMDk6NDQNCj4gPiA+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEZsZW1t aW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7DQo+ID4gPiBkb3RzQGlldGYub3JnIE9iamV0wqA6 IFJFOiBbRG90c10gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cw0KPiA+ID4g cmV2aWV3ICgtMDYpKQ0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiA+ID4gRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mDQo+ID4gPiA+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiA+ID4gU2Vu dDogVHVlc2RheSwgT2N0b2JlciAyNCwgMjAxNyAyOjIwIFBNDQo+ID4gPiA+IFRvOiBGbGVtbWlu ZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2NvLmNvbT47IEpvbiBTaGFsbG93IDxzdXBqcHMtDQo+ ID4gPiA+IGlldGZAanBzaGFsbG93LmNvbT47IGRvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVj dDogUmU6IFtEb3RzXSBET1RTICYgTkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJldmll dw0KPiA+ID4gPiAoLTA2KSkNCj4gPiA+ID4NCj4gPiA+ID4gSGkgRmxlbW1pbmcsIGFsbCwNCj4g PiA+ID4NCj4gPiA+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPiA+DQo+ID4gPiA+IENoZWVy cywNCj4gPiA+ID4gTWVkDQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+ID4gPiA+ID4gRGXCoDogRmxlbW1pbmcgQW5kcmVhc2VuIFttYWlsdG86ZmFuZHJl YXNAY2lzY28uY29tXSBFbnZvecOpwqA6IGx1bmRpDQo+ID4gPiA+ID4gMjMgb2N0b2JyZSAyMDE3 IDE3OjM2IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEpvbiBTaGFsbG93Ow0KPiA+ ID4gPiA+IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IERPVFMgJiBOQVQgKHdhcyBSRTogW0Rv dHNdIERPVFMNCj4gPiA+ID4gPiBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKQ0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9uIDEwLzIzLzE3IDg6MjggQU0sIG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gPiA+ID4gPiBIaSBKb24sIGFs bCwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJIGFncmVlIHdpdGggRmxlbW1pbmcgdGhhdCAi c29tZSBtb3JlIHdvcmsiIGlzIG5lZWRlZC4gSU1ITywNCj4gPiA+ID4gPiA+IHRoaXMgaXMgYQ0K PiA+ID4gPiA+IHR5cGljYWwgZGlzY3Vzc2lvbiB0byBpbmNsdWRlIGluIGEgZGVkaWNhdGVkIHNl Y3Rpb24gaW4gdGhlIERPVFMNCj4gPiA+ID4gPiBhcmNoaXRlY3R1cmUgSS1ELg0KPiA+ID4gPiA+ IEFncmVlZC4NCj4gPiA+ID4gPiA+ID5Gcm9tIGEgcmVxdWlyZW1lbnQgc3RhbmRwb2ludCwgd2Ug ZG9uJ3QgbmVlZCB0byBlbGFib3JhdGUgaG93DQo+ID4gPiA+ID4gPiA+dGhlDQo+ID4gPiA+ID4g cHJvdG9jb2xzIHdpbGwgZnVsZmlsIGl0LiBTSUctMTAgZG9lcyBldmVuIGEgbmljZSBqb2IgYnkg Y2l0aW5nDQo+ID4gPiA+ID4gUkZDODA4NSB3aGljaCBwb2ludHMgdG8gTkFUIHRyYXZlcnNhbCBt ZWNoYW5pc21zLiBPbmUgY291bGQgcGljaw0KPiA+ID4gPiA+IGhpcy9oZXIgZmF2b3JpdGUgcHJv dG9jb2wgZnJvbSB0aGUgbGlzdCBpbiA4MDg1IHRvIGRpc2NvdmVyIHRoZQ0KPiA+ID4gPiA+IGV4 dGVybmFsIElQIGFkZHJlc3MvcHJlZml4LCBpZiBuZWVkZWQuIEV4dGVybmFsIElQDQo+ID4gPiA+ ID4gYWRkcmVzc2VzL3ByZWZpeGVzIGNhbiBiZSBJUHY0IGZvciBhIE5BVDQ0IG9yIE5BVDY0LCBi dXQgY2FuIGJlDQo+ID4gPiA+ID4gSVB2NiBwcmVmaXhlcyBmb3IgZW50ZXJwcmlzZXMgZGVwbG95 aW5nIE5QVHY2LCBhbmQgc28gb24uDQo+ID4gPiA+ID4gUGFydCBvZiB0aGUgY2hhbGxlbmdlIGhl cmUgaXMgdGhhdCB0aGUgYXR0YWNrIHRhcmdldCBhbmQgdGhlIERPVFMNCj4gPiA+ID4gPiBjbGll bnQgYXJlIG5vdCBuZWNlc3NhcmlseSBvbmUgYW5kIHRoZSBzYW1lLCB3aGljaCBtYWtlcyBpdCBt b3JlDQo+ID4gPiA+ID4gZGlmZmljdWx0IHRvIGRldGVybWluZSB0aGUgcHVibGljLWZhY2luZyBJ UC1hZGRyZXNzL3BvcnQgdW5kZXINCj4gPiA+ID4gPiBhdHRhY2sgKGF0IGxlYXN0IGlmIHRoZSBE T1RTIGNsaWVudCBpcyBnb2luZyB0byBkbyBpdCkuDQo+ID4gPiA+DQo+ID4gPiA+IFtNZWRdIFRo aXMgaXMgZXhhY3RseSB0aGUga2luZCBvZiB0aGUgZGlzY3Vzc2lvbiB0byBoYXZlLiBUaGFua3Mu DQo+ID4gPiA+DQo+ID4gPiA+IFdpdGggb3Igd2l0aG91dCBOQVQsIERPVFMgY2xpZW50cyBhcmUg YXNzdW1lZCB0byBiZSBmZWQgd2l0aCB0aGUNCj4gPiA+IGludGVybmFsDQo+ID4gPiA+IHRhcmdl dChzKS4gVGhpcyBjYW4gYmUgYWNoaWV2ZWQgYnkgcHJvdmlzaW9uaW5nIChsaWtlbHkpIG9yIGJ5 DQo+ID4gPiA+IGRpc2NvdmVyeQ0KPiA+ID4gbWVhbnMNCj4gPiA+ID4gKGUuZy4sIHJlc2lkZW50 aWFsIG9yIHNtYWxsIGVudGVycHJpc2UgbmV0d29ya3MpLg0KPiA+ID4gPg0KPiA+ID4gPiBDYW4g d2UgYXNzdW1lIHRoYXQgdGhlIGRpc2NvdmVyeSBvZiB0aGUgZXh0ZXJuYWwgSVANCj4gPiA+ID4g YWRkcmVzcy9wcmVmaXgvLi4gaXMNCj4gPiA+IGRvbmUNCj4gPiA+ID4gYnkgYSBET1RTIGNsaWVu dCBvbmx5IGlmIGl0IGlzIGV4cGxpY2l0bHkgaW5zdHJ1Y3RlZCB0byBkbyBzbz8NCj4gPiA+ID4N Cj4gPiA+ID4NCj4gPiA+ID4gPiA+IEluIHNvbWUgZGVwbG95bWVudHMsIERPVFMgY2xpZW50cyBt YXkgYmUgcHJvdmlzaW9uZWQgd2l0aCB0aGUNCj4gPiA+ID4gPiA+IHNldCBvZg0KPiA+ID4gPiA+ IGludGVybmFsIHJlc291cmNlcywgc28gdGhlcmUgaXMgbm8gbmVlZCBmb3IgZGlzY292ZXJ5Lg0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEFsc28sIGFzIEpvbiBtZW50aW9uZWQsIERPVFMgZ2F0 ZXdheXMgY2FuIGJlIG9mIGhlbHAgdG8gc2V0IHRoZQ0KPiA+ID4gPiA+IGFwcHJvcHJpYXRlIElQ IGFkZHJlc3Nlcy9wcmVmaXhlcy9wb3J0IG51bWJlcnMgaW4gdGhlIHByZXNlbmNlIG9mDQo+ID4g PiA+ID4gdHJhbnNsYXRvcnMuDQo+ID4gPiA+ID4gQWdyZWVkIC0gYnV0IHRoZXkgc3RpbGwgbmVl ZCBhIHdheSB0byBmaWd1cmUgb3V0IHRoZQ0KPiA+ID4gPiA+IHByaXZhdGUvcHVibGljIG1hcHBp bmcgZm9yIGEgZ2l2ZW4gYXR0YWNrIHRhcmdldC4NCj4gPiA+ID4NCj4gPiA+ID4gW01lZF0gQmVj YXVzZSBhIEREb1MgYXR0YWNrIGlzIG9ic2VydmVkIGZyb20gdGhlIGludGVybmFsIG5ldHdvcmss DQo+ID4gPiA+IG1hcHBpbmcocykgYXJlIG5lY2Vzc2FyaWx5IG1haW50YWluZWQgYnkgdGhlIG9u LXBhdGggdHJhbnNsYXRvcihzKS4NCj4gPiA+ID4gT3RoZXJ3aXNlLCB0aGUgaW5jb21pbmcgYXR0 YWNrIHRyYWZmaWMgY291bGRuJ3QgYmUgZm9yd2FyZGVkIHRvDQo+ID4gPiA+IGludGVybmFsDQo+ ID4gPiBob3N0cy4NCj4gPiA+ID4gVGhpcyBtb2RlbCBhc3N1bWVzIHRoYXQgdGhlIGdhdGV3YXkg aXMgY29sbG9jYXRlZCB3aXRoIHRoZSBOQVQuIFNvLA0KPiA+ID4gPiB0aGUgZ2F0ZXdheSBjYW4g cmVwbGFjZSB0aGUgaW50ZXJuYWwgSVAgYWRkcmVzcy9wcmVmaXggd2l0aCB0aGUgb25lDQo+ID4g PiByZXRyaWV2ZXMNCj4gPiA+ID4gZnJvbSB0aGUgTkFUIG1hcHBpbmcgdGFibGUuDQo+ID4gPiA+ DQo+ID4gPiA+IERvIHlvdSBzZWUgYW55IGlzc3VlIHdpdGggdGhpcyBzY2hlbWU/DQo+ID4gPiA+ DQo+ID4gPiA+ID4gPiBBbiBvcGVuIHF1ZXN0aW9uIHRob3VnaCB3b3VsZCBiZSB0byBkaXNjdXNz IGlmIHRoZXJlIGlzIGEgdmFsdWUNCj4gPiA+ID4gPiA+IGluDQo+ID4gPiA+ID4gaGF2aW5nIGEg ZmVhdHVyZSBpbiB0aGUgRE9UUyBwcm90b2NvbCB0byBpbmZvcm0gYSBET1RTIGNsaWVudCB0aGF0 DQo+ID4gPiA+ID4gYSBOQVQgaXMgZGV0ZWN0ZWQgb24tcGF0aC4gVGhpcyBjYW4gYmUgcHJlc2Vu dGVkIGFzIGFuIGluZm9ybWF0aW9uDQo+ID4gPiA+ID4gZWxlbWVudCByZXR1cm5lZCBieSB0aGUg c2VydmVyIHRvIHRoZSBjbGllbnQuIFRoaXMgaW5mb3JtYXRpb24gY2FuDQo+ID4gPiA+ID4gYmUs IGZvciBleGFtcGxlLCB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gYWRqdXN0IGl0cyBIVCBpbnRlcnZh bCwNCj4gPiA+ID4gPiBhZGp1c3QgdGhlIGludGVybmFsIElQIGFkZHJlc3Nlcy9wcmVmaXhlcyB0 byBiZSBwcm90ZWN0ZWQsIGV0Yy4NCj4gT3BpbmlvbnM/DQo+ID4gPiA+ID4gSXQgc291bmRzIGFw cGVhbGluZywgYnV0IGl0J3MgdmVyeSBkaWZmaWN1bHQgdG8gZG8gdGhpcyByZWxpYWJseSwNCj4g PiA+ID4gPiBhbmQgaXQncyBub3QganVzdCBOQVRzIHRoYXQgYXJlIGFuIGlzc3VlIGhlcmU7IEZp cmV3YWxscyBwcmVzZW50DQo+ID4gPiA+ID4gc2ltaWxhciBjaGFsbGVuZ2VzIChhbmQgdGhleSBt YXkgb3IgbWF5IG5vdCBiZSBOQVQnaW5nIGluZGl2aWR1YWwNCj4gPiBmbG93cykuDQo+ID4gPiA+ ID4NCj4gPiA+ID4NCj4gPiA+ID4gW01lZF0gSSBmdWxseSBhZ3JlZSB0aGF0IGZpcmV3YWxscyBk ZXRlY3QgaXMgbW9yZSBjb21wbGV4LiBMZXQncyBwdXQNCj4gPiA+ID4gaXQNCj4gPiA+IGFzaWRl DQo+ID4gPiA+IGFuZCBmb2N1cyBvbiB0aGUgTkFUIGNhc2UuDQo+ID4gPg0KPiA+ID4gVGhlIHBy ZXNlbmNlIGFuZCBiZWhhdmlvciBvZiBOQVQgYW5kIEZpcmV3YWxsLCBhbmQga2VlcGFsaXZlIGlu dGVydmFsDQo+ID4gPiBjYW4gYmUgZGV0ZXJtaW5lZCB1c2luZyBTVFVOIChkaXNjdXNzZWQgaW4N Cj4gPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzgwKS4NCj4gPiA+DQo+ID4g PiAtVGlydQ0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gV2UgY2FuIGNvbnNpZGVyIG1hbnkgYXBw cm9hY2hlcyB0byBkZXRlY3QgYSBOQVQsIGUuZy4sDQo+ID4gPiA+DQo+ID4gPiA+ICgxKSBUaGUg RE9UUyBjbGllbnQgaW5zZXJ0cyBpbiB0aGUgY29yZSBtZXNzYWdlIHRoZSBJUCBhZGRyZXNzL3Bv cnQNCj4gPiA+ID4gaXQNCj4gPiA+IHVzZXMgdG8NCj4gPiA+ID4gc2VuZCB0aGUgcmVxdWVzdCB0 byB0aGUgRE9UUyBzZXJ2ZXIuIFVwb24gcmVjZWlwdCBvZiB0aGUgcmVxdWVzdCBieQ0KPiA+ID4g PiB0aGUgRE9UUyBzZXJ2ZXIsIGl0IGNoZWNrcyBpZiB0aGUgZW5jbG9zZWQgSVAgYWRkcmVzcy9w b3J0IG1hdGNoIHRoZQ0KPiA+ID4gPiBzb3VyY2UNCj4gPiA+IElQDQo+ID4gPiA+IGFkZHJlc3Mv cG9ydCBvZiB0aGUgcmVjZWl2ZWQgcGFja2V0LiBJZiB5ZXMsIHRoZSBzZXJ2ZXIgc2V0cyBpbiB0 aGUNCj4gPiA+IHJlc3BvbnNlIGENCj4gPiA+ID4gZGVkaWNhdGVkIHBhcmFtZXRlciB0byBpbmRp Y2F0ZSB0aGF0IGEgdHJhbnNsYXRvciBpcyBkZXRlY3RlZCBvbi0NCj4gcGF0aC4NCj4gPiA+ID4N Cj4gPiA+ID4gKDIpIFRoZSBET1RTIHNlcnZlciBpbnNlcnRzIHN5c3RlbWF0aWNhbGx5IHRoZSBz b3VyY2UgSVANCj4gPiA+ID4gYWRkcmVzcy9wb3J0IGluDQo+ID4gPiBhDQo+ID4gPiA+IHJlc3Bv bnNlIHRvIGEgbWVzc2FnZSBmcm9tIGEgRE9UUyBjbGllbnQuIFVwb24gcmVjZWlwdCBvZiB0aGF0 DQo+ID4gPiA+IHJlc3BvbnNlLCB0aGUgRE9UUyBjbGllbnQgY29tcGFyZXMgdGhlIGVuY2xvc2Vk IGFkZHJlc3MvcG9ydCB3aXRoDQo+ID4gPiA+IHRoZSBvbmVzIGl0IHVzZWQNCj4gPiA+IHRvDQo+ ID4gPiA+IHNlbmQgdGhlIHJlcXVlc3QgdG8gZGV0ZWN0IGFueSBtaXNtYXRjaC4NCj4gPiA+ID4N Cj4gPiA+ID4NCj4gPiA+ID4gPiAtLSBGbGVtbWluZw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IENoZWVycywNCj4gPiA+ID4gPiA+IE1lZA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+ID4gPiA+PiBEZcKgOiBEb3Rz IFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvbg0KPiA+ID4g PiA+ID4+IFNoYWxsb3cgRW52b3nDqcKgOiBsdW5kaSAyMyBvY3RvYnJlIDIwMTcgMTM6MTggw4DC oDogJ0ZsZW1taW5nDQo+ID4gPiA+ID4gPj4gQW5kcmVhc2VuJzsgZG90c0BpZXRmLm9yZyBPYmpl dMKgOiBSZTogW0RvdHNdIERPVFMgUmVxdWlyZW1lbnRzDQo+ID4gPiA+ID4gPj4gcmV2aWV3ICgt MDYpDQo+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+PiBIaSBGbGVtbWluZywNCj4gPiA+ID4gPiA+ Pg0KPiA+ID4gPiA+ID4+IFRoZSB3YXkgbXkgbWluZCB3b3JrcyBpcyB0byB0aGluayBvZiBhIHBy YWN0aWNhbCBzaXR1YXRpb24gYW5kDQo+ID4gPiA+ID4gPj4gc2VlIGlmIHRoaW5ncyBmaXQuDQo+ ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+PiBBcyBJIHJlYWQgU0lHLTAxMCwgdGhlcmUgY291bGQg YmUgYSBET1RTIGNsaWVudCB3aXRoIGENCj4gPiA+ID4gPiA+PiBtYW5hZ2VtZW50IElQIGFkZHJl c3MgdGhhdCBpcyBSRkMxOTE4IC0gdGhpcyBjbGllbnQgY291bGQgYmUNCj4gPiA+ID4gPiA+PiBt b25pdG9yaW5nIE5ldGZsb3cgaW5mb3JtYXRpb24gYW5kIGNhbiByZXF1ZXN0IG1pdGlnYXRpb24g Zm9yDQo+ID4gPiA+ID4gPj4gdGhlIGFwcHJvcHJpYXRlIHB1YmxpYyBJUHMNCj4gPiA+ID4gPiB0 aGF0DQo+ID4gPiA+ID4gPj4gYXJlIGJlaW5nIG1vbml0b3JlZC4gIFNvIFNJRy0wMTAgaXMgbmVl ZGVkIGZvciB0aGlzIHVzZSBjYXNlLg0KPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPj4gSXQgaXMg dGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBET1RTIHNlcnZlciBhcyB0byB3aGV0aGVyIGl0DQo+ ID4gPiA+ID4gPj4gYWNjZXB0cyBhIG1pdGlnYXRpb24gcmVxdWVzdCBmb3IgYSBwYXJ0aWN1bGFy IHRhcmdldCBpcCAob3INCj4gPiA+ID4gPiA+PiBkb21haW4NCj4gPiA+IGV0Yy4pIG9yDQo+ID4g PiA+IG5vdC4NCj4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4+IElmIHRoZXJlIGlzIGdvaW5nIHRv IGJlIGEgTkFUIGJvcmRlciB3aGVyZSBwdWJsaWMgSVBzIGFyZQ0KPiA+ID4gPiA+ID4+IG1hcHBl ZCBpbnRvIHByaXZhdGUgSVBzIChhbmQgdmljZSB2ZXJzYSksIEkgd291bGQgdGhlbiBleHBlY3QN Cj4gPiA+ID4gPiA+PiB0aGVyZSB0byBiZSBhIERPVFMgZ2F0ZXdheSBiZXR3ZWVuIHRoZXNlIDIg em9uZXMsIGFuZCBpdCBpcyB0aGUNCj4gPiA+ID4gPiA+PiByZXNwb25zaWJpbGl0eSBvZiB0aGUg RE9UUyBnYXRld2F5IHRvIGRvIGFueSB0YXJnZXQtaXANCj4gbWFwcGluZ3MuDQo+ID4gPiA+ID4g Pj4NCj4gPiA+ID4gPiA+PiBSZWdhcmRzDQo+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+PiBKb24N Cj4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gPiA+ID4gPj4gRnJvbTogRG90cyBbbWFpbHRvOmlldGYtc3VwanBzLWRvdHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmDQo+ID4gPiA+ID4gPj4gT2YgRmxlbW1pbmcgQW5kcmVhc2VuDQo+ ID4gPiA+ID4gPj4gU2VudDogMjIgT2N0b2JlciAyMDE3IDIwOjE3DQo+ID4gPiA+ID4gPj4gVG86 IGRvdHM7IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ PiBTdWJqZWN0OiBbRG90c10gRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpDQo+ID4gPiA+ ID4gPj4NCj4gPiA+ID4gPiA+PiBHcmVldGluZ3MNCj4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4+ IEkgaGF2ZSByZXZpZXdlZCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIERPVFMgcmVxdWlyZW1l bnRzDQo+ID4gPiA+ID4gPj4gZHJhZnQNCj4gPiA+ID4gPiA+PiAoaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0wNi50eHQpLg0KPiA+ID4gPiA+ID4+ IEluDQo+ID4gPiA+ID4gZ2VuZXJhbCwNCj4gPiA+ID4gPiA+PiBJIHRoaW5rIHRoZSBkcmFmdCBp cyBpbiBnb29kIHNoYXBlIHdpdGggb25seSBhIGZldyBlZGl0cw0KPiA+ID4gPiA+ID4+IHJlcXVp cmVkLCBzbyBJIGhvcGUgd2UgY2FuIG1vdmUgdG8gV0dMQyBzb29uLiBJIGhhdmUgYSBmZXcNCj4g PiA+ID4gPiA+PiBjb21tZW50cyBiZWxvdyAob2Ygd2hpY2gNCj4gPiA+ID4gPiB0aGUNCj4gPiA+ ID4gPiA+PiBOQVQgb25lIGlzIHRoZSBvbmx5IHJlYWwgc3Vic3RhbnRpYWwgb25lKS4gSSBoYXZl IGFsc28NCj4gPiA+ID4gPiA+PiBzdWJtaXR0ZWQgYSBwdWxsIHJlcXVlc3Qgd2l0aCBhIGZldyBu aXQgZml4ZXMgb24gR2l0SHViOg0KPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPj4NCj4gPiA+ID4g PiA+PiBTZWN0aW9uIDEuMg0KPiA+ID4gPiA+ID4+IC0gVGhlIGRlZmluaXRpb24gb2YgIkRPVFMg U2lnbmFsIiBpcyBzbGlnaHRseSBpbmNvbnNpc3RlbnQgd2l0aA0KPiA+ID4gPiA+ID4+IHRoZSBy ZXNwZWN0aXZlICJDbGllbnQgU2lnbmFsIiBhbmQgIlNlcnZlciBTaWduYWwiIGRlZmluaXRpb25z Lg0KPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPj4gU0lHLTAwNToNCj4gPiA+ID4gPiA+PiAtIE5v dCBjbGVhciB0aGF0IGFsd2F5cyByZXF1aXJpbmcgIm51bWJlciBvZiBwYWNrZXRzIiBtZXRyaWNz DQo+ID4gPiA+ID4gPj4gaXMgbWVhbmluZ2Z1bC4gQ29uc2lkZXIgVENQLWJhc2VkIGF0dGFja3Mg Zm9yIGV4YW1wbGUuIE51bWJlcg0KPiA+ID4gPiA+ID4+IG9mIGJ5dGVzIG1heSBhbHdheXMgYmUg b2sgLSBhYm92ZSBhbmQgYmV5b25kIHRoYXQgaXQgc2hvdWxkDQo+ID4gPiA+ID4gPj4gcHJvYmFi bHkgYmUgZXh0ZW5zaWJsZSBhbmQvb3IgYXR0YWNrIGRlcGVuZGVudC4NCj4gPiA+ID4gPiA+PiAt IEkgZG9uJ3QgdGhpbmsgdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudCBzaG91bGQgZ2V0IGludG8N Cj4gPiA+ID4gPiA+PiBzcGVjaWZ5aW5nDQo+ID4gPiA+ID4gdGltZXINCj4gPiA+ID4gPiA+PiB2 YWx1ZXMgLSBleHBvbnRpYWwgYmFja29mZiB3aXRoIHNvbWUgbWF4aW11bSB2YWx1ZSBzZWVtcyBh Ym91dA0KPiA+ID4gPiA+ID4+IHRoZQ0KPiA+ID4gPiA+IHJpZ2h0DQo+ID4gPiA+ID4gPj4gbGV2 ZWwgb2YgZGV0YWlsIGhlcmUuDQo+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+PiBTSUctMDA5Og0K PiA+ID4gPiA+ID4+IC0gVG8gYmUgY2xlYXIsIHRoZSBjb25mbGljdHMgb25seSBhcHBseSB3aXRo aW4gYSBzaW5nbGUNCj4gPiA+ID4gPiA+PiBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIHJpZ2h0ID8g Rm9yIGV4YW1wbGUsIGlmIGEgY2xpZW50IHRlbGxzDQo+ID4gPiA+ID4gPj4gdGhlIHNhbWUgZG9t YWluIHRvIGFsdGVybmF0ZWx5IHR1cm4gb24vb2ZmIG1pdGlnYXRpb24gZm9yIGENCj4gPiA+ID4g PiA+PiBnaXZlbiBwcmVmaXgsIHJvdXRlIGZsYXBwaW5nDQo+ID4gPiA+ID4gbWF5DQo+ID4gPiA+ ID4gPj4gb2NjdXIuIFRoZSBzYW1lIGNvbmNlcm4gZG9lcyBub3QgYXBwbHkgaWYgYSBjbGllbnQg dGVsbHMgdHdvDQo+ID4gPiA+ID4gPj4gZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlIGRvbWFpbnMg dG8gcmVzcGVjdGl2ZSB0dXJuIG1pdGlnYXRpb24NCj4gPiA+ID4gPiA+PiBvbiAoZG9tYWluIDEp IGFuZA0KPiA+ID4gPiA+IG9mZg0KPiA+ID4gPiA+ID4+IChkb21haW4gMikuIElmIHNvLCBjYW4g d2UgY2xhcmlmeSB0aGF0IChhbHNvIGluIGxpZXUgb2Ygc29tZSBvZg0KPiA+ID4gPiA+ID4+IHRo ZQ0KPiA+ID4gPiA+IG11bHRpLQ0KPiA+ID4gPiA+ID4+IGhvbWluZyBjb21tZW50cyByYWlzZWQg cHJldmlvdXNseSkgPw0KPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPj4gU0lHLTAxMDoNCj4gPiA+ ID4gPiA+PiAtIERPVFMgQ2xpZW50IGJlaGluZCBOQVQuIE9uIG9uZSBoYW5kLCBpdCBzZWVtcyBy ZWFzb25hYmxlIHRvDQo+ID4gPiA+ID4gPj4gaGF2ZSB0aGlzIHJlcXVpcmVtZW50IHNpbmNlIGNs aWVudHMgZm9yIHN1cmUgY2FuIGJlIGJlaGluZA0KPiA+ID4gPiA+ID4+IE5BVHMsIGFuZA0KPiA+ ID4gd2l0aA0KPiA+ID4gPiB0aGluZ3MNCj4gPiA+ID4gPiA+PiBsaWtlIGR5bmFtaWMgRE5TLCB0 aGV5IGNhbiAgICAgY2VydGFpbmx5IGJlIHJlYWNoYWJsZS4gSG93ZXZlciwNCj4gaWYNCj4gPiA+ IHdlDQo+ID4gPiA+ID4gZG8NCj4gPiA+ID4gPiA+PiB3YW50IHRvIGFsbG93IGZvciB0aGlzIHNj ZW5hcmlvLCBhbmQgaW4gcGFydGljdWxhciBmb3IgdGhlIERPVFMNCj4gPiA+ID4gPiA+PiBjbGll bnQNCj4gPiA+ID4gPiB0bw0KPiA+ID4gPiA+ID4+IGhhdmUgYSBwcml2YXRlIElQLWFkZHJlc3Mg KHBvdGVudGlhbGx5IGJlaGluZCBtdWx0aXBsZSBOQVRzKSwNCj4gPiA+ID4gPiA+PiB0aGVuIHdl DQo+ID4gPiA+ID4gaGF2ZQ0KPiA+ID4gPiA+ID4+IG1vcmUgd29yayB0byBkbyBiZWNhdXNlIGl0 IHdvbid0IGRvIHRoZSBET1RTIHNlcnZlciBhbnkgZ29vZCB0bw0KPiA+ID4gPiA+ID4+IGdldCBh IG1pdGlnYXRpb24gcmVxdWVzdCByZWZlcnJpbmcgdG8gdGhhdCBwcml2YXRlIElQLWFkZHJlc3MN Cj4gPiA+ID4gPiA+PiAob3INCj4gPiA+IHByZWZpeCkuDQo+ID4gPiA+ID4gPj4NCj4gPiA+ID4g PiA+Pg0KPiA+ID4gPiA+ID4+IFRoYW5rcw0KPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPj4gLS0g RmxlbW1pbmcNCj4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gPj4gRG90cyBtYWlsaW5nIGxp c3QNCj4gPiA+ID4gPiA+PiBEb3RzQGlldGYub3JnDQo+ID4gPiA+ID4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4g PiA+ID4+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gPj4gRG90c0BpZXRmLm9yZw0KPiA+ ID4gPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+ ID4gPiA+ID4gLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gRG90cyBtYWlsaW5nIGxp c3QNCj4gPiA+ID4gRG90c0BpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Thu Oct 26 03:57:54 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DF01387BC for ; Thu, 26 Oct 2017 03:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 XAvBCUq0axLT for ; Thu, 26 Oct 2017 03:57:50 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 0B72B13F555 for ; Thu, 26 Oct 2017 03:57:49 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509015462; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=F nFwP5qrT3RdkZHn+DRGM0XVzPdzOcpJrdVeI/m/wT w=; b=VldtgZhJpLz/WwewCje9n9sX4Cm93YGo2VzR6jHFA54X udTi5ptctBCPHI1nk76/5Ctr6QN3iHwJF4iXRBdN/aSIFo0klH Bm9gdl5FlwC7dX2TyvTK/324GIfp1dI1Przzgr606DRj2lVowL DX+fwBkzTL3/KyU5qgIbWzLjsXo= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 2c47_ff1d_757281eb_14c7_448d_a512_b53ece1f384e; Thu, 26 Oct 2017 05:57:40 -0500 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 06:57:40 -0400 Received: from MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 06:57:39 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 26 Oct 2017 06:57:39 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 06:57:38 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 26 Oct 2017 10:57:37 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0156.007; Thu, 26 Oct 2017 10:57:37 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Flemming Andreasen" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAGjp6AACQhAAAAYgT5UAABUQNgAACCGwAAAIl5gAAA3jTg Date: Thu, 26 Oct 2017 10:57:36 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:bhEpIIK6xxNAhXOeOxrd7QHPlsHacxU9dx0DXL7WmVXPNiBKx9fCd+v0goJ9PyCPR0lP+iXUenFeJVZXl1AJC28cv89W9C/4mH90eqrLywI429KlhkfFZ7GyepfLjYzckN/quOsZsqKwrYbRDeDjGGHGlymAph9uzh+XZaMhUWBD0K0D1FmWnIpaPQeZFWZ34seJr2m8bsgsbKMz4yPoDr9bcsiCqtEWiyH4DaHtCDkpw97t5GsGyUqOzt5yZOY5c5FeXknrWhwc4lBya8fkx4srvyF3tZb9lPxpjmEBz/CCR9zuAP+TtT+F6+82kMc5t+hXuumrCrY3sBUSr4ZAsA==; 5:rSoiIRm31MTKMo8ZkbkQ5ZRnAs8eMTGMkjYEUPj+OmqsQrTyDcHeKQOKh6GDbBFLTgsKBZSnw5xfvq8928ZDonRlYrpfNKYe0jUPROPU7FY6xe5SDfypt3XNVhvMOy/S8s0EaRVRYOJnehTOVVcy1A==; 24:3bZbIyuvQs+ZDsrY8JgVndETYEcggw/iaC61d2yg4T6SNNOzy3tOy6XGZsoDFWkg0qYFeD17s7vNzlidsuPFmD0oNTLJ8JXHhDyM6jBjYaM=; 7:MuZE9WqJ9TGQBTZQL8lQBnuECRrMZs7Dn9NSCbIXlQR/U6ozd5ZjkGJFxNltHXSVvs8yqPuGPIPLitt/rLdPRssBU3hT32F5inXji5s1BNPqH881N/rp6+jIN2bTKF3MJfIsu9slk4lna9BmVM5eg7PNbiF2zy+wrGdB62Dep+jOWarhV7dLPA2VOCCJpjF3MuEAk9nqSGYaFEkJnPf7CU2K5rTUpamrrTLbFLOA2to= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b8787b58-7c3e-45b3-5b9f-08d51c605ea2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(788757137089)(95692535739014)(18271650672692)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3231020)(3002001)(6041248)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(24454002)(13464003)(189002)(55784002)(199003)(32952001)(72206003)(106356001)(81156014)(2900100001)(68736007)(81166006)(6116002)(105586002)(102836003)(3846002)(8936002)(8676002)(80792005)(9686003)(97736004)(6246003)(3660700001)(3280700002)(229853002)(77096006)(6436002)(6506006)(55016002)(99286003)(53936002)(478600001)(6306002)(86362001)(5660300001)(2950100002)(966005)(7736002)(2906002)(25786009)(189998001)(2501003)(74316002)(110136005)(305945005)(53546010)(7696004)(76176999)(101416001)(66066001)(50986999)(316002)(33656002)(561944003)(14454004)(93886005)(54356999)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b8787b58-7c3e-45b3-5b9f-08d51c605ea2 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 10:57:37.0586 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6144> : inlines <6146> : streams <1768464> : uri <2522675> Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 10:57:52 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tDQo+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4gU2Vu dDogVGh1cnNkYXksIE9jdG9iZXIgMjYsIDIwMTcgMjoyMSBQTQ0KPiBUbzogS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47DQo+IEZs ZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPjsgSm9uIFNoYWxsb3cgPHN1cGpw cy0NCj4gaWV0ZkBqcHNoYWxsb3cuY29tPjsgZG90c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTog W0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYp KQ0KPiANCj4gUmUtLA0KPiANCj4gSSBoZWFyIHlvdS4gTXkgdGFrZSBpcyB0aGF0IHdlIGRvbid0 IG5lZWQgdG8gcmVjb21tZW5kIHdoaWNoIGNvbXBhbmlvbg0KPiAicHJvdG9jb2xzL21lY2hhbmlz bXMiIG5lZWQgdG8gYmUgc3VwcG9ydGVkIGZvciBOQVQvRlcgdHJhdmVyc2FsDQo+IHB1cnBvc2Vz LiBIYXZpbmcgYSBkaXNjdXNzaW9uIGF0IHRoZSBzYW1lIGxldmVsIGluIDgwODUgd291bGQgYmUg c3VmZmljaWVudCwNCj4gSU1ITy4NCj4gDQo+IExldCdzIGZvY3VzIG9uIHRoZSBzaW1wbGUgYnVp bHQtaW4gZmVhdHVyZSBmb3IgTkFUIGRldGVjdC4NCg0KSSBkb27igJl0IHRoaW5rIHRoZSBzaW1w bGUgYnVpbHQtaW4gZmVhdHVyZSBpcyBzdWZmaWNpZW50LCBET1RTIGNsaWVudCB3aWxsIGhhdmUg dG8gcmVseSBvbiBtZWNoYW5pc21zIGRpc2N1c3NlZCBpbiA4MDg1IGZvciBib3RoIGZpcmV3YWxs IGFuZCBOQVQgdHJhdmVyc2FsLg0KDQotVGlydQ0KDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiAN Cj4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiBEZcKgOiBLb25kYSwgVGlydW1h bGVzd2FyIFJlZGR5DQo+ID4gW21haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUu Y29tXQ0KPiA+IEVudm95w6nCoDogamV1ZGkgMjYgb2N0b2JyZSAyMDE3IDEwOjM2DQo+ID4gw4DC oDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgRmxlbW1pbmcgQW5kcmVhc2VuOyBKb24gU2hh bGxvdzsNCj4gPiBkb3RzQGlldGYub3JnIE9iamV0wqA6IFJFOiBbRG90c10gRE9UUyAmIE5BVCAo d2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cw0KPiA+IHJldmlldyAoLTA2KSkNCj4gPg0KPiA+IEJ1 dCBOQVRzIGFyZSBub3QgdGhlIG9ubHkgcHJvYmxlbSwgZmlyZXdhbGxzIHdpbGwgYWxzbyBiZSBt b3N0IGxpa2VseQ0KPiA+IHByZXNlbnQsIGFuZCBTVFVOIGhlbHBzIGRpc2NvdmVyIGJvdGggTkFU cyBhbmQgZmlyZXdhbGxzIGFuZCB1c2VmdWwNCj4gPiBldmVuIGluIElQdjYgbmV0d29ya3MgdG8g ZGV0ZXJtaW5lIHRoZSBrZWVwYWxpdmUgaW50ZXJ2YWwgb2YgZmlyZXdhbGwuDQo+ID4NCj4gPiAt VGlydQ0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTog bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+ID4gW21haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tXQ0KPiA+ID4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjYsIDIwMTcg MTo1MiBQTQ0KPiA+ID4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPFRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+Ow0KPiA+ID4gRmxlbW1pbmcgQW5kcmVhc2VuIDxm YW5kcmVhc0BjaXNjby5jb20+OyBKb24gU2hhbGxvdyA8c3VwanBzLQ0KPiA+ID4gaWV0ZkBqcHNo YWxsb3cuY29tPjsgZG90c0BpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUkU6IFtEb3RzXSBET1RT ICYgTkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJldmlldw0KPiA+ID4gKC0wNikpDQo+ ID4gPg0KPiA+ID4gVGlydSwNCj4gPiA+DQo+ID4gPiBZZXMsIFNUVU4gY2FuIGJlIGxpc3RlZCBh cyBwYXJ0IG9mIHRoZSBleGlzdGluZyB0b29scyBib3ggKGFtb25nIHRoZQ0KPiA+IGxpbmVzIG9m DQo+ID4gPiB3aGF0IGlzIGFscmVhZHkgZGlzY3Vzc2VkIGluIDgwODUpLg0KPiA+ID4NCj4gPiA+ IEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBtYWtlcyBzZW5zZSB0byByZXF1aXJlIFNUVU4gc3VwcG9y dCBieSBET1RTDQo+ID4gY2xpZW50cy4NCj4gPiA+DQo+ID4gPiBUaGUgcHJvcG9zYWwgaXMgdG8g aW5jbHVkZSBhIHNpbXBsZSBidWlsdC1pbiBmZWF0dXJlIGluIHRoZSBET1RTDQo+ID4gcHJvdG9j b2wgaXRzZWxmDQo+ID4gPiB0aGF0IGNhbiBoZWxwIHRvIGRldGVjdCBOQVRzLiBUaGUgc3VwcG9y dCBvZiBzdWNoIGZlYXR1cmUgd2lsbCwNCj4gPiA+IGUuZy4sDQo+ID4gZWFzZQ0KPiA+ID4gdHJv dWJsZXNob290aW5nIHdoZW4gY29ubmVjdGl2aXR5IHByb2JsZW1zIGFyZSBleHBlcmllbmNlZCBv biB0aGUNCj4gPiA+IHBhdGggYmV0d2VlbiBhIGNsaWVudCBhbmQgYSBzZXJ2ZXIuDQo+ID4gPg0K PiA+ID4gQ2hlZXJzLA0KPiA+ID4gTWVkDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU1lc3NhZ2UgZCdv cmlnaW5lLS0tLS0NCj4gPiA+ID4gRGXCoDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+ ID4gPiBbbWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb21dDQo+ID4gPiA+ IEVudm95w6nCoDogamV1ZGkgMjYgb2N0b2JyZSAyMDE3IDA5OjQ0IMOAwqA6IEJPVUNBREFJUiBN b2hhbWVkDQo+ID4gPiA+IElNVC9PTE47IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7 IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDoNCj4gPiA+ID4gUkU6IFtEb3RzXSBET1RTICYgTkFUICh3 YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KSkNCj4gPiA+ID4NCj4gPiA+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZyb206IERvdHMgW21haWx0 bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+ID4gPiA+IG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiA+ID4gPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI0 LCAyMDE3IDI6MjAgUE0NCj4gPiA+ID4gPiBUbzogRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVh c0BjaXNjby5jb20+OyBKb24gU2hhbGxvdw0KPiA+ID4gPiA+IDxzdXBqcHMtIGlldGZAanBzaGFs bG93LmNvbT47IGRvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW0RvdHNdIERP VFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3DQo+ID4gPiA+ID4gKC0w NikpDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBIaSBGbGVtbWluZywgYWxsLA0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBDaGVlcnMs DQo+ID4gPiA+ID4gTWVkDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPiA+ID4gPiA+ID4gRGXCoDogRmxlbW1pbmcgQW5kcmVhc2VuIFttYWlsdG86 ZmFuZHJlYXNAY2lzY28uY29tXSBFbnZvecOpwqA6DQo+ID4gPiA+ID4gPiBsdW5kaQ0KPiA+ID4g PiA+ID4gMjMgb2N0b2JyZSAyMDE3IDE3OjM2IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9P TE47IEpvbg0KPiA+ID4gPiA+ID4gU2hhbGxvdzsgZG90c0BpZXRmLm9yZyBPYmpldMKgOiBSZTog RE9UUyAmIE5BVCAod2FzIFJFOiBbRG90c10NCj4gPiA+ID4gPiA+IERPVFMgUmVxdWlyZW1lbnRz IHJldmlldyAoLTA2KSkNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IE9uIDEwLzIzLzE3IDg6MjggQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20gd3JvdGU6DQo+ID4gPiA+ID4gPiA+IEhpIEpvbiwgYWxsLA0KPiA+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gPiBJIGFncmVlIHdpdGggRmxlbW1pbmcgdGhhdCAic29tZSBtb3JlIHdvcmsiIGlz IG5lZWRlZC4gSU1ITywNCj4gPiA+ID4gPiA+ID4gdGhpcyBpcyBhDQo+ID4gPiA+ID4gPiB0eXBp Y2FsIGRpc2N1c3Npb24gdG8gaW5jbHVkZSBpbiBhIGRlZGljYXRlZCBzZWN0aW9uIGluIHRoZQ0K PiA+ID4gPiA+ID4gRE9UUyBhcmNoaXRlY3R1cmUgSS1ELg0KPiA+ID4gPiA+ID4gQWdyZWVkLg0K PiA+ID4gPiA+ID4gPiA+RnJvbSBhIHJlcXVpcmVtZW50IHN0YW5kcG9pbnQsIHdlIGRvbid0IG5l ZWQgdG8gZWxhYm9yYXRlDQo+ID4gPiA+ID4gPiA+ID5ob3cgdGhlDQo+ID4gPiA+ID4gPiBwcm90 b2NvbHMgd2lsbCBmdWxmaWwgaXQuIFNJRy0xMCBkb2VzIGV2ZW4gYSBuaWNlIGpvYiBieQ0KPiA+ ID4gPiA+ID4gY2l0aW5nDQo+ID4gPiA+ID4gPiBSRkM4MDg1IHdoaWNoIHBvaW50cyB0byBOQVQg dHJhdmVyc2FsIG1lY2hhbmlzbXMuIE9uZSBjb3VsZA0KPiA+ID4gPiA+ID4gcGljayBoaXMvaGVy IGZhdm9yaXRlIHByb3RvY29sIGZyb20gdGhlIGxpc3QgaW4gODA4NSB0bw0KPiA+ID4gPiA+ID4g ZGlzY292ZXIgdGhlIGV4dGVybmFsIElQIGFkZHJlc3MvcHJlZml4LCBpZiBuZWVkZWQuIEV4dGVy bmFsDQo+ID4gPiA+ID4gPiBJUCBhZGRyZXNzZXMvcHJlZml4ZXMgY2FuIGJlIElQdjQgZm9yIGEg TkFUNDQgb3IgTkFUNjQsIGJ1dA0KPiA+ID4gPiA+ID4gY2FuIGJlDQo+ID4gPiA+ID4gPiBJUHY2 IHByZWZpeGVzIGZvciBlbnRlcnByaXNlcyBkZXBsb3lpbmcgTlBUdjYsIGFuZCBzbyBvbi4NCj4g PiA+ID4gPiA+IFBhcnQgb2YgdGhlIGNoYWxsZW5nZSBoZXJlIGlzIHRoYXQgdGhlIGF0dGFjayB0 YXJnZXQgYW5kIHRoZQ0KPiA+ID4gPiA+ID4gRE9UUyBjbGllbnQgYXJlIG5vdCBuZWNlc3Nhcmls eSBvbmUgYW5kIHRoZSBzYW1lLCB3aGljaCBtYWtlcw0KPiA+ID4gPiA+ID4gaXQgbW9yZSBkaWZm aWN1bHQgdG8gZGV0ZXJtaW5lIHRoZSBwdWJsaWMtZmFjaW5nDQo+ID4gPiA+ID4gPiBJUC1hZGRy ZXNzL3BvcnQgdW5kZXIgYXR0YWNrIChhdCBsZWFzdCBpZiB0aGUgRE9UUyBjbGllbnQgaXMgZ29p bmcgdG8NCj4gZG8gaXQpLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gW01lZF0gVGhpcyBpcyBleGFj dGx5IHRoZSBraW5kIG9mIHRoZSBkaXNjdXNzaW9uIHRvIGhhdmUuIFRoYW5rcy4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IFdpdGggb3Igd2l0aG91dCBOQVQsIERPVFMgY2xpZW50cyBhcmUgYXNzdW1l ZCB0byBiZSBmZWQgd2l0aCB0aGUNCj4gPiA+ID4gaW50ZXJuYWwNCj4gPiA+ID4gPiB0YXJnZXQo cykuIFRoaXMgY2FuIGJlIGFjaGlldmVkIGJ5IHByb3Zpc2lvbmluZyAobGlrZWx5KSBvciBieQ0K PiA+ID4gPiA+IGRpc2NvdmVyeQ0KPiA+ID4gPiBtZWFucw0KPiA+ID4gPiA+IChlLmcuLCByZXNp ZGVudGlhbCBvciBzbWFsbCBlbnRlcnByaXNlIG5ldHdvcmtzKS4NCj4gPiA+ID4gPg0KPiA+ID4g PiA+IENhbiB3ZSBhc3N1bWUgdGhhdCB0aGUgZGlzY292ZXJ5IG9mIHRoZSBleHRlcm5hbCBJUA0K PiA+ID4gPiA+IGFkZHJlc3MvcHJlZml4Ly4uIGlzDQo+ID4gPiA+IGRvbmUNCj4gPiA+ID4gPiBi eSBhIERPVFMgY2xpZW50IG9ubHkgaWYgaXQgaXMgZXhwbGljaXRseSBpbnN0cnVjdGVkIHRvIGRv IHNvPw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSW4gc29tZSBkZXBsb3lt ZW50cywgRE9UUyBjbGllbnRzIG1heSBiZSBwcm92aXNpb25lZCB3aXRoDQo+ID4gPiA+ID4gPiA+ IHRoZSBzZXQgb2YNCj4gPiA+ID4gPiA+IGludGVybmFsIHJlc291cmNlcywgc28gdGhlcmUgaXMg bm8gbmVlZCBmb3IgZGlzY292ZXJ5Lg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBBbHNv LCBhcyBKb24gbWVudGlvbmVkLCBET1RTIGdhdGV3YXlzIGNhbiBiZSBvZiBoZWxwIHRvIHNldA0K PiA+ID4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+IGFwcHJvcHJpYXRlIElQIGFkZHJlc3Nlcy9w cmVmaXhlcy9wb3J0IG51bWJlcnMgaW4gdGhlIHByZXNlbmNlDQo+ID4gPiA+ID4gPiBvZiB0cmFu c2xhdG9ycy4NCj4gPiA+ID4gPiA+IEFncmVlZCAtIGJ1dCB0aGV5IHN0aWxsIG5lZWQgYSB3YXkg dG8gZmlndXJlIG91dCB0aGUNCj4gPiA+ID4gPiA+IHByaXZhdGUvcHVibGljIG1hcHBpbmcgZm9y IGEgZ2l2ZW4gYXR0YWNrIHRhcmdldC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFtNZWRdIEJlY2F1 c2UgYSBERG9TIGF0dGFjayBpcyBvYnNlcnZlZCBmcm9tIHRoZSBpbnRlcm5hbA0KPiA+ID4gPiA+ IG5ldHdvcmssDQo+ID4gPiA+ID4gbWFwcGluZyhzKSBhcmUgbmVjZXNzYXJpbHkgbWFpbnRhaW5l ZCBieSB0aGUgb24tcGF0aCB0cmFuc2xhdG9yKHMpLg0KPiA+ID4gPiA+IE90aGVyd2lzZSwgdGhl IGluY29taW5nIGF0dGFjayB0cmFmZmljIGNvdWxkbid0IGJlIGZvcndhcmRlZCB0bw0KPiA+ID4g PiA+IGludGVybmFsDQo+ID4gPiA+IGhvc3RzLg0KPiA+ID4gPiA+IFRoaXMgbW9kZWwgYXNzdW1l cyB0aGF0IHRoZSBnYXRld2F5IGlzIGNvbGxvY2F0ZWQgd2l0aCB0aGUgTkFULg0KPiA+ID4gPiA+ IFNvLCB0aGUgZ2F0ZXdheSBjYW4gcmVwbGFjZSB0aGUgaW50ZXJuYWwgSVAgYWRkcmVzcy9wcmVm aXggd2l0aA0KPiA+ID4gPiA+IHRoZSBvbmUNCj4gPiA+ID4gcmV0cmlldmVzDQo+ID4gPiA+ID4g ZnJvbSB0aGUgTkFUIG1hcHBpbmcgdGFibGUuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBEbyB5b3Ug c2VlIGFueSBpc3N1ZSB3aXRoIHRoaXMgc2NoZW1lPw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ IEFuIG9wZW4gcXVlc3Rpb24gdGhvdWdoIHdvdWxkIGJlIHRvIGRpc2N1c3MgaWYgdGhlcmUgaXMg YQ0KPiA+ID4gPiA+ID4gPiB2YWx1ZSBpbg0KPiA+ID4gPiA+ID4gaGF2aW5nIGEgZmVhdHVyZSBp biB0aGUgRE9UUyBwcm90b2NvbCB0byBpbmZvcm0gYSBET1RTIGNsaWVudA0KPiA+ID4gPiA+ID4g dGhhdCBhIE5BVCBpcyBkZXRlY3RlZCBvbi1wYXRoLiBUaGlzIGNhbiBiZSBwcmVzZW50ZWQgYXMg YW4NCj4gPiA+ID4gPiA+IGluZm9ybWF0aW9uIGVsZW1lbnQgcmV0dXJuZWQgYnkgdGhlIHNlcnZl ciB0byB0aGUgY2xpZW50LiBUaGlzDQo+ID4gPiA+ID4gPiBpbmZvcm1hdGlvbiBjYW4gYmUsIGZv ciBleGFtcGxlLCB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gYWRqdXN0DQo+ID4gPiA+ID4gPiBpdHMg SFQgaW50ZXJ2YWwsIGFkanVzdCB0aGUgaW50ZXJuYWwgSVAgYWRkcmVzc2VzL3ByZWZpeGVzIHRv IGJlDQo+IHByb3RlY3RlZCwgZXRjLg0KPiA+IE9waW5pb25zPw0KPiA+ID4gPiA+ID4gSXQgc291 bmRzIGFwcGVhbGluZywgYnV0IGl0J3MgdmVyeSBkaWZmaWN1bHQgdG8gZG8gdGhpcw0KPiA+ID4g PiA+ID4gcmVsaWFibHksIGFuZCBpdCdzIG5vdCBqdXN0IE5BVHMgdGhhdCBhcmUgYW4gaXNzdWUg aGVyZTsNCj4gPiA+ID4gPiA+IEZpcmV3YWxscyBwcmVzZW50IHNpbWlsYXIgY2hhbGxlbmdlcyAo YW5kIHRoZXkgbWF5IG9yIG1heSBub3QNCj4gPiA+ID4gPiA+IGJlIE5BVCdpbmcgaW5kaXZpZHVh bA0KPiA+ID4gZmxvd3MpLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFtNZWRd IEkgZnVsbHkgYWdyZWUgdGhhdCBmaXJld2FsbHMgZGV0ZWN0IGlzIG1vcmUgY29tcGxleC4gTGV0 J3MNCj4gPiA+ID4gPiBwdXQgaXQNCj4gPiA+ID4gYXNpZGUNCj4gPiA+ID4gPiBhbmQgZm9jdXMg b24gdGhlIE5BVCBjYXNlLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgcHJlc2VuY2UgYW5kIGJlaGF2 aW9yIG9mIE5BVCBhbmQgRmlyZXdhbGwsIGFuZCBrZWVwYWxpdmUNCj4gPiA+ID4gaW50ZXJ2YWwg Y2FuIGJlIGRldGVybWluZWQgdXNpbmcgU1RVTiAoZGlzY3Vzc2VkIGluDQo+ID4gPiA+IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzgwKS4NCj4gPiA+ID4NCj4gPiA+ID4gLVRpcnUN Cj4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFdlIGNhbiBjb25zaWRlciBtYW55IGFwcHJv YWNoZXMgdG8gZGV0ZWN0IGEgTkFULCBlLmcuLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gKDEpIFRo ZSBET1RTIGNsaWVudCBpbnNlcnRzIGluIHRoZSBjb3JlIG1lc3NhZ2UgdGhlIElQDQo+ID4gPiA+ ID4gYWRkcmVzcy9wb3J0IGl0DQo+ID4gPiA+IHVzZXMgdG8NCj4gPiA+ID4gPiBzZW5kIHRoZSBy ZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4gVXBvbiByZWNlaXB0IG9mIHRoZSByZXF1ZXN0DQo+ ID4gPiA+ID4gYnkgdGhlIERPVFMgc2VydmVyLCBpdCBjaGVja3MgaWYgdGhlIGVuY2xvc2VkIElQ IGFkZHJlc3MvcG9ydA0KPiA+ID4gPiA+IG1hdGNoIHRoZSBzb3VyY2UNCj4gPiA+ID4gSVANCj4g PiA+ID4gPiBhZGRyZXNzL3BvcnQgb2YgdGhlIHJlY2VpdmVkIHBhY2tldC4gSWYgeWVzLCB0aGUg c2VydmVyIHNldHMgaW4NCj4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gcmVzcG9uc2UgYQ0KPiA+ID4g PiA+IGRlZGljYXRlZCBwYXJhbWV0ZXIgdG8gaW5kaWNhdGUgdGhhdCBhIHRyYW5zbGF0b3IgaXMg ZGV0ZWN0ZWQNCj4gPiA+ID4gPiBvbi0NCj4gPiBwYXRoLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g KDIpIFRoZSBET1RTIHNlcnZlciBpbnNlcnRzIHN5c3RlbWF0aWNhbGx5IHRoZSBzb3VyY2UgSVAN Cj4gPiA+ID4gPiBhZGRyZXNzL3BvcnQgaW4NCj4gPiA+ID4gYQ0KPiA+ID4gPiA+IHJlc3BvbnNl IHRvIGEgbWVzc2FnZSBmcm9tIGEgRE9UUyBjbGllbnQuIFVwb24gcmVjZWlwdCBvZiB0aGF0DQo+ ID4gPiA+ID4gcmVzcG9uc2UsIHRoZSBET1RTIGNsaWVudCBjb21wYXJlcyB0aGUgZW5jbG9zZWQg YWRkcmVzcy9wb3J0DQo+ID4gPiA+ID4gd2l0aCB0aGUgb25lcyBpdCB1c2VkDQo+ID4gPiA+IHRv DQo+ID4gPiA+ID4gc2VuZCB0aGUgcmVxdWVzdCB0byBkZXRlY3QgYW55IG1pc21hdGNoLg0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tIEZsZW1taW5nDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+ID4gPiBNZWQNCj4g PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLSBE ZcKgOiBEb3RzDQo+ID4gPiA+ID4gPiA+PiBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10g RGUgbGEgcGFydCBkZSBKb24gU2hhbGxvdw0KPiA+ID4gPiA+ID4gPj4gRW52b3nDqcKgOiBsdW5k aSAyMyBvY3RvYnJlIDIwMTcgMTM6MTggw4DCoDogJ0ZsZW1taW5nDQo+ID4gPiA+ID4gPiA+PiBB bmRyZWFzZW4nOyBkb3RzQGlldGYub3JnIE9iamV0wqA6IFJlOiBbRG90c10gRE9UUw0KPiA+ID4g PiA+ID4gPj4gUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KQ0KPiA+ID4gPiA+ID4gPj4NCj4gPiA+ ID4gPiA+ID4+IEhpIEZsZW1taW5nLA0KPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4+IFRo ZSB3YXkgbXkgbWluZCB3b3JrcyBpcyB0byB0aGluayBvZiBhIHByYWN0aWNhbCBzaXR1YXRpb24N Cj4gPiA+ID4gPiA+ID4+IGFuZCBzZWUgaWYgdGhpbmdzIGZpdC4NCj4gPiA+ID4gPiA+ID4+DQo+ ID4gPiA+ID4gPiA+PiBBcyBJIHJlYWQgU0lHLTAxMCwgdGhlcmUgY291bGQgYmUgYSBET1RTIGNs aWVudCB3aXRoIGENCj4gPiA+ID4gPiA+ID4+IG1hbmFnZW1lbnQgSVAgYWRkcmVzcyB0aGF0IGlz IFJGQzE5MTggLSB0aGlzIGNsaWVudCBjb3VsZA0KPiA+ID4gPiA+ID4gPj4gYmUgbW9uaXRvcmlu ZyBOZXRmbG93IGluZm9ybWF0aW9uIGFuZCBjYW4gcmVxdWVzdA0KPiA+ID4gPiA+ID4gPj4gbWl0 aWdhdGlvbiBmb3IgdGhlIGFwcHJvcHJpYXRlIHB1YmxpYyBJUHMNCj4gPiA+ID4gPiA+IHRoYXQN Cj4gPiA+ID4gPiA+ID4+IGFyZSBiZWluZyBtb25pdG9yZWQuICBTbyBTSUctMDEwIGlzIG5lZWRl ZCBmb3IgdGhpcyB1c2UgY2FzZS4NCj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiBJdCBp cyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIERPVFMgc2VydmVyIGFzIHRvIHdoZXRoZXINCj4g PiA+ID4gPiA+ID4+IGl0IGFjY2VwdHMgYSBtaXRpZ2F0aW9uIHJlcXVlc3QgZm9yIGEgcGFydGlj dWxhciB0YXJnZXQgaXANCj4gPiA+ID4gPiA+ID4+IChvciBkb21haW4NCj4gPiA+ID4gZXRjLikg b3INCj4gPiA+ID4gPiBub3QuDQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gSWYgdGhl cmUgaXMgZ29pbmcgdG8gYmUgYSBOQVQgYm9yZGVyIHdoZXJlIHB1YmxpYyBJUHMgYXJlDQo+ID4g PiA+ID4gPiA+PiBtYXBwZWQgaW50byBwcml2YXRlIElQcyAoYW5kIHZpY2UgdmVyc2EpLCBJIHdv dWxkIHRoZW4NCj4gPiA+ID4gPiA+ID4+IGV4cGVjdCB0aGVyZSB0byBiZSBhIERPVFMgZ2F0ZXdh eSBiZXR3ZWVuIHRoZXNlIDIgem9uZXMsDQo+ID4gPiA+ID4gPiA+PiBhbmQgaXQgaXMgdGhlIHJl c3BvbnNpYmlsaXR5IG9mIHRoZSBET1RTIGdhdGV3YXkgdG8gZG8gYW55DQo+ID4gPiA+ID4gPiA+ PiB0YXJnZXQtaXANCj4gPiBtYXBwaW5ncy4NCj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ PiBSZWdhcmRzDQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gSm9uDQo+ID4gPiA+ID4g PiA+Pg0KPiA+ID4gPiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4g PiA+ID4+IEZyb206IERvdHMgW21haWx0bzppZXRmLXN1cGpwcy1kb3RzLWJvdW5jZXNAaWV0Zi5v cmddIE9uDQo+ID4gPiA+ID4gPiA+PiBCZWhhbGYgT2YgRmxlbW1pbmcgQW5kcmVhc2VuDQo+ID4g PiA+ID4gPiA+PiBTZW50OiAyMiBPY3RvYmVyIDIwMTcgMjA6MTcNCj4gPiA+ID4gPiA+ID4+IFRv OiBkb3RzOyBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnDQo+ID4gPiA+ID4g PiA+PiBTdWJqZWN0OiBbRG90c10gRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpDQo+ID4g PiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gR3JlZXRpbmdzDQo+ID4gPiA+ID4gPiA+Pg0KPiA+ ID4gPiA+ID4gPj4gSSBoYXZlIHJldmlld2VkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgRE9U UyByZXF1aXJlbWVudHMNCj4gPiA+ID4gPiA+ID4+IGRyYWZ0DQo+ID4gPiA+ID4gPiA+PiAoaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0wNi50eHQp Lg0KPiA+ID4gPiA+ID4gPj4gSW4NCj4gPiA+ID4gPiA+IGdlbmVyYWwsDQo+ID4gPiA+ID4gPiA+ PiBJIHRoaW5rIHRoZSBkcmFmdCBpcyBpbiBnb29kIHNoYXBlIHdpdGggb25seSBhIGZldyBlZGl0 cw0KPiA+ID4gPiA+ID4gPj4gcmVxdWlyZWQsIHNvIEkgaG9wZSB3ZSBjYW4gbW92ZSB0byBXR0xD IHNvb24uIEkgaGF2ZSBhIGZldw0KPiA+ID4gPiA+ID4gPj4gY29tbWVudHMgYmVsb3cgKG9mIHdo aWNoDQo+ID4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+ID4+IE5BVCBvbmUgaXMgdGhlIG9ubHkg cmVhbCBzdWJzdGFudGlhbCBvbmUpLiBJIGhhdmUgYWxzbw0KPiA+ID4gPiA+ID4gPj4gc3VibWl0 dGVkIGEgcHVsbCByZXF1ZXN0IHdpdGggYSBmZXcgbml0IGZpeGVzIG9uIEdpdEh1YjoNCj4gPiA+ ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gU2VjdGlvbiAxLjINCj4g PiA+ID4gPiA+ID4+IC0gVGhlIGRlZmluaXRpb24gb2YgIkRPVFMgU2lnbmFsIiBpcyBzbGlnaHRs eSBpbmNvbnNpc3RlbnQNCj4gPiA+ID4gPiA+ID4+IHdpdGggdGhlIHJlc3BlY3RpdmUgIkNsaWVu dCBTaWduYWwiIGFuZCAiU2VydmVyIFNpZ25hbCIgZGVmaW5pdGlvbnMuDQo+ID4gPiA+ID4gPiA+ Pg0KPiA+ID4gPiA+ID4gPj4gU0lHLTAwNToNCj4gPiA+ID4gPiA+ID4+IC0gTm90IGNsZWFyIHRo YXQgYWx3YXlzIHJlcXVpcmluZyAibnVtYmVyIG9mIHBhY2tldHMiDQo+ID4gPiA+ID4gPiA+PiBt ZXRyaWNzIGlzIG1lYW5pbmdmdWwuIENvbnNpZGVyIFRDUC1iYXNlZCBhdHRhY2tzIGZvcg0KPiA+ ID4gPiA+ID4gPj4gZXhhbXBsZS4gTnVtYmVyIG9mIGJ5dGVzIG1heSBhbHdheXMgYmUgb2sgLSBh Ym92ZSBhbmQNCj4gPiA+ID4gPiA+ID4+IGJleW9uZCB0aGF0IGl0IHNob3VsZCBwcm9iYWJseSBi ZSBleHRlbnNpYmxlIGFuZC9vciBhdHRhY2sNCj4gZGVwZW5kZW50Lg0KPiA+ID4gPiA+ID4gPj4g LSBJIGRvbid0IHRoaW5rIHRoZSByZXF1aXJlbWVudHMgZG9jdW1lbnQgc2hvdWxkIGdldCBpbnRv DQo+ID4gPiA+ID4gPiA+PiBzcGVjaWZ5aW5nDQo+ID4gPiA+ID4gPiB0aW1lcg0KPiA+ID4gPiA+ ID4gPj4gdmFsdWVzIC0gZXhwb250aWFsIGJhY2tvZmYgd2l0aCBzb21lIG1heGltdW0gdmFsdWUg c2VlbXMNCj4gPiA+ID4gPiA+ID4+IGFib3V0IHRoZQ0KPiA+ID4gPiA+ID4gcmlnaHQNCj4gPiA+ ID4gPiA+ID4+IGxldmVsIG9mIGRldGFpbCBoZXJlLg0KPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4g PiA+ID4+IFNJRy0wMDk6DQo+ID4gPiA+ID4gPiA+PiAtIFRvIGJlIGNsZWFyLCB0aGUgY29uZmxp Y3RzIG9ubHkgYXBwbHkgd2l0aGluIGEgc2luZ2xlDQo+ID4gPiA+ID4gPiA+PiBhZG1pbmlzdHJh dGl2ZSBkb21haW4sIHJpZ2h0ID8gRm9yIGV4YW1wbGUsIGlmIGEgY2xpZW50DQo+ID4gPiA+ID4g PiA+PiB0ZWxscyB0aGUgc2FtZSBkb21haW4gdG8gYWx0ZXJuYXRlbHkgdHVybiBvbi9vZmYgbWl0 aWdhdGlvbg0KPiA+ID4gPiA+ID4gPj4gZm9yIGEgZ2l2ZW4gcHJlZml4LCByb3V0ZSBmbGFwcGlu Zw0KPiA+ID4gPiA+ID4gbWF5DQo+ID4gPiA+ID4gPiA+PiBvY2N1ci4gVGhlIHNhbWUgY29uY2Vy biBkb2VzIG5vdCBhcHBseSBpZiBhIGNsaWVudCB0ZWxscw0KPiA+ID4gPiA+ID4gPj4gdHdvIGRp ZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIHRvIHJlc3BlY3RpdmUgdHVybg0KPiA+ID4g PiA+ID4gPj4gbWl0aWdhdGlvbiBvbiAoZG9tYWluIDEpIGFuZA0KPiA+ID4gPiA+ID4gb2ZmDQo+ ID4gPiA+ID4gPiA+PiAoZG9tYWluIDIpLiBJZiBzbywgY2FuIHdlIGNsYXJpZnkgdGhhdCAoYWxz byBpbiBsaWV1IG9mDQo+ID4gPiA+ID4gPiA+PiBzb21lIG9mIHRoZQ0KPiA+ID4gPiA+ID4gbXVs dGktDQo+ID4gPiA+ID4gPiA+PiBob21pbmcgY29tbWVudHMgcmFpc2VkIHByZXZpb3VzbHkpID8N Cj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiBTSUctMDEwOg0KPiA+ID4gPiA+ID4gPj4g LSBET1RTIENsaWVudCBiZWhpbmQgTkFULiBPbiBvbmUgaGFuZCwgaXQgc2VlbXMgcmVhc29uYWJs ZQ0KPiA+ID4gPiA+ID4gPj4gdG8gaGF2ZSB0aGlzIHJlcXVpcmVtZW50IHNpbmNlIGNsaWVudHMg Zm9yIHN1cmUgY2FuIGJlDQo+ID4gPiA+ID4gPiA+PiBiZWhpbmQgTkFUcywgYW5kDQo+ID4gPiA+ IHdpdGgNCj4gPiA+ID4gPiB0aGluZ3MNCj4gPiA+ID4gPiA+ID4+IGxpa2UgZHluYW1pYyBETlMs IHRoZXkgY2FuICAgICBjZXJ0YWlubHkgYmUgcmVhY2hhYmxlLiBIb3dldmVyLA0KPiA+IGlmDQo+ ID4gPiA+IHdlDQo+ID4gPiA+ID4gPiBkbw0KPiA+ID4gPiA+ID4gPj4gd2FudCB0byBhbGxvdyBm b3IgdGhpcyBzY2VuYXJpbywgYW5kIGluIHBhcnRpY3VsYXIgZm9yIHRoZQ0KPiA+ID4gPiA+ID4g Pj4gRE9UUyBjbGllbnQNCj4gPiA+ID4gPiA+IHRvDQo+ID4gPiA+ID4gPiA+PiBoYXZlIGEgcHJp dmF0ZSBJUC1hZGRyZXNzIChwb3RlbnRpYWxseSBiZWhpbmQgbXVsdGlwbGUNCj4gPiA+ID4gPiA+ ID4+IE5BVHMpLCB0aGVuIHdlDQo+ID4gPiA+ID4gPiBoYXZlDQo+ID4gPiA+ID4gPiA+PiBtb3Jl IHdvcmsgdG8gZG8gYmVjYXVzZSBpdCB3b24ndCBkbyB0aGUgRE9UUyBzZXJ2ZXIgYW55DQo+ID4g PiA+ID4gPiA+PiBnb29kIHRvIGdldCBhIG1pdGlnYXRpb24gcmVxdWVzdCByZWZlcnJpbmcgdG8g dGhhdCBwcml2YXRlDQo+ID4gPiA+ID4gPiA+PiBJUC1hZGRyZXNzIChvcg0KPiA+ID4gPiBwcmVm aXgpLg0KPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiBUaGFu a3MNCj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiAtLSBGbGVtbWluZw0KPiA+ID4gPiA+ ID4gPj4NCj4gPiA+ID4gPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPiA+ID4gPiA+PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+ ID4gPj4gRG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ ID4+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gPiA+PiBEb3RzQGlldGYub3JnDQo+ID4g PiA+ID4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4g PiA+ID4gPiA+ID4gLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiBEb3Rz IG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+IERvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Thu Oct 26 04:15:29 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C3C13F582 for ; Thu, 26 Oct 2017 04:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFBOZyUW3EpS for ; Thu, 26 Oct 2017 04:15:19 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5597113F56C for ; Thu, 26 Oct 2017 04:15:12 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 26 Oct 2017 07:15:10 -0400 From: Dave Dolson To: "Konda, Tirumaleswar Reddy" , "mohamed.boucadair@orange.com" , "Flemming Andreasen" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAO8GKAACQhAQAAYkTigAABViKAAAB+EIAAAH6pgAAEb54AAAfog1A= Date: Thu, 26 Oct 2017 11:15:09 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.245.35.5] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 11:15:22 -0000 SSB0aGluayB0aGVyZSBpcyBhbm90aGVyIG9wdGlvbiB0byBoYW5kbGUgdGhlIE5BVC9maXJld2Fs bCBwcm9ibGVtcyBieSBjaGFuZ2luZyB0aGUgcHJvdG9jb2wuDQoNCklmIEkgdW5kZXJzdGFuZCBj b3JyZWN0bHksIGN1cnJlbnRseSB0aGUgTkFUIGFuZCBmaXJld2FsbCBuZWVkIHRvIGJlIGtlcHQg b3BlbiB0byBwZXJtaXQgdW5zb2xpY2l0ZWQgc2VydmVyIHBhY2tldHMuDQoNCklmIHRoZSBwcm90 b2NvbCBpcyBjaGFuZ2VkIHRvIHJlcXVpcmUgY2xpZW50IHBvbGxpbmcgb2YgdGhlIHNlcnZlciB1 cGRhdGVzLCB0aGUgTkFUIGFuZCBmaXJld2FsbCBwcm9ibGVtcyBnbyBhd2F5Lg0KDQotRGF2ZQ0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0K U2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjYsIDIwMTcgMTI6NTggUE0NClRvOiBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tOyBGbGVtbWluZyBBbmRyZWFzZW47IEpvbiBTaGFsbG93OyBkb3Rz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBS ZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gW21haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNiwgMjAx NyAyOjIxIFBNDQo+IFRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsNCj4gRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0Bj aXNjby5jb20+OyBKb24gU2hhbGxvdyA8c3VwanBzLSANCj4gaWV0ZkBqcHNoYWxsb3cuY29tPjsg ZG90c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTog RE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3IA0KPiAoLTA2KSkNCj4gDQo+IFJlLSwNCj4gDQo+IEkg aGVhciB5b3UuIE15IHRha2UgaXMgdGhhdCB3ZSBkb24ndCBuZWVkIHRvIHJlY29tbWVuZCB3aGlj aCBjb21wYW5pb24gDQo+ICJwcm90b2NvbHMvbWVjaGFuaXNtcyIgbmVlZCB0byBiZSBzdXBwb3J0 ZWQgZm9yIE5BVC9GVyB0cmF2ZXJzYWwgDQo+IHB1cnBvc2VzLiBIYXZpbmcgYSBkaXNjdXNzaW9u IGF0IHRoZSBzYW1lIGxldmVsIGluIDgwODUgd291bGQgYmUgDQo+IHN1ZmZpY2llbnQsIElNSE8u DQo+IA0KPiBMZXQncyBmb2N1cyBvbiB0aGUgc2ltcGxlIGJ1aWx0LWluIGZlYXR1cmUgZm9yIE5B VCBkZXRlY3QuDQoNCkkgZG9u4oCZdCB0aGluayB0aGUgc2ltcGxlIGJ1aWx0LWluIGZlYXR1cmUg aXMgc3VmZmljaWVudCwgRE9UUyBjbGllbnQgd2lsbCBoYXZlIHRvIHJlbHkgb24gbWVjaGFuaXNt cyBkaXNjdXNzZWQgaW4gODA4NSBmb3IgYm90aCBmaXJld2FsbCBhbmQgTkFUIHRyYXZlcnNhbC4N Cg0KLVRpcnUNCg0KPiANCj4gQ2hlZXJzLA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+ID4gRGXCoDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+IFtt YWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0NCj4gPiBFbnZvecOpwqA6 IGpldWRpIDI2IG9jdG9icmUgMjAxNyAxMDozNiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQv T0xOOyANCj4gPiBGbGVtbWluZyBBbmRyZWFzZW47IEpvbiBTaGFsbG93OyBkb3RzQGlldGYub3Jn IE9iamV0wqA6IFJFOiBbRG90c10gDQo+ID4gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVp cmVtZW50cyByZXZpZXcgKC0wNikpDQo+ID4NCj4gPiBCdXQgTkFUcyBhcmUgbm90IHRoZSBvbmx5 IHByb2JsZW0sIGZpcmV3YWxscyB3aWxsIGFsc28gYmUgbW9zdCANCj4gPiBsaWtlbHkgcHJlc2Vu dCwgYW5kIFNUVU4gaGVscHMgZGlzY292ZXIgYm90aCBOQVRzIGFuZCBmaXJld2FsbHMgYW5kIA0K PiA+IHVzZWZ1bCBldmVuIGluIElQdjYgbmV0d29ya3MgdG8gZGV0ZXJtaW5lIHRoZSBrZWVwYWxp dmUgaW50ZXJ2YWwgb2YgZmlyZXdhbGwuDQo+ID4NCj4gPiAtVGlydQ0KPiA+DQo+ID4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSANCj4gPiA+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4g PiA+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDE6NTIgUE0NCj4gPiA+IFRvOiBL b25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0Fm ZWUuY29tPjsNCj4gPiA+IEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPjsg Sm9uIFNoYWxsb3cgPHN1cGpwcy0gDQo+ID4gPiBpZXRmQGpwc2hhbGxvdy5jb20+OyBkb3RzQGll dGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9U UyBSZXF1aXJlbWVudHMgcmV2aWV3DQo+ID4gPiAoLTA2KSkNCj4gPiA+DQo+ID4gPiBUaXJ1LA0K PiA+ID4NCj4gPiA+IFllcywgU1RVTiBjYW4gYmUgbGlzdGVkIGFzIHBhcnQgb2YgdGhlIGV4aXN0 aW5nIHRvb2xzIGJveCAoYW1vbmcgDQo+ID4gPiB0aGUNCj4gPiBsaW5lcyBvZg0KPiA+ID4gd2hh dCBpcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiA4MDg1KS4NCj4gPiA+DQo+ID4gPiBJIGRvbid0IHRo aW5rIHRoYXQgaXQgbWFrZXMgc2Vuc2UgdG8gcmVxdWlyZSBTVFVOIHN1cHBvcnQgYnkgRE9UUw0K PiA+IGNsaWVudHMuDQo+ID4gPg0KPiA+ID4gVGhlIHByb3Bvc2FsIGlzIHRvIGluY2x1ZGUgYSBz aW1wbGUgYnVpbHQtaW4gZmVhdHVyZSBpbiB0aGUgRE9UUw0KPiA+IHByb3RvY29sIGl0c2VsZg0K PiA+ID4gdGhhdCBjYW4gaGVscCB0byBkZXRlY3QgTkFUcy4gVGhlIHN1cHBvcnQgb2Ygc3VjaCBm ZWF0dXJlIHdpbGwsIA0KPiA+ID4gZS5nLiwNCj4gPiBlYXNlDQo+ID4gPiB0cm91Ymxlc2hvb3Rp bmcgd2hlbiBjb25uZWN0aXZpdHkgcHJvYmxlbXMgYXJlIGV4cGVyaWVuY2VkIG9uIHRoZSANCj4g PiA+IHBhdGggYmV0d2VlbiBhIGNsaWVudCBhbmQgYSBzZXJ2ZXIuDQo+ID4gPg0KPiA+ID4gQ2hl ZXJzLA0KPiA+ID4gTWVkDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gPiA+ID4gRGXCoDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+ID4gPiBbbWFp bHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb21dDQo+ID4gPiA+IEVudm95w6nC oDogamV1ZGkgMjYgb2N0b2JyZSAyMDE3IDA5OjQ0IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIA0K PiA+ID4gPiBJTVQvT0xOOyBGbGVtbWluZyBBbmRyZWFzZW47IEpvbiBTaGFsbG93OyBkb3RzQGll dGYub3JnIE9iamV0wqA6DQo+ID4gPiA+IFJFOiBbRG90c10gRE9UUyAmIE5BVCAod2FzIFJFOiBE T1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+ID4gPiA+ID4gbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbQ0KPiA+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjQsIDIwMTcg MjoyMCBQTQ0KPiA+ID4gPiA+IFRvOiBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2Nv LmNvbT47IEpvbiBTaGFsbG93DQo+ID4gPiA+ID4gPHN1cGpwcy0gaWV0ZkBqcHNoYWxsb3cuY29t PjsgZG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyAmIE5B VCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyANCj4gPiA+ID4gPiByZXZpZXcNCj4gPiA+ID4g PiAoLTA2KSkNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhpIEZsZW1taW5nLCBhbGwsDQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IENo ZWVycywNCj4gPiA+ID4gPiBNZWQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+ID4gPiA+ID4gPiBEZcKgOiBGbGVtbWluZyBBbmRyZWFzZW4gW21h aWx0bzpmYW5kcmVhc0BjaXNjby5jb21dIEVudm95w6nCoDoNCj4gPiA+ID4gPiA+IGx1bmRpDQo+ ID4gPiA+ID4gPiAyMyBvY3RvYnJlIDIwMTcgMTc6MzYgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQg SU1UL09MTjsgSm9uIA0KPiA+ID4gPiA+ID4gU2hhbGxvdzsgZG90c0BpZXRmLm9yZyBPYmpldMKg OiBSZTogRE9UUyAmIE5BVCAod2FzIFJFOiANCj4gPiA+ID4gPiA+IFtEb3RzXSBET1RTIFJlcXVp cmVtZW50cyByZXZpZXcgKC0wNikpDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiBPbiAxMC8yMy8xNyA4OjI4IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIHdyb3RlOg0KPiA+ID4gPiA+ID4gPiBIaSBKb24sIGFsbCwNCj4gPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+ID4gSSBhZ3JlZSB3aXRoIEZsZW1taW5nIHRoYXQgInNvbWUgbW9yZSB3 b3JrIiBpcyBuZWVkZWQuIA0KPiA+ID4gPiA+ID4gPiBJTUhPLCB0aGlzIGlzIGENCj4gPiA+ID4g PiA+IHR5cGljYWwgZGlzY3Vzc2lvbiB0byBpbmNsdWRlIGluIGEgZGVkaWNhdGVkIHNlY3Rpb24g aW4gdGhlIA0KPiA+ID4gPiA+ID4gRE9UUyBhcmNoaXRlY3R1cmUgSS1ELg0KPiA+ID4gPiA+ID4g QWdyZWVkLg0KPiA+ID4gPiA+ID4gPiA+RnJvbSBhIHJlcXVpcmVtZW50IHN0YW5kcG9pbnQsIHdl IGRvbid0IG5lZWQgdG8gZWxhYm9yYXRlIA0KPiA+ID4gPiA+ID4gPiA+aG93IHRoZQ0KPiA+ID4g PiA+ID4gcHJvdG9jb2xzIHdpbGwgZnVsZmlsIGl0LiBTSUctMTAgZG9lcyBldmVuIGEgbmljZSBq b2IgYnkgDQo+ID4gPiA+ID4gPiBjaXRpbmcNCj4gPiA+ID4gPiA+IFJGQzgwODUgd2hpY2ggcG9p bnRzIHRvIE5BVCB0cmF2ZXJzYWwgbWVjaGFuaXNtcy4gT25lIGNvdWxkIA0KPiA+ID4gPiA+ID4g cGljayBoaXMvaGVyIGZhdm9yaXRlIHByb3RvY29sIGZyb20gdGhlIGxpc3QgaW4gODA4NSB0byAN Cj4gPiA+ID4gPiA+IGRpc2NvdmVyIHRoZSBleHRlcm5hbCBJUCBhZGRyZXNzL3ByZWZpeCwgaWYg bmVlZGVkLiBFeHRlcm5hbCANCj4gPiA+ID4gPiA+IElQIGFkZHJlc3Nlcy9wcmVmaXhlcyBjYW4g YmUgSVB2NCBmb3IgYSBOQVQ0NCBvciBOQVQ2NCwgYnV0IA0KPiA+ID4gPiA+ID4gY2FuIGJlDQo+ ID4gPiA+ID4gPiBJUHY2IHByZWZpeGVzIGZvciBlbnRlcnByaXNlcyBkZXBsb3lpbmcgTlBUdjYs IGFuZCBzbyBvbi4NCj4gPiA+ID4gPiA+IFBhcnQgb2YgdGhlIGNoYWxsZW5nZSBoZXJlIGlzIHRo YXQgdGhlIGF0dGFjayB0YXJnZXQgYW5kIHRoZSANCj4gPiA+ID4gPiA+IERPVFMgY2xpZW50IGFy ZSBub3QgbmVjZXNzYXJpbHkgb25lIGFuZCB0aGUgc2FtZSwgd2hpY2ggDQo+ID4gPiA+ID4gPiBt YWtlcyBpdCBtb3JlIGRpZmZpY3VsdCB0byBkZXRlcm1pbmUgdGhlIHB1YmxpYy1mYWNpbmcgDQo+ ID4gPiA+ID4gPiBJUC1hZGRyZXNzL3BvcnQgdW5kZXIgYXR0YWNrIChhdCBsZWFzdCBpZiB0aGUg RE9UUyBjbGllbnQgaXMgDQo+ID4gPiA+ID4gPiBnb2luZyB0bw0KPiBkbyBpdCkuDQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBbTWVkXSBUaGlzIGlzIGV4YWN0bHkgdGhlIGtpbmQgb2YgdGhlIGRpc2N1 c3Npb24gdG8gaGF2ZS4gVGhhbmtzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gV2l0aCBvciB3aXRo b3V0IE5BVCwgRE9UUyBjbGllbnRzIGFyZSBhc3N1bWVkIHRvIGJlIGZlZCB3aXRoIA0KPiA+ID4g PiA+IHRoZQ0KPiA+ID4gPiBpbnRlcm5hbA0KPiA+ID4gPiA+IHRhcmdldChzKS4gVGhpcyBjYW4g YmUgYWNoaWV2ZWQgYnkgcHJvdmlzaW9uaW5nIChsaWtlbHkpIG9yIGJ5IA0KPiA+ID4gPiA+IGRp c2NvdmVyeQ0KPiA+ID4gPiBtZWFucw0KPiA+ID4gPiA+IChlLmcuLCByZXNpZGVudGlhbCBvciBz bWFsbCBlbnRlcnByaXNlIG5ldHdvcmtzKS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IENhbiB3ZSBh c3N1bWUgdGhhdCB0aGUgZGlzY292ZXJ5IG9mIHRoZSBleHRlcm5hbCBJUCANCj4gPiA+ID4gPiBh ZGRyZXNzL3ByZWZpeC8uLiBpcw0KPiA+ID4gPiBkb25lDQo+ID4gPiA+ID4gYnkgYSBET1RTIGNs aWVudCBvbmx5IGlmIGl0IGlzIGV4cGxpY2l0bHkgaW5zdHJ1Y3RlZCB0byBkbyBzbz8NCj4gPiA+ ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEluIHNvbWUgZGVwbG95bWVudHMsIERPVFMg Y2xpZW50cyBtYXkgYmUgcHJvdmlzaW9uZWQgd2l0aCANCj4gPiA+ID4gPiA+ID4gdGhlIHNldCBv Zg0KPiA+ID4gPiA+ID4gaW50ZXJuYWwgcmVzb3VyY2VzLCBzbyB0aGVyZSBpcyBubyBuZWVkIGZv ciBkaXNjb3ZlcnkuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEFsc28sIGFzIEpvbiBt ZW50aW9uZWQsIERPVFMgZ2F0ZXdheXMgY2FuIGJlIG9mIGhlbHAgdG8gDQo+ID4gPiA+ID4gPiA+ IHNldCB0aGUNCj4gPiA+ID4gPiA+IGFwcHJvcHJpYXRlIElQIGFkZHJlc3Nlcy9wcmVmaXhlcy9w b3J0IG51bWJlcnMgaW4gdGhlIA0KPiA+ID4gPiA+ID4gcHJlc2VuY2Ugb2YgdHJhbnNsYXRvcnMu DQo+ID4gPiA+ID4gPiBBZ3JlZWQgLSBidXQgdGhleSBzdGlsbCBuZWVkIGEgd2F5IHRvIGZpZ3Vy ZSBvdXQgdGhlIA0KPiA+ID4gPiA+ID4gcHJpdmF0ZS9wdWJsaWMgbWFwcGluZyBmb3IgYSBnaXZl biBhdHRhY2sgdGFyZ2V0Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gW01lZF0gQmVjYXVzZSBhIERE b1MgYXR0YWNrIGlzIG9ic2VydmVkIGZyb20gdGhlIGludGVybmFsIA0KPiA+ID4gPiA+IG5ldHdv cmssDQo+ID4gPiA+ID4gbWFwcGluZyhzKSBhcmUgbmVjZXNzYXJpbHkgbWFpbnRhaW5lZCBieSB0 aGUgb24tcGF0aCB0cmFuc2xhdG9yKHMpLg0KPiA+ID4gPiA+IE90aGVyd2lzZSwgdGhlIGluY29t aW5nIGF0dGFjayB0cmFmZmljIGNvdWxkbid0IGJlIGZvcndhcmRlZCANCj4gPiA+ID4gPiB0byBp bnRlcm5hbA0KPiA+ID4gPiBob3N0cy4NCj4gPiA+ID4gPiBUaGlzIG1vZGVsIGFzc3VtZXMgdGhh dCB0aGUgZ2F0ZXdheSBpcyBjb2xsb2NhdGVkIHdpdGggdGhlIE5BVC4NCj4gPiA+ID4gPiBTbywg dGhlIGdhdGV3YXkgY2FuIHJlcGxhY2UgdGhlIGludGVybmFsIElQIGFkZHJlc3MvcHJlZml4IA0K PiA+ID4gPiA+IHdpdGggdGhlIG9uZQ0KPiA+ID4gPiByZXRyaWV2ZXMNCj4gPiA+ID4gPiBmcm9t IHRoZSBOQVQgbWFwcGluZyB0YWJsZS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IERvIHlvdSBzZWUg YW55IGlzc3VlIHdpdGggdGhpcyBzY2hlbWU/DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gQW4g b3BlbiBxdWVzdGlvbiB0aG91Z2ggd291bGQgYmUgdG8gZGlzY3VzcyBpZiB0aGVyZSBpcyBhIA0K PiA+ID4gPiA+ID4gPiB2YWx1ZSBpbg0KPiA+ID4gPiA+ID4gaGF2aW5nIGEgZmVhdHVyZSBpbiB0 aGUgRE9UUyBwcm90b2NvbCB0byBpbmZvcm0gYSBET1RTIA0KPiA+ID4gPiA+ID4gY2xpZW50IHRo YXQgYSBOQVQgaXMgZGV0ZWN0ZWQgb24tcGF0aC4gVGhpcyBjYW4gYmUgcHJlc2VudGVkIA0KPiA+ ID4gPiA+ID4gYXMgYW4gaW5mb3JtYXRpb24gZWxlbWVudCByZXR1cm5lZCBieSB0aGUgc2VydmVy IHRvIHRoZSANCj4gPiA+ID4gPiA+IGNsaWVudC4gVGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUsIGZv ciBleGFtcGxlLCB1c2VkIGJ5IHRoZSANCj4gPiA+ID4gPiA+IGNsaWVudCB0byBhZGp1c3QgaXRz IEhUIGludGVydmFsLCBhZGp1c3QgdGhlIGludGVybmFsIElQIA0KPiA+ID4gPiA+ID4gYWRkcmVz c2VzL3ByZWZpeGVzIHRvIGJlDQo+IHByb3RlY3RlZCwgZXRjLg0KPiA+IE9waW5pb25zPw0KPiA+ ID4gPiA+ID4gSXQgc291bmRzIGFwcGVhbGluZywgYnV0IGl0J3MgdmVyeSBkaWZmaWN1bHQgdG8g ZG8gdGhpcyANCj4gPiA+ID4gPiA+IHJlbGlhYmx5LCBhbmQgaXQncyBub3QganVzdCBOQVRzIHRo YXQgYXJlIGFuIGlzc3VlIGhlcmU7IA0KPiA+ID4gPiA+ID4gRmlyZXdhbGxzIHByZXNlbnQgc2lt aWxhciBjaGFsbGVuZ2VzIChhbmQgdGhleSBtYXkgb3IgbWF5IA0KPiA+ID4gPiA+ID4gbm90IGJl IE5BVCdpbmcgaW5kaXZpZHVhbA0KPiA+ID4gZmxvd3MpLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IFtNZWRdIEkgZnVsbHkgYWdyZWUgdGhhdCBmaXJld2FsbHMgZGV0ZWN0IGlz IG1vcmUgY29tcGxleC4gDQo+ID4gPiA+ID4gTGV0J3MgcHV0IGl0DQo+ID4gPiA+IGFzaWRlDQo+ ID4gPiA+ID4gYW5kIGZvY3VzIG9uIHRoZSBOQVQgY2FzZS4NCj4gPiA+ID4NCj4gPiA+ID4gVGhl IHByZXNlbmNlIGFuZCBiZWhhdmlvciBvZiBOQVQgYW5kIEZpcmV3YWxsLCBhbmQga2VlcGFsaXZl IA0KPiA+ID4gPiBpbnRlcnZhbCBjYW4gYmUgZGV0ZXJtaW5lZCB1c2luZyBTVFVOIChkaXNjdXNz ZWQgaW4gDQo+ID4gPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzgwKS4NCj4g PiA+ID4NCj4gPiA+ID4gLVRpcnUNCj4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFdlIGNh biBjb25zaWRlciBtYW55IGFwcHJvYWNoZXMgdG8gZGV0ZWN0IGEgTkFULCBlLmcuLA0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gKDEpIFRoZSBET1RTIGNsaWVudCBpbnNlcnRzIGluIHRoZSBjb3JlIG1l c3NhZ2UgdGhlIElQIA0KPiA+ID4gPiA+IGFkZHJlc3MvcG9ydCBpdA0KPiA+ID4gPiB1c2VzIHRv DQo+ID4gPiA+ID4gc2VuZCB0aGUgcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuIFVwb24gcmVj ZWlwdCBvZiB0aGUgDQo+ID4gPiA+ID4gcmVxdWVzdCBieSB0aGUgRE9UUyBzZXJ2ZXIsIGl0IGNo ZWNrcyBpZiB0aGUgZW5jbG9zZWQgSVAgDQo+ID4gPiA+ID4gYWRkcmVzcy9wb3J0IG1hdGNoIHRo ZSBzb3VyY2UNCj4gPiA+ID4gSVANCj4gPiA+ID4gPiBhZGRyZXNzL3BvcnQgb2YgdGhlIHJlY2Vp dmVkIHBhY2tldC4gSWYgeWVzLCB0aGUgc2VydmVyIHNldHMgDQo+ID4gPiA+ID4gaW4gdGhlDQo+ ID4gPiA+IHJlc3BvbnNlIGENCj4gPiA+ID4gPiBkZWRpY2F0ZWQgcGFyYW1ldGVyIHRvIGluZGlj YXRlIHRoYXQgYSB0cmFuc2xhdG9yIGlzIGRldGVjdGVkDQo+ID4gPiA+ID4gb24tDQo+ID4gcGF0 aC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICgyKSBUaGUgRE9UUyBzZXJ2ZXIgaW5zZXJ0cyBzeXN0 ZW1hdGljYWxseSB0aGUgc291cmNlIElQIA0KPiA+ID4gPiA+IGFkZHJlc3MvcG9ydCBpbg0KPiA+ ID4gPiBhDQo+ID4gPiA+ID4gcmVzcG9uc2UgdG8gYSBtZXNzYWdlIGZyb20gYSBET1RTIGNsaWVu dC4gVXBvbiByZWNlaXB0IG9mIHRoYXQgDQo+ID4gPiA+ID4gcmVzcG9uc2UsIHRoZSBET1RTIGNs aWVudCBjb21wYXJlcyB0aGUgZW5jbG9zZWQgYWRkcmVzcy9wb3J0IA0KPiA+ID4gPiA+IHdpdGgg dGhlIG9uZXMgaXQgdXNlZA0KPiA+ID4gPiB0bw0KPiA+ID4gPiA+IHNlbmQgdGhlIHJlcXVlc3Qg dG8gZGV0ZWN0IGFueSBtaXNtYXRjaC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiAtLSBGbGVtbWluZw0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IENo ZWVycywNCj4gPiA+ID4gPiA+ID4gTWVkDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+PiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0gRGXCoDogRG90cyANCj4gPiA+ID4gPiA+ID4+IFtt YWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvbiBTaGFsbG93IA0K PiA+ID4gPiA+ID4gPj4gRW52b3nDqcKgOiBsdW5kaSAyMyBvY3RvYnJlIDIwMTcgMTM6MTggw4DC oDogJ0ZsZW1taW5nIA0KPiA+ID4gPiA+ID4gPj4gQW5kcmVhc2VuJzsgZG90c0BpZXRmLm9yZyBP YmpldMKgOiBSZTogW0RvdHNdIERPVFMgDQo+ID4gPiA+ID4gPiA+PiBSZXF1aXJlbWVudHMgcmV2 aWV3ICgtMDYpDQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gSGkgRmxlbW1pbmcsDQo+ ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gVGhlIHdheSBteSBtaW5kIHdvcmtzIGlzIHRv IHRoaW5rIG9mIGEgcHJhY3RpY2FsIA0KPiA+ID4gPiA+ID4gPj4gc2l0dWF0aW9uIGFuZCBzZWUg aWYgdGhpbmdzIGZpdC4NCj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiBBcyBJIHJlYWQg U0lHLTAxMCwgdGhlcmUgY291bGQgYmUgYSBET1RTIGNsaWVudCB3aXRoIGEgDQo+ID4gPiA+ID4g PiA+PiBtYW5hZ2VtZW50IElQIGFkZHJlc3MgdGhhdCBpcyBSRkMxOTE4IC0gdGhpcyBjbGllbnQg Y291bGQgDQo+ID4gPiA+ID4gPiA+PiBiZSBtb25pdG9yaW5nIE5ldGZsb3cgaW5mb3JtYXRpb24g YW5kIGNhbiByZXF1ZXN0IA0KPiA+ID4gPiA+ID4gPj4gbWl0aWdhdGlvbiBmb3IgdGhlIGFwcHJv cHJpYXRlIHB1YmxpYyBJUHMNCj4gPiA+ID4gPiA+IHRoYXQNCj4gPiA+ID4gPiA+ID4+IGFyZSBi ZWluZyBtb25pdG9yZWQuICBTbyBTSUctMDEwIGlzIG5lZWRlZCBmb3IgdGhpcyB1c2UgY2FzZS4N Cj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiBJdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkg b2YgdGhlIERPVFMgc2VydmVyIGFzIHRvIHdoZXRoZXIgDQo+ID4gPiA+ID4gPiA+PiBpdCBhY2Nl cHRzIGEgbWl0aWdhdGlvbiByZXF1ZXN0IGZvciBhIHBhcnRpY3VsYXIgdGFyZ2V0IA0KPiA+ID4g PiA+ID4gPj4gaXAgKG9yIGRvbWFpbg0KPiA+ID4gPiBldGMuKSBvcg0KPiA+ID4gPiA+IG5vdC4N Cj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiBJZiB0aGVyZSBpcyBnb2luZyB0byBiZSBh IE5BVCBib3JkZXIgd2hlcmUgcHVibGljIElQcyBhcmUgDQo+ID4gPiA+ID4gPiA+PiBtYXBwZWQg aW50byBwcml2YXRlIElQcyAoYW5kIHZpY2UgdmVyc2EpLCBJIHdvdWxkIHRoZW4gDQo+ID4gPiA+ ID4gPiA+PiBleHBlY3QgdGhlcmUgdG8gYmUgYSBET1RTIGdhdGV3YXkgYmV0d2VlbiB0aGVzZSAy IHpvbmVzLCANCj4gPiA+ID4gPiA+ID4+IGFuZCBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2Yg dGhlIERPVFMgZ2F0ZXdheSB0byBkbyANCj4gPiA+ID4gPiA+ID4+IGFueSB0YXJnZXQtaXANCj4g PiBtYXBwaW5ncy4NCj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiBSZWdhcmRzDQo+ID4g PiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gSm9uDQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ID4+IEZyb206IERv dHMgW21haWx0bzppZXRmLXN1cGpwcy1kb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPiA+ID4g PiA+ID4gPj4gQmVoYWxmIE9mIEZsZW1taW5nIEFuZHJlYXNlbg0KPiA+ID4gPiA+ID4gPj4gU2Vu dDogMjIgT2N0b2JlciAyMDE3IDIwOjE3DQo+ID4gPiA+ID4gPiA+PiBUbzogZG90czsgZHJhZnQt aWV0Zi1kb3RzLXJlcXVpcmVtZW50c0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPj4gU3ViamVjdDog W0RvdHNdIERPVFMgUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KQ0KPiA+ID4gPiA+ID4gPj4NCj4g PiA+ID4gPiA+ID4+IEdyZWV0aW5ncw0KPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4+IEkg aGF2ZSByZXZpZXdlZCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIERPVFMgDQo+ID4gPiA+ID4g PiA+PiByZXF1aXJlbWVudHMgZHJhZnQgDQo+ID4gPiA+ID4gPiA+PiAoaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaWQvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0wNi50eHQpLg0KPiA+ID4gPiA+ ID4gPj4gSW4NCj4gPiA+ID4gPiA+IGdlbmVyYWwsDQo+ID4gPiA+ID4gPiA+PiBJIHRoaW5rIHRo ZSBkcmFmdCBpcyBpbiBnb29kIHNoYXBlIHdpdGggb25seSBhIGZldyBlZGl0cyANCj4gPiA+ID4g PiA+ID4+IHJlcXVpcmVkLCBzbyBJIGhvcGUgd2UgY2FuIG1vdmUgdG8gV0dMQyBzb29uLiBJIGhh dmUgYSANCj4gPiA+ID4gPiA+ID4+IGZldyBjb21tZW50cyBiZWxvdyAob2Ygd2hpY2gNCj4gPiA+ ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ID4gPj4gTkFUIG9uZSBpcyB0aGUgb25seSByZWFsIHN1YnN0 YW50aWFsIG9uZSkuIEkgaGF2ZSBhbHNvIA0KPiA+ID4gPiA+ID4gPj4gc3VibWl0dGVkIGEgcHVs bCByZXF1ZXN0IHdpdGggYSBmZXcgbml0IGZpeGVzIG9uIEdpdEh1YjoNCj4gPiA+ID4gPiA+ID4+ DQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gU2VjdGlvbiAxLjINCj4gPiA+ID4gPiA+ ID4+IC0gVGhlIGRlZmluaXRpb24gb2YgIkRPVFMgU2lnbmFsIiBpcyBzbGlnaHRseSANCj4gPiA+ ID4gPiA+ID4+IGluY29uc2lzdGVudCB3aXRoIHRoZSByZXNwZWN0aXZlICJDbGllbnQgU2lnbmFs IiBhbmQgIlNlcnZlciBTaWduYWwiIGRlZmluaXRpb25zLg0KPiA+ID4gPiA+ID4gPj4NCj4gPiA+ ID4gPiA+ID4+IFNJRy0wMDU6DQo+ID4gPiA+ID4gPiA+PiAtIE5vdCBjbGVhciB0aGF0IGFsd2F5 cyByZXF1aXJpbmcgIm51bWJlciBvZiBwYWNrZXRzIg0KPiA+ID4gPiA+ID4gPj4gbWV0cmljcyBp cyBtZWFuaW5nZnVsLiBDb25zaWRlciBUQ1AtYmFzZWQgYXR0YWNrcyBmb3IgDQo+ID4gPiA+ID4g PiA+PiBleGFtcGxlLiBOdW1iZXIgb2YgYnl0ZXMgbWF5IGFsd2F5cyBiZSBvayAtIGFib3ZlIGFu ZCANCj4gPiA+ID4gPiA+ID4+IGJleW9uZCB0aGF0IGl0IHNob3VsZCBwcm9iYWJseSBiZSBleHRl bnNpYmxlIGFuZC9vciANCj4gPiA+ID4gPiA+ID4+IGF0dGFjaw0KPiBkZXBlbmRlbnQuDQo+ID4g PiA+ID4gPiA+PiAtIEkgZG9uJ3QgdGhpbmsgdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudCBzaG91 bGQgZ2V0IGludG8gDQo+ID4gPiA+ID4gPiA+PiBzcGVjaWZ5aW5nDQo+ID4gPiA+ID4gPiB0aW1l cg0KPiA+ID4gPiA+ID4gPj4gdmFsdWVzIC0gZXhwb250aWFsIGJhY2tvZmYgd2l0aCBzb21lIG1h eGltdW0gdmFsdWUgc2VlbXMgDQo+ID4gPiA+ID4gPiA+PiBhYm91dCB0aGUNCj4gPiA+ID4gPiA+ IHJpZ2h0DQo+ID4gPiA+ID4gPiA+PiBsZXZlbCBvZiBkZXRhaWwgaGVyZS4NCj4gPiA+ID4gPiA+ ID4+DQo+ID4gPiA+ID4gPiA+PiBTSUctMDA5Og0KPiA+ID4gPiA+ID4gPj4gLSBUbyBiZSBjbGVh ciwgdGhlIGNvbmZsaWN0cyBvbmx5IGFwcGx5IHdpdGhpbiBhIHNpbmdsZSANCj4gPiA+ID4gPiA+ ID4+IGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgcmlnaHQgPyBGb3IgZXhhbXBsZSwgaWYgYSBjbGll bnQgDQo+ID4gPiA+ID4gPiA+PiB0ZWxscyB0aGUgc2FtZSBkb21haW4gdG8gYWx0ZXJuYXRlbHkg dHVybiBvbi9vZmYgDQo+ID4gPiA+ID4gPiA+PiBtaXRpZ2F0aW9uIGZvciBhIGdpdmVuIHByZWZp eCwgcm91dGUgZmxhcHBpbmcNCj4gPiA+ID4gPiA+IG1heQ0KPiA+ID4gPiA+ID4gPj4gb2NjdXIu IFRoZSBzYW1lIGNvbmNlcm4gZG9lcyBub3QgYXBwbHkgaWYgYSBjbGllbnQgdGVsbHMgDQo+ID4g PiA+ID4gPiA+PiB0d28gZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlIGRvbWFpbnMgdG8gcmVzcGVj dGl2ZSB0dXJuIA0KPiA+ID4gPiA+ID4gPj4gbWl0aWdhdGlvbiBvbiAoZG9tYWluIDEpIGFuZA0K PiA+ID4gPiA+ID4gb2ZmDQo+ID4gPiA+ID4gPiA+PiAoZG9tYWluIDIpLiBJZiBzbywgY2FuIHdl IGNsYXJpZnkgdGhhdCAoYWxzbyBpbiBsaWV1IG9mIA0KPiA+ID4gPiA+ID4gPj4gc29tZSBvZiB0 aGUNCj4gPiA+ID4gPiA+IG11bHRpLQ0KPiA+ID4gPiA+ID4gPj4gaG9taW5nIGNvbW1lbnRzIHJh aXNlZCBwcmV2aW91c2x5KSA/DQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gU0lHLTAx MDoNCj4gPiA+ID4gPiA+ID4+IC0gRE9UUyBDbGllbnQgYmVoaW5kIE5BVC4gT24gb25lIGhhbmQs IGl0IHNlZW1zIA0KPiA+ID4gPiA+ID4gPj4gcmVhc29uYWJsZSB0byBoYXZlIHRoaXMgcmVxdWly ZW1lbnQgc2luY2UgY2xpZW50cyBmb3IgDQo+ID4gPiA+ID4gPiA+PiBzdXJlIGNhbiBiZSBiZWhp bmQgTkFUcywgYW5kDQo+ID4gPiA+IHdpdGgNCj4gPiA+ID4gPiB0aGluZ3MNCj4gPiA+ID4gPiA+ ID4+IGxpa2UgZHluYW1pYyBETlMsIHRoZXkgY2FuICAgICBjZXJ0YWlubHkgYmUgcmVhY2hhYmxl LiBIb3dldmVyLA0KPiA+IGlmDQo+ID4gPiA+IHdlDQo+ID4gPiA+ID4gPiBkbw0KPiA+ID4gPiA+ ID4gPj4gd2FudCB0byBhbGxvdyBmb3IgdGhpcyBzY2VuYXJpbywgYW5kIGluIHBhcnRpY3VsYXIg Zm9yIA0KPiA+ID4gPiA+ID4gPj4gdGhlIERPVFMgY2xpZW50DQo+ID4gPiA+ID4gPiB0bw0KPiA+ ID4gPiA+ID4gPj4gaGF2ZSBhIHByaXZhdGUgSVAtYWRkcmVzcyAocG90ZW50aWFsbHkgYmVoaW5k IG11bHRpcGxlIA0KPiA+ID4gPiA+ID4gPj4gTkFUcyksIHRoZW4gd2UNCj4gPiA+ID4gPiA+IGhh dmUNCj4gPiA+ID4gPiA+ID4+IG1vcmUgd29yayB0byBkbyBiZWNhdXNlIGl0IHdvbid0IGRvIHRo ZSBET1RTIHNlcnZlciBhbnkgDQo+ID4gPiA+ID4gPiA+PiBnb29kIHRvIGdldCBhIG1pdGlnYXRp b24gcmVxdWVzdCByZWZlcnJpbmcgdG8gdGhhdCANCj4gPiA+ID4gPiA+ID4+IHByaXZhdGUgSVAt YWRkcmVzcyAob3INCj4gPiA+ID4gcHJlZml4KS4NCj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4g PiA+Pg0KPiA+ID4gPiA+ID4gPj4gVGhhbmtzDQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4g Pj4gLS0gRmxlbW1pbmcNCj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gPj4gRG90 cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+ID4+IERvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+ID4gPiA+ ID4gPj4NCj4gPiA+ID4gPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPiA+ID4gPiA+PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+ ID4gPj4gRG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4gPiA+ID4gPiA+IC4NCj4gPiA+ID4gPiA+ID4NCj4g PiA+ID4gPg0KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gPiA+ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBEb3RzQGll dGYub3JnDQo+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k b3RzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG90 cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG90cw0K From nobody Thu Oct 26 05:09:34 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611B213836B for ; Thu, 26 Oct 2017 05:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxztyV9EvM6w for ; Thu, 26 Oct 2017 05:09:30 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A2413A292 for ; Thu, 26 Oct 2017 05:09:30 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 5737F120BC1; Thu, 26 Oct 2017 14:09:29 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 37E5A8006E; Thu, 26 Oct 2017 14:09:29 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0361.001; Thu, 26 Oct 2017 14:09:28 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Flemming Andreasen" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAGjp6AACQhAAAAYgT5UAABUQNgAACCGwAAAIl5gAAA3jTgAAYVpgA= Date: Thu, 26 Oct 2017 12:09:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05E858@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 12:09:33 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgW21h aWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KPiBFbnZvecOpwqA6IGpl dWRpIDI2IG9jdG9icmUgMjAxNyAxMjo1OA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQv T0xOOyBGbGVtbWluZyBBbmRyZWFzZW47IEpvbiBTaGFsbG93Ow0KPiBkb3RzQGlldGYub3JnDQo+ IE9iamV0wqA6IFJFOiBbRG90c10gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50 cyByZXZpZXcgKC0wNikpDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+IFttYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4gPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNiwgMjAx NyAyOjIxIFBNDQo+ID4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dh clJlZGR5X0tvbmRhQE1jQWZlZS5jb20+Ow0KPiA+IEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJl YXNAY2lzY28uY29tPjsgSm9uIFNoYWxsb3cgPHN1cGpwcy0NCj4gPiBpZXRmQGpwc2hhbGxvdy5j b20+OyBkb3RzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFtEb3RzXSBET1RTICYgTkFUICh3 YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KSkNCj4gPg0KPiA+IFJlLSwNCj4g Pg0KPiA+IEkgaGVhciB5b3UuIE15IHRha2UgaXMgdGhhdCB3ZSBkb24ndCBuZWVkIHRvIHJlY29t bWVuZCB3aGljaCBjb21wYW5pb24NCj4gPiAicHJvdG9jb2xzL21lY2hhbmlzbXMiIG5lZWQgdG8g YmUgc3VwcG9ydGVkIGZvciBOQVQvRlcgdHJhdmVyc2FsDQo+ID4gcHVycG9zZXMuIEhhdmluZyBh IGRpc2N1c3Npb24gYXQgdGhlIHNhbWUgbGV2ZWwgaW4gODA4NSB3b3VsZCBiZQ0KPiBzdWZmaWNp ZW50LA0KPiA+IElNSE8uDQo+ID4NCj4gPiBMZXQncyBmb2N1cyBvbiB0aGUgc2ltcGxlIGJ1aWx0 LWluIGZlYXR1cmUgZm9yIE5BVCBkZXRlY3QuDQo+IA0KPiBJIGRvbuKAmXQgdGhpbmsgdGhlIHNp bXBsZSBidWlsdC1pbiBmZWF0dXJlIGlzIHN1ZmZpY2llbnQsDQoNCltNZWRdIEl0IGRlcGVuZHMg Zm9yIHdoYXQgcHVycG9zZS4gRm9yIGV4YW1wbGUsIHRoZSBidWlsdC1pbiBmZWF0dXJlIHdpbGwg aGVscCB0cm91Ymxlc2hvb3Rpbmcgd2hlbiBwcm9ibGVtcyBhcmUgZXhwZXJpZW5jZWQgdG8gZGVs aXZlciBET1RTIG1lc3NhZ2VzIGluIHRoZSBwcmVzZW5jZSBvZiBOQVRzLiANCg0KIERPVFMgY2xp ZW50IHdpbGwNCj4gaGF2ZSB0byByZWx5IG9uIG1lY2hhbmlzbXMgZGlzY3Vzc2VkIGluIDgwODUg Zm9yIGJvdGggZmlyZXdhbGwgYW5kIE5BVA0KPiB0cmF2ZXJzYWwuDQoNCltNZWRdIEknbSBub3Qg c3VyZS4gQWN0dWFsbHksIGl0IGRlcGVuZHMgd2hldGhlciB3ZSB3YW50IHRvICoqIG9wdGltaXpl ICoqIHRoZSBrZWVwYWxpdmUgbWVzc2FnZXMgYW5kIGF2b2lkIG92ZXJsb2FkaW5nIHRoZSBuZXR3 b3JrLiBIYXZpbmcgYSBOQVQvRlcgdHJhdmVyc2FsIHByb3RvY29sIHRoYXQgYWxsb3dzIHRvIGxl YXJuIHRoZSBOQVQvRlcgdmFsaWRpdHkgbGlmZXRpbWUgd2lsbCBhbGxvdyB0byBhZGp1c3QgdGhl IGtlZXAgYWxpdmUgaW50ZXJ2YWwuIFRoYXQncyBvbmx5IGFuIG9wdGltaXphdGlvbi4gDQoNCj4g DQo+IC1UaXJ1DQo+IA0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4gPiAtLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERlwqA6IEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkNCj4gPiA+IFttYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0N Cj4gPiA+IEVudm95w6nCoDogamV1ZGkgMjYgb2N0b2JyZSAyMDE3IDEwOjM2DQo+ID4gPiDDgMKg OiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBGbGVtbWluZyBBbmRyZWFzZW47IEpvbiBTaGFs bG93Ow0KPiA+ID4gZG90c0BpZXRmLm9yZyBPYmpldMKgOiBSRTogW0RvdHNdIERPVFMgJiBOQVQg KHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMNCj4gPiA+IHJldmlldyAoLTA2KSkNCj4gPiA+DQo+ ID4gPiBCdXQgTkFUcyBhcmUgbm90IHRoZSBvbmx5IHByb2JsZW0sIGZpcmV3YWxscyB3aWxsIGFs c28gYmUgbW9zdCBsaWtlbHkNCj4gPiA+IHByZXNlbnQsIGFuZCBTVFVOIGhlbHBzIGRpc2NvdmVy IGJvdGggTkFUcyBhbmQgZmlyZXdhbGxzIGFuZCB1c2VmdWwNCj4gPiA+IGV2ZW4gaW4gSVB2NiBu ZXR3b3JrcyB0byBkZXRlcm1pbmUgdGhlIGtlZXBhbGl2ZSBpbnRlcnZhbCBvZiBmaXJld2FsbC4N Cj4gPiA+DQo+ID4gPiAtVGlydQ0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiA+ID4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+ID4g PiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21dDQo+ID4gPiA+IFNlbnQ6IFRo dXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDE6NTIgUE0NCj4gPiA+ID4gVG86IEtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkNCj4gPiA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47 DQo+ID4gPiA+IEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPjsgSm9uIFNo YWxsb3cgPHN1cGpwcy0NCj4gPiA+ID4gaWV0ZkBqcHNoYWxsb3cuY29tPjsgZG90c0BpZXRmLm9y Zw0KPiA+ID4gPiBTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBS ZXF1aXJlbWVudHMgcmV2aWV3DQo+ID4gPiA+ICgtMDYpKQ0KPiA+ID4gPg0KPiA+ID4gPiBUaXJ1 LA0KPiA+ID4gPg0KPiA+ID4gPiBZZXMsIFNUVU4gY2FuIGJlIGxpc3RlZCBhcyBwYXJ0IG9mIHRo ZSBleGlzdGluZyB0b29scyBib3ggKGFtb25nIHRoZQ0KPiA+ID4gbGluZXMgb2YNCj4gPiA+ID4g d2hhdCBpcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiA4MDg1KS4NCj4gPiA+ID4NCj4gPiA+ID4gSSBk b24ndCB0aGluayB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIHJlcXVpcmUgU1RVTiBzdXBwb3J0IGJ5 IERPVFMNCj4gPiA+IGNsaWVudHMuDQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBwcm9wb3NhbCBpcyB0 byBpbmNsdWRlIGEgc2ltcGxlIGJ1aWx0LWluIGZlYXR1cmUgaW4gdGhlIERPVFMNCj4gPiA+IHBy b3RvY29sIGl0c2VsZg0KPiA+ID4gPiB0aGF0IGNhbiBoZWxwIHRvIGRldGVjdCBOQVRzLiBUaGUg c3VwcG9ydCBvZiBzdWNoIGZlYXR1cmUgd2lsbCwNCj4gPiA+ID4gZS5nLiwNCj4gPiA+IGVhc2UN Cj4gPiA+ID4gdHJvdWJsZXNob290aW5nIHdoZW4gY29ubmVjdGl2aXR5IHByb2JsZW1zIGFyZSBl eHBlcmllbmNlZCBvbiB0aGUNCj4gPiA+ID4gcGF0aCBiZXR3ZWVuIGEgY2xpZW50IGFuZCBhIHNl cnZlci4NCj4gPiA+ID4NCj4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiBNZWQNCj4gPiA+ID4NCj4g PiA+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+ID4gPiBEZcKgOiBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+ID4gPiA+ID4gW21haWx0bzpUaXJ1bWFsZXN3YXJSZWRk eV9Lb25kYUBNY0FmZWUuY29tXQ0KPiA+ID4gPiA+IEVudm95w6nCoDogamV1ZGkgMjYgb2N0b2Jy ZSAyMDE3IDA5OjQ0IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkDQo+ID4gPiA+ID4gSU1UL09MTjsg RmxlbW1pbmcgQW5kcmVhc2VuOyBKb24gU2hhbGxvdzsgZG90c0BpZXRmLm9yZyBPYmpldMKgOg0K PiA+ID4gPiA+IFJFOiBbRG90c10gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50 cyByZXZpZXcgKC0wNikpDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gPiA+ID4gPiBGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiA+ID4gPiA+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20NCj4gPiA+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjQsIDIwMTcgMjoyMCBQ TQ0KPiA+ID4gPiA+ID4gVG86IEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29t PjsgSm9uIFNoYWxsb3cNCj4gPiA+ID4gPiA+IDxzdXBqcHMtIGlldGZAanBzaGFsbG93LmNvbT47 IGRvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyAmIE5B VCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcNCj4gPiA+ID4gPiA+ICgtMDYpKQ0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEhpIEZsZW1taW5nLCBhbGwsDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g Q2hlZXJzLA0KPiA+ID4gPiA+ID4gTWVkDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAtLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+ID4gPiA+ID4gRGXCoDogRmxlbW1pbmcgQW5k cmVhc2VuIFttYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tXSBFbnZvecOpwqA6DQo+ID4gPiA+ID4g PiA+IGx1bmRpDQo+ID4gPiA+ID4gPiA+IDIzIG9jdG9icmUgMjAxNyAxNzozNiDDgMKgOiBCT1VD QURBSVIgTW9oYW1lZCBJTVQvT0xOOyBKb24NCj4gPiA+ID4gPiA+ID4gU2hhbGxvdzsgZG90c0Bp ZXRmLm9yZyBPYmpldMKgOiBSZTogRE9UUyAmIE5BVCAod2FzIFJFOiBbRG90c10NCj4gPiA+ID4g PiA+ID4gRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKQ0KPiA+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBPbiAxMC8yMy8xNyA4OjI4 IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+ID4gPiA+ID4gPiA+ IEhpIEpvbiwgYWxsLA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gSSBhZ3JlZSB3 aXRoIEZsZW1taW5nIHRoYXQgInNvbWUgbW9yZSB3b3JrIiBpcyBuZWVkZWQuIElNSE8sDQo+ID4g PiA+ID4gPiA+ID4gdGhpcyBpcyBhDQo+ID4gPiA+ID4gPiA+IHR5cGljYWwgZGlzY3Vzc2lvbiB0 byBpbmNsdWRlIGluIGEgZGVkaWNhdGVkIHNlY3Rpb24gaW4gdGhlDQo+ID4gPiA+ID4gPiA+IERP VFMgYXJjaGl0ZWN0dXJlIEktRC4NCj4gPiA+ID4gPiA+ID4gQWdyZWVkLg0KPiA+ID4gPiA+ID4g PiA+ID5Gcm9tIGEgcmVxdWlyZW1lbnQgc3RhbmRwb2ludCwgd2UgZG9uJ3QgbmVlZCB0byBlbGFi b3JhdGUNCj4gPiA+ID4gPiA+ID4gPiA+aG93IHRoZQ0KPiA+ID4gPiA+ID4gPiBwcm90b2NvbHMg d2lsbCBmdWxmaWwgaXQuIFNJRy0xMCBkb2VzIGV2ZW4gYSBuaWNlIGpvYiBieQ0KPiA+ID4gPiA+ ID4gPiBjaXRpbmcNCj4gPiA+ID4gPiA+ID4gUkZDODA4NSB3aGljaCBwb2ludHMgdG8gTkFUIHRy YXZlcnNhbCBtZWNoYW5pc21zLiBPbmUgY291bGQNCj4gPiA+ID4gPiA+ID4gcGljayBoaXMvaGVy IGZhdm9yaXRlIHByb3RvY29sIGZyb20gdGhlIGxpc3QgaW4gODA4NSB0bw0KPiA+ID4gPiA+ID4g PiBkaXNjb3ZlciB0aGUgZXh0ZXJuYWwgSVAgYWRkcmVzcy9wcmVmaXgsIGlmIG5lZWRlZC4gRXh0 ZXJuYWwNCj4gPiA+ID4gPiA+ID4gSVAgYWRkcmVzc2VzL3ByZWZpeGVzIGNhbiBiZSBJUHY0IGZv ciBhIE5BVDQ0IG9yIE5BVDY0LCBidXQNCj4gPiA+ID4gPiA+ID4gY2FuIGJlDQo+ID4gPiA+ID4g PiA+IElQdjYgcHJlZml4ZXMgZm9yIGVudGVycHJpc2VzIGRlcGxveWluZyBOUFR2NiwgYW5kIHNv IG9uLg0KPiA+ID4gPiA+ID4gPiBQYXJ0IG9mIHRoZSBjaGFsbGVuZ2UgaGVyZSBpcyB0aGF0IHRo ZSBhdHRhY2sgdGFyZ2V0IGFuZCB0aGUNCj4gPiA+ID4gPiA+ID4gRE9UUyBjbGllbnQgYXJlIG5v dCBuZWNlc3NhcmlseSBvbmUgYW5kIHRoZSBzYW1lLCB3aGljaCBtYWtlcw0KPiA+ID4gPiA+ID4g PiBpdCBtb3JlIGRpZmZpY3VsdCB0byBkZXRlcm1pbmUgdGhlIHB1YmxpYy1mYWNpbmcNCj4gPiA+ ID4gPiA+ID4gSVAtYWRkcmVzcy9wb3J0IHVuZGVyIGF0dGFjayAoYXQgbGVhc3QgaWYgdGhlIERP VFMgY2xpZW50IGlzDQo+IGdvaW5nIHRvDQo+ID4gZG8gaXQpLg0KPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+IFtNZWRdIFRoaXMgaXMgZXhhY3RseSB0aGUga2luZCBvZiB0aGUgZGlzY3Vzc2lvbiB0 byBoYXZlLg0KPiBUaGFua3MuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gV2l0aCBvciB3aXRo b3V0IE5BVCwgRE9UUyBjbGllbnRzIGFyZSBhc3N1bWVkIHRvIGJlIGZlZCB3aXRoIHRoZQ0KPiA+ ID4gPiA+IGludGVybmFsDQo+ID4gPiA+ID4gPiB0YXJnZXQocykuIFRoaXMgY2FuIGJlIGFjaGll dmVkIGJ5IHByb3Zpc2lvbmluZyAobGlrZWx5KSBvciBieQ0KPiA+ID4gPiA+ID4gZGlzY292ZXJ5 DQo+ID4gPiA+ID4gbWVhbnMNCj4gPiA+ID4gPiA+IChlLmcuLCByZXNpZGVudGlhbCBvciBzbWFs bCBlbnRlcnByaXNlIG5ldHdvcmtzKS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBDYW4gd2Ug YXNzdW1lIHRoYXQgdGhlIGRpc2NvdmVyeSBvZiB0aGUgZXh0ZXJuYWwgSVANCj4gPiA+ID4gPiA+ IGFkZHJlc3MvcHJlZml4Ly4uIGlzDQo+ID4gPiA+ID4gZG9uZQ0KPiA+ID4gPiA+ID4gYnkgYSBE T1RTIGNsaWVudCBvbmx5IGlmIGl0IGlzIGV4cGxpY2l0bHkgaW5zdHJ1Y3RlZCB0byBkbyBzbz8N Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IEluIHNvbWUgZGVwbG95 bWVudHMsIERPVFMgY2xpZW50cyBtYXkgYmUgcHJvdmlzaW9uZWQgd2l0aA0KPiA+ID4gPiA+ID4g PiA+IHRoZSBzZXQgb2YNCj4gPiA+ID4gPiA+ID4gaW50ZXJuYWwgcmVzb3VyY2VzLCBzbyB0aGVy ZSBpcyBubyBuZWVkIGZvciBkaXNjb3ZlcnkuDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gPiBBbHNvLCBhcyBKb24gbWVudGlvbmVkLCBET1RTIGdhdGV3YXlzIGNhbiBiZSBvZiBoZWxw IHRvIHNldA0KPiA+ID4gPiA+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ID4gPiBhcHByb3ByaWF0ZSBJ UCBhZGRyZXNzZXMvcHJlZml4ZXMvcG9ydCBudW1iZXJzIGluIHRoZSBwcmVzZW5jZQ0KPiA+ID4g PiA+ID4gPiBvZiB0cmFuc2xhdG9ycy4NCj4gPiA+ID4gPiA+ID4gQWdyZWVkIC0gYnV0IHRoZXkg c3RpbGwgbmVlZCBhIHdheSB0byBmaWd1cmUgb3V0IHRoZQ0KPiA+ID4gPiA+ID4gPiBwcml2YXRl L3B1YmxpYyBtYXBwaW5nIGZvciBhIGdpdmVuIGF0dGFjayB0YXJnZXQuDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gW01lZF0gQmVjYXVzZSBhIEREb1MgYXR0YWNrIGlzIG9ic2VydmVkIGZyb20g dGhlIGludGVybmFsDQo+ID4gPiA+ID4gPiBuZXR3b3JrLA0KPiA+ID4gPiA+ID4gbWFwcGluZyhz KSBhcmUgbmVjZXNzYXJpbHkgbWFpbnRhaW5lZCBieSB0aGUgb24tcGF0aA0KPiB0cmFuc2xhdG9y KHMpLg0KPiA+ID4gPiA+ID4gT3RoZXJ3aXNlLCB0aGUgaW5jb21pbmcgYXR0YWNrIHRyYWZmaWMg Y291bGRuJ3QgYmUgZm9yd2FyZGVkIHRvDQo+ID4gPiA+ID4gPiBpbnRlcm5hbA0KPiA+ID4gPiA+ IGhvc3RzLg0KPiA+ID4gPiA+ID4gVGhpcyBtb2RlbCBhc3N1bWVzIHRoYXQgdGhlIGdhdGV3YXkg aXMgY29sbG9jYXRlZCB3aXRoIHRoZSBOQVQuDQo+ID4gPiA+ID4gPiBTbywgdGhlIGdhdGV3YXkg Y2FuIHJlcGxhY2UgdGhlIGludGVybmFsIElQIGFkZHJlc3MvcHJlZml4IHdpdGgNCj4gPiA+ID4g PiA+IHRoZSBvbmUNCj4gPiA+ID4gPiByZXRyaWV2ZXMNCj4gPiA+ID4gPiA+IGZyb20gdGhlIE5B VCBtYXBwaW5nIHRhYmxlLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IERvIHlvdSBzZWUgYW55 IGlzc3VlIHdpdGggdGhpcyBzY2hlbWU/DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IEFu IG9wZW4gcXVlc3Rpb24gdGhvdWdoIHdvdWxkIGJlIHRvIGRpc2N1c3MgaWYgdGhlcmUgaXMgYQ0K PiA+ID4gPiA+ID4gPiA+IHZhbHVlIGluDQo+ID4gPiA+ID4gPiA+IGhhdmluZyBhIGZlYXR1cmUg aW4gdGhlIERPVFMgcHJvdG9jb2wgdG8gaW5mb3JtIGEgRE9UUyBjbGllbnQNCj4gPiA+ID4gPiA+ ID4gdGhhdCBhIE5BVCBpcyBkZXRlY3RlZCBvbi1wYXRoLiBUaGlzIGNhbiBiZSBwcmVzZW50ZWQg YXMgYW4NCj4gPiA+ID4gPiA+ID4gaW5mb3JtYXRpb24gZWxlbWVudCByZXR1cm5lZCBieSB0aGUg c2VydmVyIHRvIHRoZSBjbGllbnQuIFRoaXMNCj4gPiA+ID4gPiA+ID4gaW5mb3JtYXRpb24gY2Fu IGJlLCBmb3IgZXhhbXBsZSwgdXNlZCBieSB0aGUgY2xpZW50IHRvIGFkanVzdA0KPiA+ID4gPiA+ ID4gPiBpdHMgSFQgaW50ZXJ2YWwsIGFkanVzdCB0aGUgaW50ZXJuYWwgSVAgYWRkcmVzc2VzL3By ZWZpeGVzIHRvDQo+IGJlDQo+ID4gcHJvdGVjdGVkLCBldGMuDQo+ID4gPiBPcGluaW9ucz8NCj4g PiA+ID4gPiA+ID4gSXQgc291bmRzIGFwcGVhbGluZywgYnV0IGl0J3MgdmVyeSBkaWZmaWN1bHQg dG8gZG8gdGhpcw0KPiA+ID4gPiA+ID4gPiByZWxpYWJseSwgYW5kIGl0J3Mgbm90IGp1c3QgTkFU cyB0aGF0IGFyZSBhbiBpc3N1ZSBoZXJlOw0KPiA+ID4gPiA+ID4gPiBGaXJld2FsbHMgcHJlc2Vu dCBzaW1pbGFyIGNoYWxsZW5nZXMgKGFuZCB0aGV5IG1heSBvciBtYXkgbm90DQo+ID4gPiA+ID4g PiA+IGJlIE5BVCdpbmcgaW5kaXZpZHVhbA0KPiA+ID4gPiBmbG93cykuDQo+ID4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gW01lZF0gSSBmdWxseSBhZ3JlZSB0aGF0IGZpcmV3 YWxscyBkZXRlY3QgaXMgbW9yZSBjb21wbGV4LiBMZXQncw0KPiA+ID4gPiA+ID4gcHV0IGl0DQo+ ID4gPiA+ID4gYXNpZGUNCj4gPiA+ID4gPiA+IGFuZCBmb2N1cyBvbiB0aGUgTkFUIGNhc2UuDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGUgcHJlc2VuY2UgYW5kIGJlaGF2aW9yIG9mIE5BVCBhbmQg RmlyZXdhbGwsIGFuZCBrZWVwYWxpdmUNCj4gPiA+ID4gPiBpbnRlcnZhbCBjYW4gYmUgZGV0ZXJt aW5lZCB1c2luZyBTVFVOIChkaXNjdXNzZWQgaW4NCj4gPiA+ID4gPiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNTc4MCkuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAtVGlydQ0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gV2UgY2FuIGNvbnNpZGVyIG1hbnkgYXBwcm9h Y2hlcyB0byBkZXRlY3QgYSBOQVQsIGUuZy4sDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gKDEp IFRoZSBET1RTIGNsaWVudCBpbnNlcnRzIGluIHRoZSBjb3JlIG1lc3NhZ2UgdGhlIElQDQo+ID4g PiA+ID4gPiBhZGRyZXNzL3BvcnQgaXQNCj4gPiA+ID4gPiB1c2VzIHRvDQo+ID4gPiA+ID4gPiBz ZW5kIHRoZSByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4gVXBvbiByZWNlaXB0IG9mIHRoZSBy ZXF1ZXN0DQo+ID4gPiA+ID4gPiBieSB0aGUgRE9UUyBzZXJ2ZXIsIGl0IGNoZWNrcyBpZiB0aGUg ZW5jbG9zZWQgSVAgYWRkcmVzcy9wb3J0DQo+ID4gPiA+ID4gPiBtYXRjaCB0aGUgc291cmNlDQo+ ID4gPiA+ID4gSVANCj4gPiA+ID4gPiA+IGFkZHJlc3MvcG9ydCBvZiB0aGUgcmVjZWl2ZWQgcGFj a2V0LiBJZiB5ZXMsIHRoZSBzZXJ2ZXIgc2V0cyBpbg0KPiA+ID4gPiA+ID4gdGhlDQo+ID4gPiA+ ID4gcmVzcG9uc2UgYQ0KPiA+ID4gPiA+ID4gZGVkaWNhdGVkIHBhcmFtZXRlciB0byBpbmRpY2F0 ZSB0aGF0IGEgdHJhbnNsYXRvciBpcyBkZXRlY3RlZA0KPiA+ID4gPiA+ID4gb24tDQo+ID4gPiBw YXRoLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICgyKSBUaGUgRE9UUyBzZXJ2ZXIgaW5zZXJ0 cyBzeXN0ZW1hdGljYWxseSB0aGUgc291cmNlIElQDQo+ID4gPiA+ID4gPiBhZGRyZXNzL3BvcnQg aW4NCj4gPiA+ID4gPiBhDQo+ID4gPiA+ID4gPiByZXNwb25zZSB0byBhIG1lc3NhZ2UgZnJvbSBh IERPVFMgY2xpZW50LiBVcG9uIHJlY2VpcHQgb2YgdGhhdA0KPiA+ID4gPiA+ID4gcmVzcG9uc2Us IHRoZSBET1RTIGNsaWVudCBjb21wYXJlcyB0aGUgZW5jbG9zZWQgYWRkcmVzcy9wb3J0DQo+ID4g PiA+ID4gPiB3aXRoIHRoZSBvbmVzIGl0IHVzZWQNCj4gPiA+ID4gPiB0bw0KPiA+ID4gPiA+ID4g c2VuZCB0aGUgcmVxdWVzdCB0byBkZXRlY3QgYW55IG1pc21hdGNoLg0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IC0tIEZsZW1taW5nDQo+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+ID4gPiA+IE1lZA0K PiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLSBEZcKgOiBEb3RzDQo+ID4gPiA+ID4gPiA+ID4+IFttYWlsdG86ZG90cy1ib3VuY2VzQGll dGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvbiBTaGFsbG93DQo+ID4gPiA+ID4gPiA+ID4+IEVudm95 w6nCoDogbHVuZGkgMjMgb2N0b2JyZSAyMDE3IDEzOjE4IMOAwqA6ICdGbGVtbWluZw0KPiA+ID4g PiA+ID4gPiA+PiBBbmRyZWFzZW4nOyBkb3RzQGlldGYub3JnIE9iamV0wqA6IFJlOiBbRG90c10g RE9UUw0KPiA+ID4gPiA+ID4gPiA+PiBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpDQo+ID4gPiA+ ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+IEhpIEZsZW1taW5nLA0KPiA+ID4gPiA+ID4gPiA+ Pg0KPiA+ID4gPiA+ID4gPiA+PiBUaGUgd2F5IG15IG1pbmQgd29ya3MgaXMgdG8gdGhpbmsgb2Yg YSBwcmFjdGljYWwgc2l0dWF0aW9uDQo+ID4gPiA+ID4gPiA+ID4+IGFuZCBzZWUgaWYgdGhpbmdz IGZpdC4NCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gQXMgSSByZWFkIFNJRy0w MTAsIHRoZXJlIGNvdWxkIGJlIGEgRE9UUyBjbGllbnQgd2l0aCBhDQo+ID4gPiA+ID4gPiA+ID4+ IG1hbmFnZW1lbnQgSVAgYWRkcmVzcyB0aGF0IGlzIFJGQzE5MTggLSB0aGlzIGNsaWVudCBjb3Vs ZA0KPiA+ID4gPiA+ID4gPiA+PiBiZSBtb25pdG9yaW5nIE5ldGZsb3cgaW5mb3JtYXRpb24gYW5k IGNhbiByZXF1ZXN0DQo+ID4gPiA+ID4gPiA+ID4+IG1pdGlnYXRpb24gZm9yIHRoZSBhcHByb3By aWF0ZSBwdWJsaWMgSVBzDQo+ID4gPiA+ID4gPiA+IHRoYXQNCj4gPiA+ID4gPiA+ID4gPj4gYXJl IGJlaW5nIG1vbml0b3JlZC4gIFNvIFNJRy0wMTAgaXMgbmVlZGVkIGZvciB0aGlzIHVzZQ0KPiBj YXNlLg0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+PiBJdCBpcyB0aGUgcmVzcG9u c2liaWxpdHkgb2YgdGhlIERPVFMgc2VydmVyIGFzIHRvIHdoZXRoZXINCj4gPiA+ID4gPiA+ID4g Pj4gaXQgYWNjZXB0cyBhIG1pdGlnYXRpb24gcmVxdWVzdCBmb3IgYSBwYXJ0aWN1bGFyIHRhcmdl dCBpcA0KPiA+ID4gPiA+ID4gPiA+PiAob3IgZG9tYWluDQo+ID4gPiA+ID4gZXRjLikgb3INCj4g PiA+ID4gPiA+IG5vdC4NCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gSWYgdGhl cmUgaXMgZ29pbmcgdG8gYmUgYSBOQVQgYm9yZGVyIHdoZXJlIHB1YmxpYyBJUHMgYXJlDQo+ID4g PiA+ID4gPiA+ID4+IG1hcHBlZCBpbnRvIHByaXZhdGUgSVBzIChhbmQgdmljZSB2ZXJzYSksIEkg d291bGQgdGhlbg0KPiA+ID4gPiA+ID4gPiA+PiBleHBlY3QgdGhlcmUgdG8gYmUgYSBET1RTIGdh dGV3YXkgYmV0d2VlbiB0aGVzZSAyIHpvbmVzLA0KPiA+ID4gPiA+ID4gPiA+PiBhbmQgaXQgaXMg dGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBET1RTIGdhdGV3YXkgdG8gZG8gYW55DQo+ID4gPiA+ ID4gPiA+ID4+IHRhcmdldC1pcA0KPiA+ID4gbWFwcGluZ3MuDQo+ID4gPiA+ID4gPiA+ID4+DQo+ ID4gPiA+ID4gPiA+ID4+IFJlZ2FyZHMNCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4g Pj4gSm9uDQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+ID4+IEZyb206IERvdHMgW21haWx0bzppZXRmLXN1 cGpwcy1kb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gPiA+ID4gPiA+ID4+IEJlaGFsZiBP ZiBGbGVtbWluZyBBbmRyZWFzZW4NCj4gPiA+ID4gPiA+ID4gPj4gU2VudDogMjIgT2N0b2JlciAy MDE3IDIwOjE3DQo+ID4gPiA+ID4gPiA+ID4+IFRvOiBkb3RzOyBkcmFmdC1pZXRmLWRvdHMtcmVx dWlyZW1lbnRzQGlldGYub3JnDQo+ID4gPiA+ID4gPiA+ID4+IFN1YmplY3Q6IFtEb3RzXSBET1RT IFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikNCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ ID4gPj4gR3JlZXRpbmdzDQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+IEkgaGF2 ZSByZXZpZXdlZCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIERPVFMgcmVxdWlyZW1lbnRzDQo+ ID4gPiA+ID4gPiA+ID4+IGRyYWZ0DQo+ID4gPiA+ID4gPiA+ID4+IChodHRwczovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLQ0KPiAwNi50eHQpLg0KPiA+ID4g PiA+ID4gPiA+PiBJbg0KPiA+ID4gPiA+ID4gPiBnZW5lcmFsLA0KPiA+ID4gPiA+ID4gPiA+PiBJ IHRoaW5rIHRoZSBkcmFmdCBpcyBpbiBnb29kIHNoYXBlIHdpdGggb25seSBhIGZldyBlZGl0cw0K PiA+ID4gPiA+ID4gPiA+PiByZXF1aXJlZCwgc28gSSBob3BlIHdlIGNhbiBtb3ZlIHRvIFdHTEMg c29vbi4gSSBoYXZlIGEgZmV3DQo+ID4gPiA+ID4gPiA+ID4+IGNvbW1lbnRzIGJlbG93IChvZiB3 aGljaA0KPiA+ID4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+ID4gPj4gTkFUIG9uZSBpcyB0aGUg b25seSByZWFsIHN1YnN0YW50aWFsIG9uZSkuIEkgaGF2ZSBhbHNvDQo+ID4gPiA+ID4gPiA+ID4+ IHN1Ym1pdHRlZCBhIHB1bGwgcmVxdWVzdCB3aXRoIGEgZmV3IG5pdCBmaXhlcyBvbiBHaXRIdWI6 DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+IFNl Y3Rpb24gMS4yDQo+ID4gPiA+ID4gPiA+ID4+IC0gVGhlIGRlZmluaXRpb24gb2YgIkRPVFMgU2ln bmFsIiBpcyBzbGlnaHRseSBpbmNvbnNpc3RlbnQNCj4gPiA+ID4gPiA+ID4gPj4gd2l0aCB0aGUg cmVzcGVjdGl2ZSAiQ2xpZW50IFNpZ25hbCIgYW5kICJTZXJ2ZXIgU2lnbmFsIg0KPiBkZWZpbml0 aW9ucy4NCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gU0lHLTAwNToNCj4gPiA+ ID4gPiA+ID4gPj4gLSBOb3QgY2xlYXIgdGhhdCBhbHdheXMgcmVxdWlyaW5nICJudW1iZXIgb2Yg cGFja2V0cyINCj4gPiA+ID4gPiA+ID4gPj4gbWV0cmljcyBpcyBtZWFuaW5nZnVsLiBDb25zaWRl ciBUQ1AtYmFzZWQgYXR0YWNrcyBmb3INCj4gPiA+ID4gPiA+ID4gPj4gZXhhbXBsZS4gTnVtYmVy IG9mIGJ5dGVzIG1heSBhbHdheXMgYmUgb2sgLSBhYm92ZSBhbmQNCj4gPiA+ID4gPiA+ID4gPj4g YmV5b25kIHRoYXQgaXQgc2hvdWxkIHByb2JhYmx5IGJlIGV4dGVuc2libGUgYW5kL29yIGF0dGFj aw0KPiA+IGRlcGVuZGVudC4NCj4gPiA+ID4gPiA+ID4gPj4gLSBJIGRvbid0IHRoaW5rIHRoZSBy ZXF1aXJlbWVudHMgZG9jdW1lbnQgc2hvdWxkIGdldCBpbnRvDQo+ID4gPiA+ID4gPiA+ID4+IHNw ZWNpZnlpbmcNCj4gPiA+ID4gPiA+ID4gdGltZXINCj4gPiA+ID4gPiA+ID4gPj4gdmFsdWVzIC0g ZXhwb250aWFsIGJhY2tvZmYgd2l0aCBzb21lIG1heGltdW0gdmFsdWUgc2VlbXMNCj4gPiA+ID4g PiA+ID4gPj4gYWJvdXQgdGhlDQo+ID4gPiA+ID4gPiA+IHJpZ2h0DQo+ID4gPiA+ID4gPiA+ID4+ IGxldmVsIG9mIGRldGFpbCBoZXJlLg0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ PiBTSUctMDA5Og0KPiA+ID4gPiA+ID4gPiA+PiAtIFRvIGJlIGNsZWFyLCB0aGUgY29uZmxpY3Rz IG9ubHkgYXBwbHkgd2l0aGluIGEgc2luZ2xlDQo+ID4gPiA+ID4gPiA+ID4+IGFkbWluaXN0cmF0 aXZlIGRvbWFpbiwgcmlnaHQgPyBGb3IgZXhhbXBsZSwgaWYgYSBjbGllbnQNCj4gPiA+ID4gPiA+ ID4gPj4gdGVsbHMgdGhlIHNhbWUgZG9tYWluIHRvIGFsdGVybmF0ZWx5IHR1cm4gb24vb2ZmIG1p dGlnYXRpb24NCj4gPiA+ID4gPiA+ID4gPj4gZm9yIGEgZ2l2ZW4gcHJlZml4LCByb3V0ZSBmbGFw cGluZw0KPiA+ID4gPiA+ID4gPiBtYXkNCj4gPiA+ID4gPiA+ID4gPj4gb2NjdXIuIFRoZSBzYW1l IGNvbmNlcm4gZG9lcyBub3QgYXBwbHkgaWYgYSBjbGllbnQgdGVsbHMNCj4gPiA+ID4gPiA+ID4g Pj4gdHdvIGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIHRvIHJlc3BlY3RpdmUgdHVy bg0KPiA+ID4gPiA+ID4gPiA+PiBtaXRpZ2F0aW9uIG9uIChkb21haW4gMSkgYW5kDQo+ID4gPiA+ ID4gPiA+IG9mZg0KPiA+ID4gPiA+ID4gPiA+PiAoZG9tYWluIDIpLiBJZiBzbywgY2FuIHdlIGNs YXJpZnkgdGhhdCAoYWxzbyBpbiBsaWV1IG9mDQo+ID4gPiA+ID4gPiA+ID4+IHNvbWUgb2YgdGhl DQo+ID4gPiA+ID4gPiA+IG11bHRpLQ0KPiA+ID4gPiA+ID4gPiA+PiBob21pbmcgY29tbWVudHMg cmFpc2VkIHByZXZpb3VzbHkpID8NCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4g U0lHLTAxMDoNCj4gPiA+ID4gPiA+ID4gPj4gLSBET1RTIENsaWVudCBiZWhpbmQgTkFULiBPbiBv bmUgaGFuZCwgaXQgc2VlbXMgcmVhc29uYWJsZQ0KPiA+ID4gPiA+ID4gPiA+PiB0byBoYXZlIHRo aXMgcmVxdWlyZW1lbnQgc2luY2UgY2xpZW50cyBmb3Igc3VyZSBjYW4gYmUNCj4gPiA+ID4gPiA+ ID4gPj4gYmVoaW5kIE5BVHMsIGFuZA0KPiA+ID4gPiA+IHdpdGgNCj4gPiA+ID4gPiA+IHRoaW5n cw0KPiA+ID4gPiA+ID4gPiA+PiBsaWtlIGR5bmFtaWMgRE5TLCB0aGV5IGNhbiAgICAgY2VydGFp bmx5IGJlIHJlYWNoYWJsZS4NCj4gSG93ZXZlciwNCj4gPiA+IGlmDQo+ID4gPiA+ID4gd2UNCj4g PiA+ID4gPiA+ID4gZG8NCj4gPiA+ID4gPiA+ID4gPj4gd2FudCB0byBhbGxvdyBmb3IgdGhpcyBz Y2VuYXJpbywgYW5kIGluIHBhcnRpY3VsYXIgZm9yIHRoZQ0KPiA+ID4gPiA+ID4gPiA+PiBET1RT IGNsaWVudA0KPiA+ID4gPiA+ID4gPiB0bw0KPiA+ID4gPiA+ID4gPiA+PiBoYXZlIGEgcHJpdmF0 ZSBJUC1hZGRyZXNzIChwb3RlbnRpYWxseSBiZWhpbmQgbXVsdGlwbGUNCj4gPiA+ID4gPiA+ID4g Pj4gTkFUcyksIHRoZW4gd2UNCj4gPiA+ID4gPiA+ID4gaGF2ZQ0KPiA+ID4gPiA+ID4gPiA+PiBt b3JlIHdvcmsgdG8gZG8gYmVjYXVzZSBpdCB3b24ndCBkbyB0aGUgRE9UUyBzZXJ2ZXIgYW55DQo+ ID4gPiA+ID4gPiA+ID4+IGdvb2QgdG8gZ2V0IGEgbWl0aWdhdGlvbiByZXF1ZXN0IHJlZmVycmlu ZyB0byB0aGF0IHByaXZhdGUNCj4gPiA+ID4gPiA+ID4gPj4gSVAtYWRkcmVzcyAob3INCj4gPiA+ ID4gPiBwcmVmaXgpLg0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4g PiA+ID4gPiA+PiBUaGFua3MNCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gLS0g RmxlbW1pbmcNCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ID4gPj4gRG90 cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+ID4gPj4gRG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+ ID4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4gPiA+ ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ID4gPj4gRG90cyBtYWlsaW5nIGxpc3QN Cj4gPiA+ID4gPiA+ID4gPj4gRG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiA+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4gPiA+ID4gPiA+ID4gPiAuDQo+ ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gRG90cyBtYWlsaW5n IGxpc3QNCj4gPiA+ID4gPiA+IERvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Thu Oct 26 05:12:00 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E1F13F563 for ; Thu, 26 Oct 2017 05:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEEUOfIrKLFt for ; Thu, 26 Oct 2017 05:11:57 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED37A13836B for ; Thu, 26 Oct 2017 05:11:56 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 6E543160B07; Thu, 26 Oct 2017 14:11:55 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 48411160068; Thu, 26 Oct 2017 14:11:55 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0361.001; Thu, 26 Oct 2017 14:11:54 +0200 From: To: Dave Dolson , "Konda, Tirumaleswar Reddy" , Flemming Andreasen , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAO8GKAACQhAQAAYkTigAABViKAAAB+EIAAAH6pgAAEb54AAAfog1AADcdhsA== Date: Thu, 26 Oct 2017 12:11:54 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 12:12:00 -0000 SGkgRGF2ZSwgDQoNClRoZSBwcm90b2NvbCBkb2VzIGFscmVhZHkgc3VwcG9ydCBhIG1lY2hhbmlz bSB0byBzZW5kIGtlZXBhbGl2ZSBtZXNzYWdlcyBldmVyeSAzMHMgKHJlY29tbWVuZGVkIHZhbHVl KS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBE ZcKgOiBEYXZlIERvbHNvbiBbbWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tXQ0KPiBFbnZvecOp wqA6IGpldWRpIDI2IG9jdG9icmUgMjAxNyAxMzoxNQ0KPiDDgMKgOiBLb25kYSwgVGlydW1hbGVz d2FyIFJlZGR5OyBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBGbGVtbWluZw0KPiBBbmRyZWFz ZW47IEpvbiBTaGFsbG93OyBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJFOiBbRG90c10gRE9U UyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQo+IA0KPiBJ IHRoaW5rIHRoZXJlIGlzIGFub3RoZXIgb3B0aW9uIHRvIGhhbmRsZSB0aGUgTkFUL2ZpcmV3YWxs IHByb2JsZW1zIGJ5DQo+IGNoYW5naW5nIHRoZSBwcm90b2NvbC4NCj4gDQo+IElmIEkgdW5kZXJz dGFuZCBjb3JyZWN0bHksIGN1cnJlbnRseSB0aGUgTkFUIGFuZCBmaXJld2FsbCBuZWVkIHRvIGJl IGtlcHQNCj4gb3BlbiB0byBwZXJtaXQgdW5zb2xpY2l0ZWQgc2VydmVyIHBhY2tldHMuDQo+IA0K PiBJZiB0aGUgcHJvdG9jb2wgaXMgY2hhbmdlZCB0byByZXF1aXJlIGNsaWVudCBwb2xsaW5nIG9m IHRoZSBzZXJ2ZXINCj4gdXBkYXRlcywgdGhlIE5BVCBhbmQgZmlyZXdhbGwgcHJvYmxlbXMgZ28g YXdheS4NCj4gDQo+IC1EYXZlDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEtvbmRhLCBUaXJ1bWFsZXN3YXINCj4gUmVkZHkNCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIg MjYsIDIwMTcgMTI6NTggUE0NCj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IEZs ZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7DQo+IGRvdHNAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtEb3RzXSBET1RTICYgTkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJldmll dyAoLTA2KSkNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tXQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDI6MjEg UE0NCj4gPiBUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlf S29uZGFATWNBZmVlLmNvbT47DQo+ID4gRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0BjaXNj by5jb20+OyBKb24gU2hhbGxvdyA8c3VwanBzLQ0KPiA+IGlldGZAanBzaGFsbG93LmNvbT47IGRv dHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTog RE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3DQo+ID4gKC0wNikpDQo+ID4NCj4gPiBSZS0sDQo+ID4N Cj4gPiBJIGhlYXIgeW91LiBNeSB0YWtlIGlzIHRoYXQgd2UgZG9uJ3QgbmVlZCB0byByZWNvbW1l bmQgd2hpY2ggY29tcGFuaW9uDQo+ID4gInByb3RvY29scy9tZWNoYW5pc21zIiBuZWVkIHRvIGJl IHN1cHBvcnRlZCBmb3IgTkFUL0ZXIHRyYXZlcnNhbA0KPiA+IHB1cnBvc2VzLiBIYXZpbmcgYSBk aXNjdXNzaW9uIGF0IHRoZSBzYW1lIGxldmVsIGluIDgwODUgd291bGQgYmUNCj4gPiBzdWZmaWNp ZW50LCBJTUhPLg0KPiA+DQo+ID4gTGV0J3MgZm9jdXMgb24gdGhlIHNpbXBsZSBidWlsdC1pbiBm ZWF0dXJlIGZvciBOQVQgZGV0ZWN0Lg0KPiANCj4gSSBkb27igJl0IHRoaW5rIHRoZSBzaW1wbGUg YnVpbHQtaW4gZmVhdHVyZSBpcyBzdWZmaWNpZW50LCBET1RTIGNsaWVudCB3aWxsDQo+IGhhdmUg dG8gcmVseSBvbiBtZWNoYW5pc21zIGRpc2N1c3NlZCBpbiA4MDg1IGZvciBib3RoIGZpcmV3YWxs IGFuZCBOQVQNCj4gdHJhdmVyc2FsLg0KPiANCj4gLVRpcnUNCj4gDQo+ID4NCj4gPiBDaGVlcnMs DQo+ID4gTWVkDQo+ID4NCj4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4g RGXCoDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+ID4gW21haWx0bzpUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KPiA+ID4gRW52b3nDqcKgOiBqZXVkaSAyNiBvY3Rv YnJlIDIwMTcgMTA6MzYgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsNCj4gPiA+IEZs ZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDogUkU6 IFtEb3RzXQ0KPiA+ID4gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZp ZXcgKC0wNikpDQo+ID4gPg0KPiA+ID4gQnV0IE5BVHMgYXJlIG5vdCB0aGUgb25seSBwcm9ibGVt LCBmaXJld2FsbHMgd2lsbCBhbHNvIGJlIG1vc3QNCj4gPiA+IGxpa2VseSBwcmVzZW50LCBhbmQg U1RVTiBoZWxwcyBkaXNjb3ZlciBib3RoIE5BVHMgYW5kIGZpcmV3YWxscyBhbmQNCj4gPiA+IHVz ZWZ1bCBldmVuIGluIElQdjYgbmV0d29ya3MgdG8gZGV0ZXJtaW5lIHRoZSBrZWVwYWxpdmUgaW50 ZXJ2YWwgb2YNCj4gZmlyZXdhbGwuDQo+ID4gPg0KPiA+ID4gLVRpcnUNCj4gPiA+DQo+ID4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20NCj4gPiA+ID4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tXQ0KPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNiwgMjAxNyAxOjUyIFBNDQo+ ID4gPiA+IFRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+ID4gPFRpcnVtYWxlc3dhclJl ZGR5X0tvbmRhQE1jQWZlZS5jb20+Ow0KPiA+ID4gPiBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRy ZWFzQGNpc2NvLmNvbT47IEpvbiBTaGFsbG93IDxzdXBqcHMtDQo+ID4gPiA+IGlldGZAanBzaGFs bG93LmNvbT47IGRvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDogUkU6IFtEb3RzXSBET1RT ICYgTkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJldmlldw0KPiA+ID4gPiAoLTA2KSkN Cj4gPiA+ID4NCj4gPiA+ID4gVGlydSwNCj4gPiA+ID4NCj4gPiA+ID4gWWVzLCBTVFVOIGNhbiBi ZSBsaXN0ZWQgYXMgcGFydCBvZiB0aGUgZXhpc3RpbmcgdG9vbHMgYm94IChhbW9uZw0KPiA+ID4g PiB0aGUNCj4gPiA+IGxpbmVzIG9mDQo+ID4gPiA+IHdoYXQgaXMgYWxyZWFkeSBkaXNjdXNzZWQg aW4gODA4NSkuDQo+ID4gPiA+DQo+ID4gPiA+IEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBtYWtlcyBz ZW5zZSB0byByZXF1aXJlIFNUVU4gc3VwcG9ydCBieSBET1RTDQo+ID4gPiBjbGllbnRzLg0KPiA+ ID4gPg0KPiA+ID4gPiBUaGUgcHJvcG9zYWwgaXMgdG8gaW5jbHVkZSBhIHNpbXBsZSBidWlsdC1p biBmZWF0dXJlIGluIHRoZSBET1RTDQo+ID4gPiBwcm90b2NvbCBpdHNlbGYNCj4gPiA+ID4gdGhh dCBjYW4gaGVscCB0byBkZXRlY3QgTkFUcy4gVGhlIHN1cHBvcnQgb2Ygc3VjaCBmZWF0dXJlIHdp bGwsDQo+ID4gPiA+IGUuZy4sDQo+ID4gPiBlYXNlDQo+ID4gPiA+IHRyb3VibGVzaG9vdGluZyB3 aGVuIGNvbm5lY3Rpdml0eSBwcm9ibGVtcyBhcmUgZXhwZXJpZW5jZWQgb24gdGhlDQo+ID4gPiA+ IHBhdGggYmV0d2VlbiBhIGNsaWVudCBhbmQgYSBzZXJ2ZXIuDQo+ID4gPiA+DQo+ID4gPiA+IENo ZWVycywNCj4gPiA+ID4gTWVkDQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+ID4gPiA+ID4gRGXCoDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+ ID4gPiA+IFttYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0NCj4gPiA+ ID4gPiBFbnZvecOpwqA6IGpldWRpIDI2IG9jdG9icmUgMjAxNyAwOTo0NCDDgMKgOiBCT1VDQURB SVIgTW9oYW1lZA0KPiA+ID4gPiA+IElNVC9PTE47IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNo YWxsb3c7IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDoNCj4gPiA+ID4gPiBSRTogW0RvdHNdIERPVFMg JiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKQ0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gRnJv bTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4g PiA+ID4gPiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4gPiA+ID4gPiBTZW50OiBU dWVzZGF5LCBPY3RvYmVyIDI0LCAyMDE3IDI6MjAgUE0NCj4gPiA+ID4gPiA+IFRvOiBGbGVtbWlu ZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2NvLmNvbT47IEpvbiBTaGFsbG93DQo+ID4gPiA+ID4g PiA8c3VwanBzLSBpZXRmQGpwc2hhbGxvdy5jb20+OyBkb3RzQGlldGYub3JnDQo+ID4gPiA+ID4g PiBTdWJqZWN0OiBSZTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVu dHMNCj4gPiA+ID4gPiA+IHJldmlldw0KPiA+ID4gPiA+ID4gKC0wNikpDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gSGkgRmxlbW1pbmcsIGFsbCwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBQ bGVhc2Ugc2VlIGlubGluZS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBDaGVlcnMsDQo+ID4g PiA+ID4gPiBNZWQNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPiA+ID4gPiA+ID4gPiBEZcKgOiBGbGVtbWluZyBBbmRyZWFzZW4gW21haWx0 bzpmYW5kcmVhc0BjaXNjby5jb21dIEVudm95w6nCoDoNCj4gPiA+ID4gPiA+ID4gbHVuZGkNCj4g PiA+ID4gPiA+ID4gMjMgb2N0b2JyZSAyMDE3IDE3OjM2IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVk IElNVC9PTE47IEpvbg0KPiA+ID4gPiA+ID4gPiBTaGFsbG93OyBkb3RzQGlldGYub3JnIE9iamV0 wqA6IFJlOiBET1RTICYgTkFUICh3YXMgUkU6DQo+ID4gPiA+ID4gPiA+IFtEb3RzXSBET1RTIFJl cXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IE9uIDEwLzIzLzE3IDg6MjggQU0sIG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gPiA+ID4gPiA+ID4gSGkgSm9uLCBhbGws DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBJIGFncmVlIHdpdGggRmxlbW1pbmcg dGhhdCAic29tZSBtb3JlIHdvcmsiIGlzIG5lZWRlZC4NCj4gPiA+ID4gPiA+ID4gPiBJTUhPLCB0 aGlzIGlzIGENCj4gPiA+ID4gPiA+ID4gdHlwaWNhbCBkaXNjdXNzaW9uIHRvIGluY2x1ZGUgaW4g YSBkZWRpY2F0ZWQgc2VjdGlvbiBpbiB0aGUNCj4gPiA+ID4gPiA+ID4gRE9UUyBhcmNoaXRlY3R1 cmUgSS1ELg0KPiA+ID4gPiA+ID4gPiBBZ3JlZWQuDQo+ID4gPiA+ID4gPiA+ID4gPkZyb20gYSBy ZXF1aXJlbWVudCBzdGFuZHBvaW50LCB3ZSBkb24ndCBuZWVkIHRvIGVsYWJvcmF0ZQ0KPiA+ID4g PiA+ID4gPiA+ID5ob3cgdGhlDQo+ID4gPiA+ID4gPiA+IHByb3RvY29scyB3aWxsIGZ1bGZpbCBp dC4gU0lHLTEwIGRvZXMgZXZlbiBhIG5pY2Ugam9iIGJ5DQo+ID4gPiA+ID4gPiA+IGNpdGluZw0K PiA+ID4gPiA+ID4gPiBSRkM4MDg1IHdoaWNoIHBvaW50cyB0byBOQVQgdHJhdmVyc2FsIG1lY2hh bmlzbXMuIE9uZSBjb3VsZA0KPiA+ID4gPiA+ID4gPiBwaWNrIGhpcy9oZXIgZmF2b3JpdGUgcHJv dG9jb2wgZnJvbSB0aGUgbGlzdCBpbiA4MDg1IHRvDQo+ID4gPiA+ID4gPiA+IGRpc2NvdmVyIHRo ZSBleHRlcm5hbCBJUCBhZGRyZXNzL3ByZWZpeCwgaWYgbmVlZGVkLiBFeHRlcm5hbA0KPiA+ID4g PiA+ID4gPiBJUCBhZGRyZXNzZXMvcHJlZml4ZXMgY2FuIGJlIElQdjQgZm9yIGEgTkFUNDQgb3Ig TkFUNjQsIGJ1dA0KPiA+ID4gPiA+ID4gPiBjYW4gYmUNCj4gPiA+ID4gPiA+ID4gSVB2NiBwcmVm aXhlcyBmb3IgZW50ZXJwcmlzZXMgZGVwbG95aW5nIE5QVHY2LCBhbmQgc28gb24uDQo+ID4gPiA+ ID4gPiA+IFBhcnQgb2YgdGhlIGNoYWxsZW5nZSBoZXJlIGlzIHRoYXQgdGhlIGF0dGFjayB0YXJn ZXQgYW5kIHRoZQ0KPiA+ID4gPiA+ID4gPiBET1RTIGNsaWVudCBhcmUgbm90IG5lY2Vzc2FyaWx5 IG9uZSBhbmQgdGhlIHNhbWUsIHdoaWNoDQo+ID4gPiA+ID4gPiA+IG1ha2VzIGl0IG1vcmUgZGlm ZmljdWx0IHRvIGRldGVybWluZSB0aGUgcHVibGljLWZhY2luZw0KPiA+ID4gPiA+ID4gPiBJUC1h ZGRyZXNzL3BvcnQgdW5kZXIgYXR0YWNrIChhdCBsZWFzdCBpZiB0aGUgRE9UUyBjbGllbnQgaXMN Cj4gPiA+ID4gPiA+ID4gZ29pbmcgdG8NCj4gPiBkbyBpdCkuDQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gW01lZF0gVGhpcyBpcyBleGFjdGx5IHRoZSBraW5kIG9mIHRoZSBkaXNjdXNzaW9uIHRv IGhhdmUuDQo+IFRoYW5rcy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBXaXRoIG9yIHdpdGhv dXQgTkFULCBET1RTIGNsaWVudHMgYXJlIGFzc3VtZWQgdG8gYmUgZmVkIHdpdGgNCj4gPiA+ID4g PiA+IHRoZQ0KPiA+ID4gPiA+IGludGVybmFsDQo+ID4gPiA+ID4gPiB0YXJnZXQocykuIFRoaXMg Y2FuIGJlIGFjaGlldmVkIGJ5IHByb3Zpc2lvbmluZyAobGlrZWx5KSBvciBieQ0KPiA+ID4gPiA+ ID4gZGlzY292ZXJ5DQo+ID4gPiA+ID4gbWVhbnMNCj4gPiA+ID4gPiA+IChlLmcuLCByZXNpZGVu dGlhbCBvciBzbWFsbCBlbnRlcnByaXNlIG5ldHdvcmtzKS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiBDYW4gd2UgYXNzdW1lIHRoYXQgdGhlIGRpc2NvdmVyeSBvZiB0aGUgZXh0ZXJuYWwgSVAN Cj4gPiA+ID4gPiA+IGFkZHJlc3MvcHJlZml4Ly4uIGlzDQo+ID4gPiA+ID4gZG9uZQ0KPiA+ID4g PiA+ID4gYnkgYSBET1RTIGNsaWVudCBvbmx5IGlmIGl0IGlzIGV4cGxpY2l0bHkgaW5zdHJ1Y3Rl ZCB0byBkbyBzbz8NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IElu IHNvbWUgZGVwbG95bWVudHMsIERPVFMgY2xpZW50cyBtYXkgYmUgcHJvdmlzaW9uZWQgd2l0aA0K PiA+ID4gPiA+ID4gPiA+IHRoZSBzZXQgb2YNCj4gPiA+ID4gPiA+ID4gaW50ZXJuYWwgcmVzb3Vy Y2VzLCBzbyB0aGVyZSBpcyBubyBuZWVkIGZvciBkaXNjb3ZlcnkuDQo+ID4gPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gPiBBbHNvLCBhcyBKb24gbWVudGlvbmVkLCBET1RTIGdhdGV3YXlzIGNh biBiZSBvZiBoZWxwIHRvDQo+ID4gPiA+ID4gPiA+ID4gc2V0IHRoZQ0KPiA+ID4gPiA+ID4gPiBh cHByb3ByaWF0ZSBJUCBhZGRyZXNzZXMvcHJlZml4ZXMvcG9ydCBudW1iZXJzIGluIHRoZQ0KPiA+ ID4gPiA+ID4gPiBwcmVzZW5jZSBvZiB0cmFuc2xhdG9ycy4NCj4gPiA+ID4gPiA+ID4gQWdyZWVk IC0gYnV0IHRoZXkgc3RpbGwgbmVlZCBhIHdheSB0byBmaWd1cmUgb3V0IHRoZQ0KPiA+ID4gPiA+ ID4gPiBwcml2YXRlL3B1YmxpYyBtYXBwaW5nIGZvciBhIGdpdmVuIGF0dGFjayB0YXJnZXQuDQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gW01lZF0gQmVjYXVzZSBhIEREb1MgYXR0YWNrIGlzIG9i c2VydmVkIGZyb20gdGhlIGludGVybmFsDQo+ID4gPiA+ID4gPiBuZXR3b3JrLA0KPiA+ID4gPiA+ ID4gbWFwcGluZyhzKSBhcmUgbmVjZXNzYXJpbHkgbWFpbnRhaW5lZCBieSB0aGUgb24tcGF0aA0K PiB0cmFuc2xhdG9yKHMpLg0KPiA+ID4gPiA+ID4gT3RoZXJ3aXNlLCB0aGUgaW5jb21pbmcgYXR0 YWNrIHRyYWZmaWMgY291bGRuJ3QgYmUgZm9yd2FyZGVkDQo+ID4gPiA+ID4gPiB0byBpbnRlcm5h bA0KPiA+ID4gPiA+IGhvc3RzLg0KPiA+ID4gPiA+ID4gVGhpcyBtb2RlbCBhc3N1bWVzIHRoYXQg dGhlIGdhdGV3YXkgaXMgY29sbG9jYXRlZCB3aXRoIHRoZSBOQVQuDQo+ID4gPiA+ID4gPiBTbywg dGhlIGdhdGV3YXkgY2FuIHJlcGxhY2UgdGhlIGludGVybmFsIElQIGFkZHJlc3MvcHJlZml4DQo+ ID4gPiA+ID4gPiB3aXRoIHRoZSBvbmUNCj4gPiA+ID4gPiByZXRyaWV2ZXMNCj4gPiA+ID4gPiA+ IGZyb20gdGhlIE5BVCBtYXBwaW5nIHRhYmxlLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IERv IHlvdSBzZWUgYW55IGlzc3VlIHdpdGggdGhpcyBzY2hlbWU/DQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPiA+IEFuIG9wZW4gcXVlc3Rpb24gdGhvdWdoIHdvdWxkIGJlIHRvIGRpc2N1c3MgaWYg dGhlcmUgaXMgYQ0KPiA+ID4gPiA+ID4gPiA+IHZhbHVlIGluDQo+ID4gPiA+ID4gPiA+IGhhdmlu ZyBhIGZlYXR1cmUgaW4gdGhlIERPVFMgcHJvdG9jb2wgdG8gaW5mb3JtIGEgRE9UUw0KPiA+ID4g PiA+ID4gPiBjbGllbnQgdGhhdCBhIE5BVCBpcyBkZXRlY3RlZCBvbi1wYXRoLiBUaGlzIGNhbiBi ZSBwcmVzZW50ZWQNCj4gPiA+ID4gPiA+ID4gYXMgYW4gaW5mb3JtYXRpb24gZWxlbWVudCByZXR1 cm5lZCBieSB0aGUgc2VydmVyIHRvIHRoZQ0KPiA+ID4gPiA+ID4gPiBjbGllbnQuIFRoaXMgaW5m b3JtYXRpb24gY2FuIGJlLCBmb3IgZXhhbXBsZSwgdXNlZCBieSB0aGUNCj4gPiA+ID4gPiA+ID4g Y2xpZW50IHRvIGFkanVzdCBpdHMgSFQgaW50ZXJ2YWwsIGFkanVzdCB0aGUgaW50ZXJuYWwgSVAN Cj4gPiA+ID4gPiA+ID4gYWRkcmVzc2VzL3ByZWZpeGVzIHRvIGJlDQo+ID4gcHJvdGVjdGVkLCBl dGMuDQo+ID4gPiBPcGluaW9ucz8NCj4gPiA+ID4gPiA+ID4gSXQgc291bmRzIGFwcGVhbGluZywg YnV0IGl0J3MgdmVyeSBkaWZmaWN1bHQgdG8gZG8gdGhpcw0KPiA+ID4gPiA+ID4gPiByZWxpYWJs eSwgYW5kIGl0J3Mgbm90IGp1c3QgTkFUcyB0aGF0IGFyZSBhbiBpc3N1ZSBoZXJlOw0KPiA+ID4g PiA+ID4gPiBGaXJld2FsbHMgcHJlc2VudCBzaW1pbGFyIGNoYWxsZW5nZXMgKGFuZCB0aGV5IG1h eSBvciBtYXkNCj4gPiA+ID4gPiA+ID4gbm90IGJlIE5BVCdpbmcgaW5kaXZpZHVhbA0KPiA+ID4g PiBmbG93cykuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gW01lZF0g SSBmdWxseSBhZ3JlZSB0aGF0IGZpcmV3YWxscyBkZXRlY3QgaXMgbW9yZSBjb21wbGV4Lg0KPiA+ ID4gPiA+ID4gTGV0J3MgcHV0IGl0DQo+ID4gPiA+ID4gYXNpZGUNCj4gPiA+ID4gPiA+IGFuZCBm b2N1cyBvbiB0aGUgTkFUIGNhc2UuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGUgcHJlc2VuY2Ug YW5kIGJlaGF2aW9yIG9mIE5BVCBhbmQgRmlyZXdhbGwsIGFuZCBrZWVwYWxpdmUNCj4gPiA+ID4g PiBpbnRlcnZhbCBjYW4gYmUgZGV0ZXJtaW5lZCB1c2luZyBTVFVOIChkaXNjdXNzZWQgaW4NCj4g PiA+ID4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc4MCkuDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiAtVGlydQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gV2Ug Y2FuIGNvbnNpZGVyIG1hbnkgYXBwcm9hY2hlcyB0byBkZXRlY3QgYSBOQVQsIGUuZy4sDQo+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gKDEpIFRoZSBET1RTIGNsaWVudCBpbnNlcnRzIGluIHRoZSBj b3JlIG1lc3NhZ2UgdGhlIElQDQo+ID4gPiA+ID4gPiBhZGRyZXNzL3BvcnQgaXQNCj4gPiA+ID4g PiB1c2VzIHRvDQo+ID4gPiA+ID4gPiBzZW5kIHRoZSByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZl ci4gVXBvbiByZWNlaXB0IG9mIHRoZQ0KPiA+ID4gPiA+ID4gcmVxdWVzdCBieSB0aGUgRE9UUyBz ZXJ2ZXIsIGl0IGNoZWNrcyBpZiB0aGUgZW5jbG9zZWQgSVANCj4gPiA+ID4gPiA+IGFkZHJlc3Mv cG9ydCBtYXRjaCB0aGUgc291cmNlDQo+ID4gPiA+ID4gSVANCj4gPiA+ID4gPiA+IGFkZHJlc3Mv cG9ydCBvZiB0aGUgcmVjZWl2ZWQgcGFja2V0LiBJZiB5ZXMsIHRoZSBzZXJ2ZXIgc2V0cw0KPiA+ ID4gPiA+ID4gaW4gdGhlDQo+ID4gPiA+ID4gcmVzcG9uc2UgYQ0KPiA+ID4gPiA+ID4gZGVkaWNh dGVkIHBhcmFtZXRlciB0byBpbmRpY2F0ZSB0aGF0IGEgdHJhbnNsYXRvciBpcyBkZXRlY3RlZA0K PiA+ID4gPiA+ID4gb24tDQo+ID4gPiBwYXRoLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICgy KSBUaGUgRE9UUyBzZXJ2ZXIgaW5zZXJ0cyBzeXN0ZW1hdGljYWxseSB0aGUgc291cmNlIElQDQo+ ID4gPiA+ID4gPiBhZGRyZXNzL3BvcnQgaW4NCj4gPiA+ID4gPiBhDQo+ID4gPiA+ID4gPiByZXNw b25zZSB0byBhIG1lc3NhZ2UgZnJvbSBhIERPVFMgY2xpZW50LiBVcG9uIHJlY2VpcHQgb2YgdGhh dA0KPiA+ID4gPiA+ID4gcmVzcG9uc2UsIHRoZSBET1RTIGNsaWVudCBjb21wYXJlcyB0aGUgZW5j bG9zZWQgYWRkcmVzcy9wb3J0DQo+ID4gPiA+ID4gPiB3aXRoIHRoZSBvbmVzIGl0IHVzZWQNCj4g PiA+ID4gPiB0bw0KPiA+ID4gPiA+ID4gc2VuZCB0aGUgcmVxdWVzdCB0byBkZXRlY3QgYW55IG1p c21hdGNoLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IC0tIEZsZW1t aW5nDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gQ2hlZXJz LA0KPiA+ID4gPiA+ID4gPiA+IE1lZA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLSBEZcKgOiBEb3RzDQo+ID4gPiA+ID4gPiA+ID4+ IFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvbiBTaGFsbG93 DQo+ID4gPiA+ID4gPiA+ID4+IEVudm95w6nCoDogbHVuZGkgMjMgb2N0b2JyZSAyMDE3IDEzOjE4 IMOAwqA6ICdGbGVtbWluZw0KPiA+ID4gPiA+ID4gPiA+PiBBbmRyZWFzZW4nOyBkb3RzQGlldGYu b3JnIE9iamV0wqA6IFJlOiBbRG90c10gRE9UUw0KPiA+ID4gPiA+ID4gPiA+PiBSZXF1aXJlbWVu dHMgcmV2aWV3ICgtMDYpDQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+IEhpIEZs ZW1taW5nLA0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+PiBUaGUgd2F5IG15IG1p bmQgd29ya3MgaXMgdG8gdGhpbmsgb2YgYSBwcmFjdGljYWwNCj4gPiA+ID4gPiA+ID4gPj4gc2l0 dWF0aW9uIGFuZCBzZWUgaWYgdGhpbmdzIGZpdC4NCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4g PiA+ID4gPj4gQXMgSSByZWFkIFNJRy0wMTAsIHRoZXJlIGNvdWxkIGJlIGEgRE9UUyBjbGllbnQg d2l0aCBhDQo+ID4gPiA+ID4gPiA+ID4+IG1hbmFnZW1lbnQgSVAgYWRkcmVzcyB0aGF0IGlzIFJG QzE5MTggLSB0aGlzIGNsaWVudCBjb3VsZA0KPiA+ID4gPiA+ID4gPiA+PiBiZSBtb25pdG9yaW5n IE5ldGZsb3cgaW5mb3JtYXRpb24gYW5kIGNhbiByZXF1ZXN0DQo+ID4gPiA+ID4gPiA+ID4+IG1p dGlnYXRpb24gZm9yIHRoZSBhcHByb3ByaWF0ZSBwdWJsaWMgSVBzDQo+ID4gPiA+ID4gPiA+IHRo YXQNCj4gPiA+ID4gPiA+ID4gPj4gYXJlIGJlaW5nIG1vbml0b3JlZC4gIFNvIFNJRy0wMTAgaXMg bmVlZGVkIGZvciB0aGlzIHVzZQ0KPiBjYXNlLg0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ ID4gPiA+PiBJdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIERPVFMgc2VydmVyIGFzIHRv IHdoZXRoZXINCj4gPiA+ID4gPiA+ID4gPj4gaXQgYWNjZXB0cyBhIG1pdGlnYXRpb24gcmVxdWVz dCBmb3IgYSBwYXJ0aWN1bGFyIHRhcmdldA0KPiA+ID4gPiA+ID4gPiA+PiBpcCAob3IgZG9tYWlu DQo+ID4gPiA+ID4gZXRjLikgb3INCj4gPiA+ID4gPiA+IG5vdC4NCj4gPiA+ID4gPiA+ID4gPj4N Cj4gPiA+ID4gPiA+ID4gPj4gSWYgdGhlcmUgaXMgZ29pbmcgdG8gYmUgYSBOQVQgYm9yZGVyIHdo ZXJlIHB1YmxpYyBJUHMgYXJlDQo+ID4gPiA+ID4gPiA+ID4+IG1hcHBlZCBpbnRvIHByaXZhdGUg SVBzIChhbmQgdmljZSB2ZXJzYSksIEkgd291bGQgdGhlbg0KPiA+ID4gPiA+ID4gPiA+PiBleHBl Y3QgdGhlcmUgdG8gYmUgYSBET1RTIGdhdGV3YXkgYmV0d2VlbiB0aGVzZSAyIHpvbmVzLA0KPiA+ ID4gPiA+ID4gPiA+PiBhbmQgaXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBET1RTIGdh dGV3YXkgdG8gZG8NCj4gPiA+ID4gPiA+ID4gPj4gYW55IHRhcmdldC1pcA0KPiA+ID4gbWFwcGlu Z3MuDQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+IFJlZ2FyZHMNCj4gPiA+ID4g PiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gSm9uDQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ ID4gPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+ID4+IEZy b206IERvdHMgW21haWx0bzppZXRmLXN1cGpwcy1kb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ ID4gPiA+ID4gPiA+ID4+IEJlaGFsZiBPZiBGbGVtbWluZyBBbmRyZWFzZW4NCj4gPiA+ID4gPiA+ ID4gPj4gU2VudDogMjIgT2N0b2JlciAyMDE3IDIwOjE3DQo+ID4gPiA+ID4gPiA+ID4+IFRvOiBk b3RzOyBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnDQo+ID4gPiA+ID4gPiA+ ID4+IFN1YmplY3Q6IFtEb3RzXSBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikNCj4gPiA+ ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gR3JlZXRpbmdzDQo+ID4gPiA+ID4gPiA+ID4+ DQo+ID4gPiA+ID4gPiA+ID4+IEkgaGF2ZSByZXZpZXdlZCB0aGUgbGF0ZXN0IHZlcnNpb24gb2Yg dGhlIERPVFMNCj4gPiA+ID4gPiA+ID4gPj4gcmVxdWlyZW1lbnRzIGRyYWZ0DQo+ID4gPiA+ID4g PiA+ID4+IChodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1l bnRzLQ0KPiAwNi50eHQpLg0KPiA+ID4gPiA+ID4gPiA+PiBJbg0KPiA+ID4gPiA+ID4gPiBnZW5l cmFsLA0KPiA+ID4gPiA+ID4gPiA+PiBJIHRoaW5rIHRoZSBkcmFmdCBpcyBpbiBnb29kIHNoYXBl IHdpdGggb25seSBhIGZldyBlZGl0cw0KPiA+ID4gPiA+ID4gPiA+PiByZXF1aXJlZCwgc28gSSBo b3BlIHdlIGNhbiBtb3ZlIHRvIFdHTEMgc29vbi4gSSBoYXZlIGENCj4gPiA+ID4gPiA+ID4gPj4g ZmV3IGNvbW1lbnRzIGJlbG93IChvZiB3aGljaA0KPiA+ID4gPiA+ID4gPiB0aGUNCj4gPiA+ID4g PiA+ID4gPj4gTkFUIG9uZSBpcyB0aGUgb25seSByZWFsIHN1YnN0YW50aWFsIG9uZSkuIEkgaGF2 ZSBhbHNvDQo+ID4gPiA+ID4gPiA+ID4+IHN1Ym1pdHRlZCBhIHB1bGwgcmVxdWVzdCB3aXRoIGEg ZmV3IG5pdCBmaXhlcyBvbiBHaXRIdWI6DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ ID4+DQo+ID4gPiA+ID4gPiA+ID4+IFNlY3Rpb24gMS4yDQo+ID4gPiA+ID4gPiA+ID4+IC0gVGhl IGRlZmluaXRpb24gb2YgIkRPVFMgU2lnbmFsIiBpcyBzbGlnaHRseQ0KPiA+ID4gPiA+ID4gPiA+ PiBpbmNvbnNpc3RlbnQgd2l0aCB0aGUgcmVzcGVjdGl2ZSAiQ2xpZW50IFNpZ25hbCIgYW5kDQo+ ICJTZXJ2ZXIgU2lnbmFsIiBkZWZpbml0aW9ucy4NCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4g PiA+ID4gPj4gU0lHLTAwNToNCj4gPiA+ID4gPiA+ID4gPj4gLSBOb3QgY2xlYXIgdGhhdCBhbHdh eXMgcmVxdWlyaW5nICJudW1iZXIgb2YgcGFja2V0cyINCj4gPiA+ID4gPiA+ID4gPj4gbWV0cmlj cyBpcyBtZWFuaW5nZnVsLiBDb25zaWRlciBUQ1AtYmFzZWQgYXR0YWNrcyBmb3INCj4gPiA+ID4g PiA+ID4gPj4gZXhhbXBsZS4gTnVtYmVyIG9mIGJ5dGVzIG1heSBhbHdheXMgYmUgb2sgLSBhYm92 ZSBhbmQNCj4gPiA+ID4gPiA+ID4gPj4gYmV5b25kIHRoYXQgaXQgc2hvdWxkIHByb2JhYmx5IGJl IGV4dGVuc2libGUgYW5kL29yDQo+ID4gPiA+ID4gPiA+ID4+IGF0dGFjaw0KPiA+IGRlcGVuZGVu dC4NCj4gPiA+ID4gPiA+ID4gPj4gLSBJIGRvbid0IHRoaW5rIHRoZSByZXF1aXJlbWVudHMgZG9j dW1lbnQgc2hvdWxkIGdldCBpbnRvDQo+ID4gPiA+ID4gPiA+ID4+IHNwZWNpZnlpbmcNCj4gPiA+ ID4gPiA+ID4gdGltZXINCj4gPiA+ID4gPiA+ID4gPj4gdmFsdWVzIC0gZXhwb250aWFsIGJhY2tv ZmYgd2l0aCBzb21lIG1heGltdW0gdmFsdWUgc2VlbXMNCj4gPiA+ID4gPiA+ID4gPj4gYWJvdXQg dGhlDQo+ID4gPiA+ID4gPiA+IHJpZ2h0DQo+ID4gPiA+ID4gPiA+ID4+IGxldmVsIG9mIGRldGFp bCBoZXJlLg0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+PiBTSUctMDA5Og0KPiA+ ID4gPiA+ID4gPiA+PiAtIFRvIGJlIGNsZWFyLCB0aGUgY29uZmxpY3RzIG9ubHkgYXBwbHkgd2l0 aGluIGEgc2luZ2xlDQo+ID4gPiA+ID4gPiA+ID4+IGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgcmln aHQgPyBGb3IgZXhhbXBsZSwgaWYgYSBjbGllbnQNCj4gPiA+ID4gPiA+ID4gPj4gdGVsbHMgdGhl IHNhbWUgZG9tYWluIHRvIGFsdGVybmF0ZWx5IHR1cm4gb24vb2ZmDQo+ID4gPiA+ID4gPiA+ID4+ IG1pdGlnYXRpb24gZm9yIGEgZ2l2ZW4gcHJlZml4LCByb3V0ZSBmbGFwcGluZw0KPiA+ID4gPiA+ ID4gPiBtYXkNCj4gPiA+ID4gPiA+ID4gPj4gb2NjdXIuIFRoZSBzYW1lIGNvbmNlcm4gZG9lcyBu b3QgYXBwbHkgaWYgYSBjbGllbnQgdGVsbHMNCj4gPiA+ID4gPiA+ID4gPj4gdHdvIGRpZmZlcmVu dCBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIHRvIHJlc3BlY3RpdmUgdHVybg0KPiA+ID4gPiA+ID4g PiA+PiBtaXRpZ2F0aW9uIG9uIChkb21haW4gMSkgYW5kDQo+ID4gPiA+ID4gPiA+IG9mZg0KPiA+ ID4gPiA+ID4gPiA+PiAoZG9tYWluIDIpLiBJZiBzbywgY2FuIHdlIGNsYXJpZnkgdGhhdCAoYWxz byBpbiBsaWV1IG9mDQo+ID4gPiA+ID4gPiA+ID4+IHNvbWUgb2YgdGhlDQo+ID4gPiA+ID4gPiA+ IG11bHRpLQ0KPiA+ID4gPiA+ID4gPiA+PiBob21pbmcgY29tbWVudHMgcmFpc2VkIHByZXZpb3Vz bHkpID8NCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gU0lHLTAxMDoNCj4gPiA+ ID4gPiA+ID4gPj4gLSBET1RTIENsaWVudCBiZWhpbmQgTkFULiBPbiBvbmUgaGFuZCwgaXQgc2Vl bXMNCj4gPiA+ID4gPiA+ID4gPj4gcmVhc29uYWJsZSB0byBoYXZlIHRoaXMgcmVxdWlyZW1lbnQg c2luY2UgY2xpZW50cyBmb3INCj4gPiA+ID4gPiA+ID4gPj4gc3VyZSBjYW4gYmUgYmVoaW5kIE5B VHMsIGFuZA0KPiA+ID4gPiA+IHdpdGgNCj4gPiA+ID4gPiA+IHRoaW5ncw0KPiA+ID4gPiA+ID4g PiA+PiBsaWtlIGR5bmFtaWMgRE5TLCB0aGV5IGNhbiAgICAgY2VydGFpbmx5IGJlIHJlYWNoYWJs ZS4NCj4gSG93ZXZlciwNCj4gPiA+IGlmDQo+ID4gPiA+ID4gd2UNCj4gPiA+ID4gPiA+ID4gZG8N Cj4gPiA+ID4gPiA+ID4gPj4gd2FudCB0byBhbGxvdyBmb3IgdGhpcyBzY2VuYXJpbywgYW5kIGlu IHBhcnRpY3VsYXIgZm9yDQo+ID4gPiA+ID4gPiA+ID4+IHRoZSBET1RTIGNsaWVudA0KPiA+ID4g PiA+ID4gPiB0bw0KPiA+ID4gPiA+ID4gPiA+PiBoYXZlIGEgcHJpdmF0ZSBJUC1hZGRyZXNzIChw b3RlbnRpYWxseSBiZWhpbmQgbXVsdGlwbGUNCj4gPiA+ID4gPiA+ID4gPj4gTkFUcyksIHRoZW4g d2UNCj4gPiA+ID4gPiA+ID4gaGF2ZQ0KPiA+ID4gPiA+ID4gPiA+PiBtb3JlIHdvcmsgdG8gZG8g YmVjYXVzZSBpdCB3b24ndCBkbyB0aGUgRE9UUyBzZXJ2ZXIgYW55DQo+ID4gPiA+ID4gPiA+ID4+ IGdvb2QgdG8gZ2V0IGEgbWl0aWdhdGlvbiByZXF1ZXN0IHJlZmVycmluZyB0byB0aGF0DQo+ID4g PiA+ID4gPiA+ID4+IHByaXZhdGUgSVAtYWRkcmVzcyAob3INCj4gPiA+ID4gPiBwcmVmaXgpLg0K PiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+PiBUaGFu a3MNCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gLS0gRmxlbW1pbmcNCj4gPiA+ ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ID4gPj4gRG90cyBtYWlsaW5nIGxpc3QN Cj4gPiA+ID4gPiA+ID4gPj4gRG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiA+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4gPiA+ID4gPiA+ID4gPj4NCj4g PiA+ID4gPiA+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiA+ID4gPiA+ID4gPj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+ID4g Pj4gRG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4gPiA+ID4gPiA+ID4gPiAuDQo+ID4gPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4g PiA+IERvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG90cw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBEb3RzIG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Thu Oct 26 05:49:55 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C890513F573 for ; Thu, 26 Oct 2017 05:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVJcM_Man_xA for ; Thu, 26 Oct 2017 05:49:52 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC3913F563 for ; Thu, 26 Oct 2017 05:49:52 -0700 (PDT) Received: from WTL-EXCHSV2-1.sandvine.com (192.168.194.58) by WTL-EXCHSV2-1.sandvine.com (192.168.194.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Thu, 26 Oct 2017 08:49:49 -0400 Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHSV2-1.sandvine.com (192.168.194.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1034.26 via Frontend Transport; Thu, 26 Oct 2017 08:49:49 -0400 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 26 Oct 2017 08:49:49 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "Konda, Tirumaleswar Reddy" , Flemming Andreasen , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAO8GKAACQhAQAAYkTigAABViKAAAB+EIAAAH6pgAAEb54AAAfog1AADcdhsP//Lswy Date: Thu, 26 Oct 2017 12:49:48 +0000 Message-ID: <20171026124947.5107771.45356.38919@sandvine.com> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> , <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 12:49:55 -0000 My point was that if server status was solicited, keep-alive interval would= be independent of firewall/NAT timeout. Keep-alives would be optional. Solicited means that client says "get status" vs. the server just sending u= pdates. David Dolson Sandvine Original Message From: mohamed.boucadair@orange.com Sent: Thursday, October 26, 2017 2:11 PM To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon Shallow= ; dots@ietf.org Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Hi Dave, The protocol does already support a mechanism to send keepalive messages ev= ery 30s (recommended value). Cheers, Med > -----Message d'origine----- > De : Dave Dolson [mailto:ddolson@sandvine.com] > Envoy=E9 : jeudi 26 octobre 2017 13:15 > =C0 : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed IMT/OLN; Flemming > Andreasen; Jon Shallow; dots@ietf.org > Objet : RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > I think there is another option to handle the NAT/firewall problems by > changing the protocol. > > If I understand correctly, currently the NAT and firewall need to be kept > open to permit unsolicited server packets. > > If the protocol is changed to require client polling of the server > updates, the NAT and firewall problems go away. > > -Dave > > > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswa= r > Reddy > Sent: Thursday, October 26, 2017 12:58 PM > To: mohamed.boucadair@orange.com; Flemming Andreasen; Jon Shallow; > dots@ietf.org > Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Thursday, October 26, 2017 2:21 PM > > To: Konda, Tirumaleswar Reddy ; > > Flemming Andreasen ; Jon Shallow > ietf@jpshallow.com>; dots@ietf.org > > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review > > (-06)) > > > > Re-, > > > > I hear you. My take is that we don't need to recommend which companion > > "protocols/mechanisms" need to be supported for NAT/FW traversal > > purposes. Having a discussion at the same level in 8085 would be > > sufficient, IMHO. > > > > Let's focus on the simple built-in feature for NAT detect. > > I don=92t think the simple built-in feature is sufficient, DOTS client wi= ll > have to rely on mechanisms discussed in 8085 for both firewall and NAT > traversal. > > -Tiru > > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9 : jeudi 26 octobre 2017 10:36 =C0 : BOUCADAIR Mohamed IMT/OL= N; > > > Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : RE: [Dots] > > > DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > > > > But NATs are not the only problem, firewalls will also be most > > > likely present, and STUN helps discover both NATs and firewalls and > > > useful even in IPv6 networks to determine the keepalive interval of > firewall. > > > > > > -Tiru > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com] > > > > Sent: Thursday, October 26, 2017 1:52 PM > > > > To: Konda, Tirumaleswar Reddy > > ; > > > > Flemming Andreasen ; Jon Shallow > > > ietf@jpshallow.com>; dots@ietf.org > > > > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review > > > > (-06)) > > > > > > > > Tiru, > > > > > > > > Yes, STUN can be listed as part of the existing tools box (among > > > > the > > > lines of > > > > what is already discussed in 8085). > > > > > > > > I don't think that it makes sense to require STUN support by DOTS > > > clients. > > > > > > > > The proposal is to include a simple built-in feature in the DOTS > > > protocol itself > > > > that can help to detect NATs. The support of such feature will, > > > > e.g., > > > ease > > > > troubleshooting when connectivity problems are experienced on the > > > > path between a client and a server. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De : Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9 : jeudi 26 octobre 2017 09:44 =C0 : BOUCADAIR Mohamed > > > > > IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : > > > > > RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: Tuesday, October 24, 2017 2:20 PM > > > > > > To: Flemming Andreasen ; Jon Shallow > > > > > > ; dots@ietf.org > > > > > > Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements > > > > > > review > > > > > > (-06)) > > > > > > > > > > > > Hi Flemming, all, > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De : Flemming Andreasen [mailto:fandreas@cisco.com] Envoy=E9 = : > > > > > > > lundi > > > > > > > 23 octobre 2017 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon > > > > > > > Shallow; dots@ietf.org Objet : Re: DOTS & NAT (was RE: > > > > > > > [Dots] DOTS Requirements review (-06)) > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/23/17 8:28 AM, mohamed.boucadair@orange.com wrote: > > > > > > > > Hi Jon, all, > > > > > > > > > > > > > > > > I agree with Flemming that "some more work" is needed. > > > > > > > > IMHO, this is a > > > > > > > typical discussion to include in a dedicated section in the > > > > > > > DOTS architecture I-D. > > > > > > > Agreed. > > > > > > > > >From a requirement standpoint, we don't need to elaborate > > > > > > > > >how the > > > > > > > protocols will fulfil it. SIG-10 does even a nice job by > > > > > > > citing > > > > > > > RFC8085 which points to NAT traversal mechanisms. One could > > > > > > > pick his/her favorite protocol from the list in 8085 to > > > > > > > discover the external IP address/prefix, if needed. External > > > > > > > IP addresses/prefixes can be IPv4 for a NAT44 or NAT64, but > > > > > > > can be > > > > > > > IPv6 prefixes for enterprises deploying NPTv6, and so on. > > > > > > > Part of the challenge here is that the attack target and the > > > > > > > DOTS client are not necessarily one and the same, which > > > > > > > makes it more difficult to determine the public-facing > > > > > > > IP-address/port under attack (at least if the DOTS client is > > > > > > > going to > > do it). > > > > > > > > > > > > [Med] This is exactly the kind of the discussion to have. > Thanks. > > > > > > > > > > > > With or without NAT, DOTS clients are assumed to be fed with > > > > > > the > > > > > internal > > > > > > target(s). This can be achieved by provisioning (likely) or by > > > > > > discovery > > > > > means > > > > > > (e.g., residential or small enterprise networks). > > > > > > > > > > > > Can we assume that the discovery of the external IP > > > > > > address/prefix/.. is > > > > > done > > > > > > by a DOTS client only if it is explicitly instructed to do so? > > > > > > > > > > > > > > > > > > > > In some deployments, DOTS clients may be provisioned with > > > > > > > > the set of > > > > > > > internal resources, so there is no need for discovery. > > > > > > > > > > > > > > > > Also, as Jon mentioned, DOTS gateways can be of help to > > > > > > > > set the > > > > > > > appropriate IP addresses/prefixes/port numbers in the > > > > > > > presence of translators. > > > > > > > Agreed - but they still need a way to figure out the > > > > > > > private/public mapping for a given attack target. > > > > > > > > > > > > [Med] Because a DDoS attack is observed from the internal > > > > > > network, > > > > > > mapping(s) are necessarily maintained by the on-path > translator(s). > > > > > > Otherwise, the incoming attack traffic couldn't be forwarded > > > > > > to internal > > > > > hosts. > > > > > > This model assumes that the gateway is collocated with the NAT. > > > > > > So, the gateway can replace the internal IP address/prefix > > > > > > with the one > > > > > retrieves > > > > > > from the NAT mapping table. > > > > > > > > > > > > Do you see any issue with this scheme? > > > > > > > > > > > > > > An open question though would be to discuss if there is a > > > > > > > > value in > > > > > > > having a feature in the DOTS protocol to inform a DOTS > > > > > > > client that a NAT is detected on-path. This can be presented > > > > > > > as an information element returned by the server to the > > > > > > > client. This information can be, for example, used by the > > > > > > > client to adjust its HT interval, adjust the internal IP > > > > > > > addresses/prefixes to be > > protected, etc. > > > Opinions? > > > > > > > It sounds appealing, but it's very difficult to do this > > > > > > > reliably, and it's not just NATs that are an issue here; > > > > > > > Firewalls present similar challenges (and they may or may > > > > > > > not be NAT'ing individual > > > > flows). > > > > > > > > > > > > > > > > > > > [Med] I fully agree that firewalls detect is more complex. > > > > > > Let's put it > > > > > aside > > > > > > and focus on the NAT case. > > > > > > > > > > The presence and behavior of NAT and Firewall, and keepalive > > > > > interval can be determined using STUN (discussed in > > > > > https://tools.ietf.org/html/rfc5780). > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > We can consider many approaches to detect a NAT, e.g., > > > > > > > > > > > > (1) The DOTS client inserts in the core message the IP > > > > > > address/port it > > > > > uses to > > > > > > send the request to the DOTS server. Upon receipt of the > > > > > > request by the DOTS server, it checks if the enclosed IP > > > > > > address/port match the source > > > > > IP > > > > > > address/port of the received packet. If yes, the server sets > > > > > > in the > > > > > response a > > > > > > dedicated parameter to indicate that a translator is detected > > > > > > on- > > > path. > > > > > > > > > > > > (2) The DOTS server inserts systematically the source IP > > > > > > address/port in > > > > > a > > > > > > response to a message from a DOTS client. Upon receipt of that > > > > > > response, the DOTS client compares the enclosed address/port > > > > > > with the ones it used > > > > > to > > > > > > send the request to detect any mismatch. > > > > > > > > > > > > > > > > > > > -- Flemming > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > >> -----Message d'origine----- De : Dots > > > > > > > >> [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > > > > > > > >> Envoy=E9 : lundi 23 octobre 2017 13:18 =C0 : 'Flemming > > > > > > > >> Andreasen'; dots@ietf.org Objet : Re: [Dots] DOTS > > > > > > > >> Requirements review (-06) > > > > > > > >> > > > > > > > >> Hi Flemming, > > > > > > > >> > > > > > > > >> The way my mind works is to think of a practical > > > > > > > >> situation and see if things fit. > > > > > > > >> > > > > > > > >> As I read SIG-010, there could be a DOTS client with a > > > > > > > >> management IP address that is RFC1918 - this client could > > > > > > > >> be monitoring Netflow information and can request > > > > > > > >> mitigation for the appropriate public IPs > > > > > > > that > > > > > > > >> are being monitored. So SIG-010 is needed for this use > case. > > > > > > > >> > > > > > > > >> It is the responsibility of the DOTS server as to whether > > > > > > > >> it accepts a mitigation request for a particular target > > > > > > > >> ip (or domain > > > > > etc.) or > > > > > > not. > > > > > > > >> > > > > > > > >> If there is going to be a NAT border where public IPs are > > > > > > > >> mapped into private IPs (and vice versa), I would then > > > > > > > >> expect there to be a DOTS gateway between these 2 zones, > > > > > > > >> and it is the responsibility of the DOTS gateway to do > > > > > > > >> any target-ip > > > mappings. > > > > > > > >> > > > > > > > >> Regards > > > > > > > >> > > > > > > > >> Jon > > > > > > > >> > > > > > > > >> -----Original Message----- > > > > > > > >> From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On > > > > > > > >> Behalf Of Flemming Andreasen > > > > > > > >> Sent: 22 October 2017 20:17 > > > > > > > >> To: dots; draft-ietf-dots-requirements@ietf.org > > > > > > > >> Subject: [Dots] DOTS Requirements review (-06) > > > > > > > >> > > > > > > > >> Greetings > > > > > > > >> > > > > > > > >> I have reviewed the latest version of the DOTS > > > > > > > >> requirements draft > > > > > > > >> (https://www.ietf.org/id/draft-ietf-dots-requirements- > 06.txt). > > > > > > > >> In > > > > > > > general, > > > > > > > >> I think the draft is in good shape with only a few edits > > > > > > > >> required, so I hope we can move to WGLC soon. I have a > > > > > > > >> few comments below (of which > > > > > > > the > > > > > > > >> NAT one is the only real substantial one). I have also > > > > > > > >> submitted a pull request with a few nit fixes on GitHub: > > > > > > > >> > > > > > > > >> > > > > > > > >> Section 1.2 > > > > > > > >> - The definition of "DOTS Signal" is slightly > > > > > > > >> inconsistent with the respective "Client Signal" and > "Server Signal" definitions. > > > > > > > >> > > > > > > > >> SIG-005: > > > > > > > >> - Not clear that always requiring "number of packets" > > > > > > > >> metrics is meaningful. Consider TCP-based attacks for > > > > > > > >> example. Number of bytes may always be ok - above and > > > > > > > >> beyond that it should probably be extensible and/or > > > > > > > >> attack > > dependent. > > > > > > > >> - I don't think the requirements document should get into > > > > > > > >> specifying > > > > > > > timer > > > > > > > >> values - expontial backoff with some maximum value seems > > > > > > > >> about the > > > > > > > right > > > > > > > >> level of detail here. > > > > > > > >> > > > > > > > >> SIG-009: > > > > > > > >> - To be clear, the conflicts only apply within a single > > > > > > > >> administrative domain, right ? For example, if a client > > > > > > > >> tells the same domain to alternately turn on/off > > > > > > > >> mitigation for a given prefix, route flapping > > > > > > > may > > > > > > > >> occur. The same concern does not apply if a client tells > > > > > > > >> two different administrative domains to respective turn > > > > > > > >> mitigation on (domain 1) and > > > > > > > off > > > > > > > >> (domain 2). If so, can we clarify that (also in lieu of > > > > > > > >> some of the > > > > > > > multi- > > > > > > > >> homing comments raised previously) ? > > > > > > > >> > > > > > > > >> SIG-010: > > > > > > > >> - DOTS Client behind NAT. On one hand, it seems > > > > > > > >> reasonable to have this requirement since clients for > > > > > > > >> sure can be behind NATs, and > > > > > with > > > > > > things > > > > > > > >> like dynamic DNS, they can certainly be reachable. > However, > > > if > > > > > we > > > > > > > do > > > > > > > >> want to allow for this scenario, and in particular for > > > > > > > >> the DOTS client > > > > > > > to > > > > > > > >> have a private IP-address (potentially behind multiple > > > > > > > >> NATs), then we > > > > > > > have > > > > > > > >> more work to do because it won't do the DOTS server any > > > > > > > >> good to get a mitigation request referring to that > > > > > > > >> private IP-address (or > > > > > prefix). > > > > > > > >> > > > > > > > >> > > > > > > > >> Thanks > > > > > > > >> > > > > > > > >> -- Flemming > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> Dots mailing list > > > > > > > >> Dots@ietf.org > > > > > > > >> https://www.ietf.org/mailman/listinfo/dots > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> Dots mailing list > > > > > > > >> Dots@ietf.org > > > > > > > >> https://www.ietf.org/mailman/listinfo/dots > > > > > > > > . > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Oct 26 06:06:11 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B61113F59B for ; Thu, 26 Oct 2017 06:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spKyOrTNcTXA for ; Thu, 26 Oct 2017 06:06:06 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CCB13F594 for ; Thu, 26 Oct 2017 06:06:06 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 5EBC616107B; Thu, 26 Oct 2017 15:06:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 3E1C94006A; Thu, 26 Oct 2017 15:06:05 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0361.001; Thu, 26 Oct 2017 15:06:04 +0200 From: To: Dave Dolson , "Konda, Tirumaleswar Reddy" , Flemming Andreasen , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAO8GKAACQhAQAAYkTigAABViKAAAB+EIAAAH6pgAAEb54AAAfog1AADcdhsP//Lswy///9vXA= Date: Thu, 26 Oct 2017 13:06:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> , <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> In-Reply-To: <20171026124947.5107771.45356.38919@sandvine.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:06:09 -0000 Re-, Not sure how to get rid of the constraint imposed by the NAT/FW timer, Dave= .=20 The current text says the following:=20 To provide a metric of signal health and distinguish an 'idle' signal channel from a 'disconnected' or 'defunct' session, the DOTS agent sends a heartbeat over the signal channel to maintain its half of the channel. The DOTS agent similarly expects a heartbeat from its peer DOTS agent, and may consider a session terminated in the extended absence of a peer agent heartbeat. Which covers your proposal. No?=20 Solicited messages from the server do not prevent from failures. Consider t= he case where a DOTS server has to send a mitigation status update back to = the client, but the client didn't refreshed the state. Or when the NAT fire= d out a mapping and assigns the external port to another host than the DOTS= client.=20 Did I missed something? Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Dave Dolson [mailto:ddolson@sandvine.com] > Envoy=E9=A0: jeudi 26 octobre 2017 14:50 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; Flemming > Andreasen; Jon Shallow; dots@ietf.org > Objet=A0: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >=20 > My point was that if server status was solicited, keep-alive interval > would be independent of firewall/NAT timeout. Keep-alives would be > optional. >=20 > Solicited means that client says "get status" vs. the server just sending > updates. >=20 >=20 >=20 > David Dolson > Sandvine > Original Message > From: mohamed.boucadair@orange.com > Sent: Thursday, October 26, 2017 2:11 PM > To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon > Shallow; dots@ietf.org > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >=20 >=20 > Hi Dave, >=20 > The protocol does already support a mechanism to send keepalive messages > every 30s (recommended value). >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Dave Dolson [mailto:ddolson@sandvine.com] > > Envoy=E9 : jeudi 26 octobre 2017 13:15 > > =C0 : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed IMT/OLN; Flemming > > Andreasen; Jon Shallow; dots@ietf.org > > Objet : RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > > I think there is another option to handle the NAT/firewall problems by > > changing the protocol. > > > > If I understand correctly, currently the NAT and firewall need to be > kept > > open to permit unsolicited server packets. > > > > If the protocol is changed to require client polling of the server > > updates, the NAT and firewall problems go away. > > > > -Dave > > > > > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar > > Reddy > > Sent: Thursday, October 26, 2017 12:58 PM > > To: mohamed.boucadair@orange.com; Flemming Andreasen; Jon Shallow; > > dots@ietf.org > > Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Thursday, October 26, 2017 2:21 PM > > > To: Konda, Tirumaleswar Reddy ; > > > Flemming Andreasen ; Jon Shallow > > ietf@jpshallow.com>; dots@ietf.org > > > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review > > > (-06)) > > > > > > Re-, > > > > > > I hear you. My take is that we don't need to recommend which companio= n > > > "protocols/mechanisms" need to be supported for NAT/FW traversal > > > purposes. Having a discussion at the same level in 8085 would be > > > sufficient, IMHO. > > > > > > Let's focus on the simple built-in feature for NAT detect. > > > > I don't think the simple built-in feature is sufficient, DOTS client > will > > have to rely on mechanisms discussed in 8085 for both firewall and NAT > > traversal. > > > > -Tiru > > > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9 : jeudi 26 octobre 2017 10:36 =C0 : BOUCADAIR Mohamed IMT/= OLN; > > > > Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : RE: [Dots] > > > > DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > > > > > > But NATs are not the only problem, firewalls will also be most > > > > likely present, and STUN helps discover both NATs and firewalls and > > > > useful even in IPv6 networks to determine the keepalive interval of > > firewall. > > > > > > > > -Tiru > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucadair@orange.com > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > Sent: Thursday, October 26, 2017 1:52 PM > > > > > To: Konda, Tirumaleswar Reddy > > > ; > > > > > Flemming Andreasen ; Jon Shallow > > > > ietf@jpshallow.com>; dots@ietf.org > > > > > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review > > > > > (-06)) > > > > > > > > > > Tiru, > > > > > > > > > > Yes, STUN can be listed as part of the existing tools box (among > > > > > the > > > > lines of > > > > > what is already discussed in 8085). > > > > > > > > > > I don't think that it makes sense to require STUN support by DOTS > > > > clients. > > > > > > > > > > The proposal is to include a simple built-in feature in the DOTS > > > > protocol itself > > > > > that can help to detect NATs. The support of such feature will, > > > > > e.g., > > > > ease > > > > > troubleshooting when connectivity problems are experienced on the > > > > > path between a client and a server. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Konda, Tirumaleswar Reddy > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9 : jeudi 26 octobre 2017 09:44 =C0 : BOUCADAIR Mohamed > > > > > > IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : > > > > > > RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: Tuesday, October 24, 2017 2:20 PM > > > > > > > To: Flemming Andreasen ; Jon Shallow > > > > > > > ; dots@ietf.org > > > > > > > Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements > > > > > > > review > > > > > > > (-06)) > > > > > > > > > > > > > > Hi Flemming, all, > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > > De : Flemming Andreasen [mailto:fandreas@cisco.com] Envoy= =E9 : > > > > > > > > lundi > > > > > > > > 23 octobre 2017 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon > > > > > > > > Shallow; dots@ietf.org Objet : Re: DOTS & NAT (was RE: > > > > > > > > [Dots] DOTS Requirements review (-06)) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/23/17 8:28 AM, mohamed.boucadair@orange.com wrote: > > > > > > > > > Hi Jon, all, > > > > > > > > > > > > > > > > > > I agree with Flemming that "some more work" is needed. > > > > > > > > > IMHO, this is a > > > > > > > > typical discussion to include in a dedicated section in the > > > > > > > > DOTS architecture I-D. > > > > > > > > Agreed. > > > > > > > > > >From a requirement standpoint, we don't need to elaborat= e > > > > > > > > > >how the > > > > > > > > protocols will fulfil it. SIG-10 does even a nice job by > > > > > > > > citing > > > > > > > > RFC8085 which points to NAT traversal mechanisms. One could > > > > > > > > pick his/her favorite protocol from the list in 8085 to > > > > > > > > discover the external IP address/prefix, if needed. Externa= l > > > > > > > > IP addresses/prefixes can be IPv4 for a NAT44 or NAT64, but > > > > > > > > can be > > > > > > > > IPv6 prefixes for enterprises deploying NPTv6, and so on. > > > > > > > > Part of the challenge here is that the attack target and th= e > > > > > > > > DOTS client are not necessarily one and the same, which > > > > > > > > makes it more difficult to determine the public-facing > > > > > > > > IP-address/port under attack (at least if the DOTS client i= s > > > > > > > > going to > > > do it). > > > > > > > > > > > > > > [Med] This is exactly the kind of the discussion to have. > > Thanks. > > > > > > > > > > > > > > With or without NAT, DOTS clients are assumed to be fed with > > > > > > > the > > > > > > internal > > > > > > > target(s). This can be achieved by provisioning (likely) or b= y > > > > > > > discovery > > > > > > means > > > > > > > (e.g., residential or small enterprise networks). > > > > > > > > > > > > > > Can we assume that the discovery of the external IP > > > > > > > address/prefix/.. is > > > > > > done > > > > > > > by a DOTS client only if it is explicitly instructed to do so= ? > > > > > > > > > > > > > > > > > > > > > > > In some deployments, DOTS clients may be provisioned with > > > > > > > > > the set of > > > > > > > > internal resources, so there is no need for discovery. > > > > > > > > > > > > > > > > > > Also, as Jon mentioned, DOTS gateways can be of help to > > > > > > > > > set the > > > > > > > > appropriate IP addresses/prefixes/port numbers in the > > > > > > > > presence of translators. > > > > > > > > Agreed - but they still need a way to figure out the > > > > > > > > private/public mapping for a given attack target. > > > > > > > > > > > > > > [Med] Because a DDoS attack is observed from the internal > > > > > > > network, > > > > > > > mapping(s) are necessarily maintained by the on-path > > translator(s). > > > > > > > Otherwise, the incoming attack traffic couldn't be forwarded > > > > > > > to internal > > > > > > hosts. > > > > > > > This model assumes that the gateway is collocated with the > NAT. > > > > > > > So, the gateway can replace the internal IP address/prefix > > > > > > > with the one > > > > > > retrieves > > > > > > > from the NAT mapping table. > > > > > > > > > > > > > > Do you see any issue with this scheme? > > > > > > > > > > > > > > > > An open question though would be to discuss if there is a > > > > > > > > > value in > > > > > > > > having a feature in the DOTS protocol to inform a DOTS > > > > > > > > client that a NAT is detected on-path. This can be presente= d > > > > > > > > as an information element returned by the server to the > > > > > > > > client. This information can be, for example, used by the > > > > > > > > client to adjust its HT interval, adjust the internal IP > > > > > > > > addresses/prefixes to be > > > protected, etc. > > > > Opinions? > > > > > > > > It sounds appealing, but it's very difficult to do this > > > > > > > > reliably, and it's not just NATs that are an issue here; > > > > > > > > Firewalls present similar challenges (and they may or may > > > > > > > > not be NAT'ing individual > > > > > flows). > > > > > > > > > > > > > > > > > > > > > > [Med] I fully agree that firewalls detect is more complex. > > > > > > > Let's put it > > > > > > aside > > > > > > > and focus on the NAT case. > > > > > > > > > > > > The presence and behavior of NAT and Firewall, and keepalive > > > > > > interval can be determined using STUN (discussed in > > > > > > https://tools.ietf.org/html/rfc5780). > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > We can consider many approaches to detect a NAT, e.g., > > > > > > > > > > > > > > (1) The DOTS client inserts in the core message the IP > > > > > > > address/port it > > > > > > uses to > > > > > > > send the request to the DOTS server. Upon receipt of the > > > > > > > request by the DOTS server, it checks if the enclosed IP > > > > > > > address/port match the source > > > > > > IP > > > > > > > address/port of the received packet. If yes, the server sets > > > > > > > in the > > > > > > response a > > > > > > > dedicated parameter to indicate that a translator is detected > > > > > > > on- > > > > path. > > > > > > > > > > > > > > (2) The DOTS server inserts systematically the source IP > > > > > > > address/port in > > > > > > a > > > > > > > response to a message from a DOTS client. Upon receipt of tha= t > > > > > > > response, the DOTS client compares the enclosed address/port > > > > > > > with the ones it used > > > > > > to > > > > > > > send the request to detect any mismatch. > > > > > > > > > > > > > > > > > > > > > > -- Flemming > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Med > > > > > > > > > > > > > > > > > >> -----Message d'origine----- De : Dots > > > > > > > > >> [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > > > > > > > > >> Envoy=E9 : lundi 23 octobre 2017 13:18 =C0 : 'Flemming > > > > > > > > >> Andreasen'; dots@ietf.org Objet : Re: [Dots] DOTS > > > > > > > > >> Requirements review (-06) > > > > > > > > >> > > > > > > > > >> Hi Flemming, > > > > > > > > >> > > > > > > > > >> The way my mind works is to think of a practical > > > > > > > > >> situation and see if things fit. > > > > > > > > >> > > > > > > > > >> As I read SIG-010, there could be a DOTS client with a > > > > > > > > >> management IP address that is RFC1918 - this client coul= d > > > > > > > > >> be monitoring Netflow information and can request > > > > > > > > >> mitigation for the appropriate public IPs > > > > > > > > that > > > > > > > > >> are being monitored. So SIG-010 is needed for this use > > case. > > > > > > > > >> > > > > > > > > >> It is the responsibility of the DOTS server as to whethe= r > > > > > > > > >> it accepts a mitigation request for a particular target > > > > > > > > >> ip (or domain > > > > > > etc.) or > > > > > > > not. > > > > > > > > >> > > > > > > > > >> If there is going to be a NAT border where public IPs ar= e > > > > > > > > >> mapped into private IPs (and vice versa), I would then > > > > > > > > >> expect there to be a DOTS gateway between these 2 zones, > > > > > > > > >> and it is the responsibility of the DOTS gateway to do > > > > > > > > >> any target-ip > > > > mappings. > > > > > > > > >> > > > > > > > > >> Regards > > > > > > > > >> > > > > > > > > >> Jon > > > > > > > > >> > > > > > > > > >> -----Original Message----- > > > > > > > > >> From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On > > > > > > > > >> Behalf Of Flemming Andreasen > > > > > > > > >> Sent: 22 October 2017 20:17 > > > > > > > > >> To: dots; draft-ietf-dots-requirements@ietf.org > > > > > > > > >> Subject: [Dots] DOTS Requirements review (-06) > > > > > > > > >> > > > > > > > > >> Greetings > > > > > > > > >> > > > > > > > > >> I have reviewed the latest version of the DOTS > > > > > > > > >> requirements draft > > > > > > > > >> (https://www.ietf.org/id/draft-ietf-dots-requirements- > > 06.txt). > > > > > > > > >> In > > > > > > > > general, > > > > > > > > >> I think the draft is in good shape with only a few edits > > > > > > > > >> required, so I hope we can move to WGLC soon. I have a > > > > > > > > >> few comments below (of which > > > > > > > > the > > > > > > > > >> NAT one is the only real substantial one). I have also > > > > > > > > >> submitted a pull request with a few nit fixes on GitHub: > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> Section 1.2 > > > > > > > > >> - The definition of "DOTS Signal" is slightly > > > > > > > > >> inconsistent with the respective "Client Signal" and > > "Server Signal" definitions. > > > > > > > > >> > > > > > > > > >> SIG-005: > > > > > > > > >> - Not clear that always requiring "number of packets" > > > > > > > > >> metrics is meaningful. Consider TCP-based attacks for > > > > > > > > >> example. Number of bytes may always be ok - above and > > > > > > > > >> beyond that it should probably be extensible and/or > > > > > > > > >> attack > > > dependent. > > > > > > > > >> - I don't think the requirements document should get int= o > > > > > > > > >> specifying > > > > > > > > timer > > > > > > > > >> values - expontial backoff with some maximum value seems > > > > > > > > >> about the > > > > > > > > right > > > > > > > > >> level of detail here. > > > > > > > > >> > > > > > > > > >> SIG-009: > > > > > > > > >> - To be clear, the conflicts only apply within a single > > > > > > > > >> administrative domain, right ? For example, if a client > > > > > > > > >> tells the same domain to alternately turn on/off > > > > > > > > >> mitigation for a given prefix, route flapping > > > > > > > > may > > > > > > > > >> occur. The same concern does not apply if a client tells > > > > > > > > >> two different administrative domains to respective turn > > > > > > > > >> mitigation on (domain 1) and > > > > > > > > off > > > > > > > > >> (domain 2). If so, can we clarify that (also in lieu of > > > > > > > > >> some of the > > > > > > > > multi- > > > > > > > > >> homing comments raised previously) ? > > > > > > > > >> > > > > > > > > >> SIG-010: > > > > > > > > >> - DOTS Client behind NAT. On one hand, it seems > > > > > > > > >> reasonable to have this requirement since clients for > > > > > > > > >> sure can be behind NATs, and > > > > > > with > > > > > > > things > > > > > > > > >> like dynamic DNS, they can certainly be reachable. > > However, > > > > if > > > > > > we > > > > > > > > do > > > > > > > > >> want to allow for this scenario, and in particular for > > > > > > > > >> the DOTS client > > > > > > > > to > > > > > > > > >> have a private IP-address (potentially behind multiple > > > > > > > > >> NATs), then we > > > > > > > > have > > > > > > > > >> more work to do because it won't do the DOTS server any > > > > > > > > >> good to get a mitigation request referring to that > > > > > > > > >> private IP-address (or > > > > > > prefix). > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> Thanks > > > > > > > > >> > > > > > > > > >> -- Flemming > > > > > > > > >> > > > > > > > > >> _______________________________________________ > > > > > > > > >> Dots mailing list > > > > > > > > >> Dots@ietf.org > > > > > > > > >> https://www.ietf.org/mailman/listinfo/dots > > > > > > > > >> > > > > > > > > >> _______________________________________________ > > > > > > > > >> Dots mailing list > > > > > > > > >> Dots@ietf.org > > > > > > > > >> https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Oct 26 06:12:08 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8B5137A70 for ; Thu, 26 Oct 2017 06:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 9pAbSjtwIDhU for ; Thu, 26 Oct 2017 06:12:04 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 B5C7813F4A9 for ; Thu, 26 Oct 2017 06:12:03 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509023511; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=o gNqzX8XYSTUjr1VnKDGC5n/BTifU9mJCnT1xTNLVa s=; b=WhCnZuNoPYYgtA+Vt12fulEbwUbRcvkeLV/Dr+7e1V2O fPJdty3gHg1FkwmxAiRUdMkHghVyF1Fp0gVqYg4Zo5ky9mpOmf F0Wn3tZiujWhrSYI9f3x6kQiPbwL3iCnzYW+9Hw5ZiY2a3kJXB 6S1W/E10davr0qTPWiDtfcef5xk= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 5c17_587c_4d48c268_0322_44b3_97f3_6026af1f56b1; Thu, 26 Oct 2017 08:11:50 -0500 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 07:11:43 -0600 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 07:11:41 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 26 Oct 2017 07:11:41 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 07:11:40 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 26 Oct 2017 13:11:40 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0156.007; Thu, 26 Oct 2017 13:11:40 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Flemming Andreasen" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAGjp6AACQhAAAAYgT5UAABUQNgAACCGwAAAIl5gAAA3jTgAAYVpgAAAg5UIA== Date: Thu, 26 Oct 2017 13:11:39 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E858@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A05E858@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.88.198] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:01+TDctnWNTZYNf7XQLX+Xa08a11oqUfLuuDHcC0qeokxTEfguALVMgI9oaDS1AoPATx3qucEFWQizNT0vdRr7R4TQyxFwZNA0uwxI1nLsN2jMIzr9WaeMYoSeFqomziH6p0FtMeCf0eHuBSMpRfC+FXmfcQ0cXeHq7VddOj4Hvab/fWo1CS2mY9ThOHmCSGfPishqX/hKssfGftM/Is5QWTw48LVE0wBL0ef+8MP6f4BsqGh7uVMA0KgQTTlYbOXuREHjE2tN0caOe9OEgjpUGw4Qzl1EYhgmatoo7FTVOaPdcJp2tebMNtcHx6X3X5v2h7Y7Vhq5As+i5YqulwNA==; 5:n3mEeav9UN18kdQcl4PDfyW3s79gi9zyqlTGXVQ8/bL2V/knZKvhTU3SicNqn5iwj4GlsIipJpgiEoGXqbZiBha1gimJvgFs1fQeGsk+m1T1aSehcgE+wfLK1hEklecl/k2ZXPCpqMAEoroTpGSSFA==; 24:VT3tstMP4A1VJvQwj+Uk5ixx4LWLcOnH93SLLDcsp4NR6DFhK9YUOTNkeDicnbLT5H1EdTGxhXuX5kmpOKTGs9wU+dr0EloCxrkRIgExlT4=; 7:zmtPrrX5phJpRY1potsS6M/5Ed3s+r2hpnWflX93z4ppAlqGdUnxRMtdtgH7mbq4oirkDsWDxO5CZnioTe+m90zXowG5akGeKe1C0//bf5bsjFM9i0rysO+q6/qeqkWZKRQJ370yao+UalEQm71rQn1YvIcQ+ZG1nxMb9HlYT3QKZneWdypKzBiNUNjMMtYyQF+y8PsatDQOCThaz7FfzeUJu7EMlWXR1u6XopedydA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 56f4d797-822d-4fdc-4a23-08d51c73187d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(788757137089)(95692535739014)(18271650672692)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3231020)(3002001)(6041248)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(32952001)(55784002)(189002)(13464003)(24454002)(199003)(25786009)(189998001)(74316002)(110136005)(305945005)(2501003)(2950100002)(966005)(7736002)(2906002)(86362001)(5660300001)(33656002)(561944003)(14454004)(316002)(54356999)(93886005)(101416001)(76176999)(7696004)(53546010)(50986999)(66066001)(6116002)(105586002)(102836003)(81166006)(68736007)(8936002)(3846002)(8676002)(72206003)(106356001)(2900100001)(81156014)(99286003)(55016002)(53936002)(6306002)(478600001)(53946003)(97736004)(3660700001)(80792005)(6246003)(9686003)(229853002)(77096006)(6436002)(6506006)(3280700002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 56f4d797-822d-4fdc-4a23-08d51c73187d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 13:11:39.8911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6145> : inlines <6146> : streams <1768473> : uri <2522728> Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:12:07 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tDQo+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4gU2Vu dDogVGh1cnNkYXksIE9jdG9iZXIgMjYsIDIwMTcgNTozOSBQTQ0KPiBUbzogS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47DQo+IEZs ZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPjsgSm9uIFNoYWxsb3cgPHN1cGpw cy0NCj4gaWV0ZkBqcHNoYWxsb3cuY29tPjsgZG90c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTog W0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYp KQ0KPiANCj4gUmUtLA0KPiANCj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+IA0KPiBDaGVlcnMsDQo+ IE1lZA0KPiANCj4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiBEZcKgOiBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+ID4gW21haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBNY0FmZWUuY29tXQ0KPiA+IEVudm95w6nCoDogamV1ZGkgMjYgb2N0b2JyZSAyMDE3IDEyOjU4 DQo+ID4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgRmxlbW1pbmcgQW5kcmVhc2Vu OyBKb24gU2hhbGxvdzsNCj4gPiBkb3RzQGlldGYub3JnIE9iamV0wqA6IFJFOiBbRG90c10gRE9U UyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cw0KPiA+IHJldmlldyAoLTA2KSkNCj4g Pg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiA+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbV0NCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDI6MjEgUE0N Cj4gPiA+IFRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+IDxUaXJ1bWFsZXN3YXJSZWRk eV9Lb25kYUBNY0FmZWUuY29tPjsNCj4gPiA+IEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNA Y2lzY28uY29tPjsgSm9uIFNoYWxsb3cgPHN1cGpwcy0NCj4gPiA+IGlldGZAanBzaGFsbG93LmNv bT47IGRvdHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyAmIE5BVCAo d2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcNCj4gPiA+ICgtMDYpKQ0KPiA+ID4NCj4g PiA+IFJlLSwNCj4gPiA+DQo+ID4gPiBJIGhlYXIgeW91LiBNeSB0YWtlIGlzIHRoYXQgd2UgZG9u J3QgbmVlZCB0byByZWNvbW1lbmQgd2hpY2gNCj4gPiA+IGNvbXBhbmlvbiAicHJvdG9jb2xzL21l Y2hhbmlzbXMiIG5lZWQgdG8gYmUgc3VwcG9ydGVkIGZvciBOQVQvRlcNCj4gPiA+IHRyYXZlcnNh bCBwdXJwb3Nlcy4gSGF2aW5nIGEgZGlzY3Vzc2lvbiBhdCB0aGUgc2FtZSBsZXZlbCBpbiA4MDg1 DQo+ID4gPiB3b3VsZCBiZQ0KPiA+IHN1ZmZpY2llbnQsDQo+ID4gPiBJTUhPLg0KPiA+ID4NCj4g PiA+IExldCdzIGZvY3VzIG9uIHRoZSBzaW1wbGUgYnVpbHQtaW4gZmVhdHVyZSBmb3IgTkFUIGRl dGVjdC4NCj4gPg0KPiA+IEkgZG9u4oCZdCB0aGluayB0aGUgc2ltcGxlIGJ1aWx0LWluIGZlYXR1 cmUgaXMgc3VmZmljaWVudCwNCj4gDQo+IFtNZWRdIEl0IGRlcGVuZHMgZm9yIHdoYXQgcHVycG9z ZS4gRm9yIGV4YW1wbGUsIHRoZSBidWlsdC1pbiBmZWF0dXJlIHdpbGwNCj4gaGVscCB0cm91Ymxl c2hvb3Rpbmcgd2hlbiBwcm9ibGVtcyBhcmUgZXhwZXJpZW5jZWQgdG8gZGVsaXZlciBET1RTDQo+ IG1lc3NhZ2VzIGluIHRoZSBwcmVzZW5jZSBvZiBOQVRzLg0KDQpOQVRzIHdpbGwgbm90IGNhdXNl IGFueSBzcGVjaWZpYyBwcm9ibGVtIGZvciBqdXN0IHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIHBy b3RvY29sLiANCkluIHRoZSBwcmVzZW5jZSBvZiAgTkFULCBET1RTIHdpbGwgZmFjZSB0aGUgc2Ft ZSBwcm9ibGVtcyBhcyBhbnkgb3RoZXIgcHJvdG9jb2wgbGlrZSBRVUlDLCBDb0FQIGV0Yy4gcnVu bmluZyBvdmVyIFVEUC4gDQoNCj4gDQo+ICBET1RTIGNsaWVudCB3aWxsDQo+ID4gaGF2ZSB0byBy ZWx5IG9uIG1lY2hhbmlzbXMgZGlzY3Vzc2VkIGluIDgwODUgZm9yIGJvdGggZmlyZXdhbGwgYW5k IE5BVA0KPiA+IHRyYXZlcnNhbC4NCj4gDQo+IFtNZWRdIEknbSBub3Qgc3VyZS4gQWN0dWFsbHks IGl0IGRlcGVuZHMgd2hldGhlciB3ZSB3YW50IHRvICoqIG9wdGltaXplICoqDQo+IHRoZSBrZWVw YWxpdmUgbWVzc2FnZXMgYW5kIGF2b2lkIG92ZXJsb2FkaW5nIHRoZSBuZXR3b3JrLiBIYXZpbmcg YQ0KPiBOQVQvRlcgdHJhdmVyc2FsIHByb3RvY29sIHRoYXQgYWxsb3dzIHRvIGxlYXJuIHRoZSBO QVQvRlcgdmFsaWRpdHkgbGlmZXRpbWUNCj4gd2lsbCBhbGxvdyB0byBhZGp1c3QgdGhlIGtlZXAg YWxpdmUgaW50ZXJ2YWwuIFRoYXQncyBvbmx5IGFuIG9wdGltaXphdGlvbi4NCg0KWWVzLCB0aGVz ZSBtZWNoYW5pc21zIG9ubHkgaGVscCB0byBvcHRpbWl6ZSB0aGUga2VlcC1hbGl2ZSBpbnRlcnZh bC4NCg0KLVRpcnUNCg0KPiANCj4gPg0KPiA+IC1UaXJ1DQo+ID4NCj4gPiA+DQo+ID4gPiBDaGVl cnMsDQo+ID4gPiBNZWQNCj4gPiA+DQo+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiA+ID4gPiBEZcKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+ID4gPiA+IFttYWls dG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0NCj4gPiA+ID4gRW52b3nDqcKg OiBqZXVkaSAyNiBvY3RvYnJlIDIwMTcgMTA6MzYgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQNCj4g PiA+ID4gSU1UL09MTjsgRmxlbW1pbmcgQW5kcmVhc2VuOyBKb24gU2hhbGxvdzsgZG90c0BpZXRm Lm9yZyBPYmpldMKgOg0KPiA+ID4gPiBSRTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9U UyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKQ0KPiA+ID4gPg0KPiA+ID4gPiBCdXQgTkFUcyBh cmUgbm90IHRoZSBvbmx5IHByb2JsZW0sIGZpcmV3YWxscyB3aWxsIGFsc28gYmUgbW9zdA0KPiA+ ID4gPiBsaWtlbHkgcHJlc2VudCwgYW5kIFNUVU4gaGVscHMgZGlzY292ZXIgYm90aCBOQVRzIGFu ZCBmaXJld2FsbHMNCj4gPiA+ID4gYW5kIHVzZWZ1bCBldmVuIGluIElQdjYgbmV0d29ya3MgdG8g ZGV0ZXJtaW5lIHRoZSBrZWVwYWxpdmUgaW50ZXJ2YWwgb2YNCj4gZmlyZXdhbGwuDQo+ID4gPiA+ DQo+ID4gPiA+IC1UaXJ1DQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4g PiA+ID4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPiA+ID4gPiA+IFNl bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDE6NTIgUE0NCj4gPiA+ID4gPiBUbzogS29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+ID4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1j QWZlZS5jb20+Ow0KPiA+ID4gPiA+IEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28u Y29tPjsgSm9uIFNoYWxsb3cgPHN1cGpwcy0NCj4gPiA+ID4gPiBpZXRmQGpwc2hhbGxvdy5jb20+ OyBkb3RzQGlldGYub3JnDQo+ID4gPiA+ID4gU3ViamVjdDogUkU6IFtEb3RzXSBET1RTICYgTkFU ICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJldmlldw0KPiA+ID4gPiA+ICgtMDYpKQ0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gVGlydSwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFllcywgU1RVTiBj YW4gYmUgbGlzdGVkIGFzIHBhcnQgb2YgdGhlIGV4aXN0aW5nIHRvb2xzIGJveCAoYW1vbmcNCj4g PiA+ID4gPiB0aGUNCj4gPiA+ID4gbGluZXMgb2YNCj4gPiA+ID4gPiB3aGF0IGlzIGFscmVhZHkg ZGlzY3Vzc2VkIGluIDgwODUpLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBkb24ndCB0aGluayB0 aGF0IGl0IG1ha2VzIHNlbnNlIHRvIHJlcXVpcmUgU1RVTiBzdXBwb3J0IGJ5DQo+ID4gPiA+ID4g RE9UUw0KPiA+ID4gPiBjbGllbnRzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIHByb3Bvc2Fs IGlzIHRvIGluY2x1ZGUgYSBzaW1wbGUgYnVpbHQtaW4gZmVhdHVyZSBpbiB0aGUgRE9UUw0KPiA+ ID4gPiBwcm90b2NvbCBpdHNlbGYNCj4gPiA+ID4gPiB0aGF0IGNhbiBoZWxwIHRvIGRldGVjdCBO QVRzLiBUaGUgc3VwcG9ydCBvZiBzdWNoIGZlYXR1cmUgd2lsbCwNCj4gPiA+ID4gPiBlLmcuLA0K PiA+ID4gPiBlYXNlDQo+ID4gPiA+ID4gdHJvdWJsZXNob290aW5nIHdoZW4gY29ubmVjdGl2aXR5 IHByb2JsZW1zIGFyZSBleHBlcmllbmNlZCBvbg0KPiA+ID4gPiA+IHRoZSBwYXRoIGJldHdlZW4g YSBjbGllbnQgYW5kIGEgc2VydmVyLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ ID4gPiA+IE1lZA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS0NCj4gPiA+ID4gPiA+IERlwqA6IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPiA+ ID4gPiA+IFttYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0NCj4gPiA+ ID4gPiA+IEVudm95w6nCoDogamV1ZGkgMjYgb2N0b2JyZSAyMDE3IDA5OjQ0IMOAwqA6IEJPVUNB REFJUiBNb2hhbWVkDQo+ID4gPiA+ID4gPiBJTVQvT0xOOyBGbGVtbWluZyBBbmRyZWFzZW47IEpv biBTaGFsbG93OyBkb3RzQGlldGYub3JnIE9iamV0wqA6DQo+ID4gPiA+ID4gPiBSRTogW0RvdHNd IERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKQ0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ ID4gPiA+ID4gRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mDQo+ID4gPiA+ID4gPiA+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiA+ ID4gPiA+ID4gU2VudDogVHVlc2RheSwgT2N0b2JlciAyNCwgMjAxNyAyOjIwIFBNDQo+ID4gPiA+ ID4gPiA+IFRvOiBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2NvLmNvbT47IEpvbiBT aGFsbG93DQo+ID4gPiA+ID4gPiA+IDxzdXBqcHMtIGlldGZAanBzaGFsbG93LmNvbT47IGRvdHNA aWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4gU3ViamVjdDogUmU6IFtEb3RzXSBET1RTICYgTkFUICh3 YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzDQo+ID4gPiA+ID4gPiA+IHJldmlldw0KPiA+ID4gPiA+ ID4gPiAoLTA2KSkNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSGkgRmxlbW1pbmcsIGFs bCwNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IENoZWVycywNCj4gPiA+ID4gPiA+ID4gTWVkDQo+ID4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tIERl wqA6IEZsZW1taW5nIEFuZHJlYXNlbg0KPiA+ID4gPiA+ID4gPiA+IFttYWlsdG86ZmFuZHJlYXNA Y2lzY28uY29tXSBFbnZvecOpwqA6DQo+ID4gPiA+ID4gPiA+ID4gbHVuZGkNCj4gPiA+ID4gPiA+ ID4gPiAyMyBvY3RvYnJlIDIwMTcgMTc6MzYgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09M TjsgSm9uDQo+ID4gPiA+ID4gPiA+ID4gU2hhbGxvdzsgZG90c0BpZXRmLm9yZyBPYmpldMKgOiBS ZTogRE9UUyAmIE5BVCAod2FzIFJFOg0KPiA+ID4gPiA+ID4gPiA+IFtEb3RzXSBET1RTIFJlcXVp cmVtZW50cyByZXZpZXcgKC0wNikpDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gT24gMTAvMjMvMTcgODoyOCBBTSwgbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPiA+IEhpIEpv biwgYWxsLA0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IEkgYWdyZWUgd2l0 aCBGbGVtbWluZyB0aGF0ICJzb21lIG1vcmUgd29yayIgaXMgbmVlZGVkLg0KPiA+ID4gPiA+ID4g PiA+ID4gSU1ITywgdGhpcyBpcyBhDQo+ID4gPiA+ID4gPiA+ID4gdHlwaWNhbCBkaXNjdXNzaW9u IHRvIGluY2x1ZGUgaW4gYSBkZWRpY2F0ZWQgc2VjdGlvbiBpbg0KPiA+ID4gPiA+ID4gPiA+IHRo ZSBET1RTIGFyY2hpdGVjdHVyZSBJLUQuDQo+ID4gPiA+ID4gPiA+ID4gQWdyZWVkLg0KPiA+ID4g PiA+ID4gPiA+ID4gPkZyb20gYSByZXF1aXJlbWVudCBzdGFuZHBvaW50LCB3ZSBkb24ndCBuZWVk IHRvDQo+ID4gPiA+ID4gPiA+ID4gPiA+ZWxhYm9yYXRlIGhvdyB0aGUNCj4gPiA+ID4gPiA+ID4g PiBwcm90b2NvbHMgd2lsbCBmdWxmaWwgaXQuIFNJRy0xMCBkb2VzIGV2ZW4gYSBuaWNlIGpvYiBi eQ0KPiA+ID4gPiA+ID4gPiA+IGNpdGluZw0KPiA+ID4gPiA+ID4gPiA+IFJGQzgwODUgd2hpY2gg cG9pbnRzIHRvIE5BVCB0cmF2ZXJzYWwgbWVjaGFuaXNtcy4gT25lDQo+ID4gPiA+ID4gPiA+ID4g Y291bGQgcGljayBoaXMvaGVyIGZhdm9yaXRlIHByb3RvY29sIGZyb20gdGhlIGxpc3QgaW4gODA4 NQ0KPiA+ID4gPiA+ID4gPiA+IHRvIGRpc2NvdmVyIHRoZSBleHRlcm5hbCBJUCBhZGRyZXNzL3By ZWZpeCwgaWYgbmVlZGVkLg0KPiA+ID4gPiA+ID4gPiA+IEV4dGVybmFsIElQIGFkZHJlc3Nlcy9w cmVmaXhlcyBjYW4gYmUgSVB2NCBmb3IgYSBOQVQ0NCBvcg0KPiA+ID4gPiA+ID4gPiA+IE5BVDY0 LCBidXQgY2FuIGJlDQo+ID4gPiA+ID4gPiA+ID4gSVB2NiBwcmVmaXhlcyBmb3IgZW50ZXJwcmlz ZXMgZGVwbG95aW5nIE5QVHY2LCBhbmQgc28gb24uDQo+ID4gPiA+ID4gPiA+ID4gUGFydCBvZiB0 aGUgY2hhbGxlbmdlIGhlcmUgaXMgdGhhdCB0aGUgYXR0YWNrIHRhcmdldCBhbmQNCj4gPiA+ID4g PiA+ID4gPiB0aGUgRE9UUyBjbGllbnQgYXJlIG5vdCBuZWNlc3NhcmlseSBvbmUgYW5kIHRoZSBz YW1lLA0KPiA+ID4gPiA+ID4gPiA+IHdoaWNoIG1ha2VzIGl0IG1vcmUgZGlmZmljdWx0IHRvIGRl dGVybWluZSB0aGUNCj4gPiA+ID4gPiA+ID4gPiBwdWJsaWMtZmFjaW5nIElQLWFkZHJlc3MvcG9y dCB1bmRlciBhdHRhY2sgKGF0IGxlYXN0IGlmDQo+ID4gPiA+ID4gPiA+ID4gdGhlIERPVFMgY2xp ZW50IGlzDQo+ID4gZ29pbmcgdG8NCj4gPiA+IGRvIGl0KS4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+ID4gW01lZF0gVGhpcyBpcyBleGFjdGx5IHRoZSBraW5kIG9mIHRoZSBkaXNjdXNzaW9u IHRvIGhhdmUuDQo+ID4gVGhhbmtzLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBXaXRo IG9yIHdpdGhvdXQgTkFULCBET1RTIGNsaWVudHMgYXJlIGFzc3VtZWQgdG8gYmUgZmVkIHdpdGgN Cj4gPiA+ID4gPiA+ID4gdGhlDQo+ID4gPiA+ID4gPiBpbnRlcm5hbA0KPiA+ID4gPiA+ID4gPiB0 YXJnZXQocykuIFRoaXMgY2FuIGJlIGFjaGlldmVkIGJ5IHByb3Zpc2lvbmluZyAobGlrZWx5KSBv cg0KPiA+ID4gPiA+ID4gPiBieSBkaXNjb3ZlcnkNCj4gPiA+ID4gPiA+IG1lYW5zDQo+ID4gPiA+ ID4gPiA+IChlLmcuLCByZXNpZGVudGlhbCBvciBzbWFsbCBlbnRlcnByaXNlIG5ldHdvcmtzKS4N Cj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gQ2FuIHdlIGFzc3VtZSB0aGF0IHRoZSBkaXNj b3Zlcnkgb2YgdGhlIGV4dGVybmFsIElQDQo+ID4gPiA+ID4gPiA+IGFkZHJlc3MvcHJlZml4Ly4u IGlzDQo+ID4gPiA+ID4gPiBkb25lDQo+ID4gPiA+ID4gPiA+IGJ5IGEgRE9UUyBjbGllbnQgb25s eSBpZiBpdCBpcyBleHBsaWNpdGx5IGluc3RydWN0ZWQgdG8gZG8gc28/DQo+ID4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBJbiBzb21lIGRlcGxveW1lbnRzLCBE T1RTIGNsaWVudHMgbWF5IGJlIHByb3Zpc2lvbmVkDQo+ID4gPiA+ID4gPiA+ID4gPiB3aXRoIHRo ZSBzZXQgb2YNCj4gPiA+ID4gPiA+ID4gPiBpbnRlcm5hbCByZXNvdXJjZXMsIHNvIHRoZXJlIGlz IG5vIG5lZWQgZm9yIGRpc2NvdmVyeS4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ ID4gPiBBbHNvLCBhcyBKb24gbWVudGlvbmVkLCBET1RTIGdhdGV3YXlzIGNhbiBiZSBvZiBoZWxw IHRvDQo+ID4gPiA+ID4gPiA+ID4gPiBzZXQgdGhlDQo+ID4gPiA+ID4gPiA+ID4gYXBwcm9wcmlh dGUgSVAgYWRkcmVzc2VzL3ByZWZpeGVzL3BvcnQgbnVtYmVycyBpbiB0aGUNCj4gPiA+ID4gPiA+ ID4gPiBwcmVzZW5jZSBvZiB0cmFuc2xhdG9ycy4NCj4gPiA+ID4gPiA+ID4gPiBBZ3JlZWQgLSBi dXQgdGhleSBzdGlsbCBuZWVkIGEgd2F5IHRvIGZpZ3VyZSBvdXQgdGhlDQo+ID4gPiA+ID4gPiA+ ID4gcHJpdmF0ZS9wdWJsaWMgbWFwcGluZyBmb3IgYSBnaXZlbiBhdHRhY2sgdGFyZ2V0Lg0KPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBbTWVkXSBCZWNhdXNlIGEgRERvUyBhdHRhY2sgaXMg b2JzZXJ2ZWQgZnJvbSB0aGUgaW50ZXJuYWwNCj4gPiA+ID4gPiA+ID4gbmV0d29yaywNCj4gPiA+ ID4gPiA+ID4gbWFwcGluZyhzKSBhcmUgbmVjZXNzYXJpbHkgbWFpbnRhaW5lZCBieSB0aGUgb24t cGF0aA0KPiA+IHRyYW5zbGF0b3IocykuDQo+ID4gPiA+ID4gPiA+IE90aGVyd2lzZSwgdGhlIGlu Y29taW5nIGF0dGFjayB0cmFmZmljIGNvdWxkbid0IGJlIGZvcndhcmRlZA0KPiA+ID4gPiA+ID4g PiB0byBpbnRlcm5hbA0KPiA+ID4gPiA+ID4gaG9zdHMuDQo+ID4gPiA+ID4gPiA+IFRoaXMgbW9k ZWwgYXNzdW1lcyB0aGF0IHRoZSBnYXRld2F5IGlzIGNvbGxvY2F0ZWQgd2l0aCB0aGUgTkFULg0K PiA+ID4gPiA+ID4gPiBTbywgdGhlIGdhdGV3YXkgY2FuIHJlcGxhY2UgdGhlIGludGVybmFsIElQ IGFkZHJlc3MvcHJlZml4DQo+ID4gPiA+ID4gPiA+IHdpdGggdGhlIG9uZQ0KPiA+ID4gPiA+ID4g cmV0cmlldmVzDQo+ID4gPiA+ID4gPiA+IGZyb20gdGhlIE5BVCBtYXBwaW5nIHRhYmxlLg0KPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBEbyB5b3Ugc2VlIGFueSBpc3N1ZSB3aXRoIHRoaXMg c2NoZW1lPw0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gQW4gb3BlbiBxdWVzdGlv biB0aG91Z2ggd291bGQgYmUgdG8gZGlzY3VzcyBpZiB0aGVyZSBpcw0KPiA+ID4gPiA+ID4gPiA+ ID4gYSB2YWx1ZSBpbg0KPiA+ID4gPiA+ID4gPiA+IGhhdmluZyBhIGZlYXR1cmUgaW4gdGhlIERP VFMgcHJvdG9jb2wgdG8gaW5mb3JtIGEgRE9UUw0KPiA+ID4gPiA+ID4gPiA+IGNsaWVudCB0aGF0 IGEgTkFUIGlzIGRldGVjdGVkIG9uLXBhdGguIFRoaXMgY2FuIGJlDQo+ID4gPiA+ID4gPiA+ID4g cHJlc2VudGVkIGFzIGFuIGluZm9ybWF0aW9uIGVsZW1lbnQgcmV0dXJuZWQgYnkgdGhlIHNlcnZl cg0KPiA+ID4gPiA+ID4gPiA+IHRvIHRoZSBjbGllbnQuIFRoaXMgaW5mb3JtYXRpb24gY2FuIGJl LCBmb3IgZXhhbXBsZSwgdXNlZA0KPiA+ID4gPiA+ID4gPiA+IGJ5IHRoZSBjbGllbnQgdG8gYWRq dXN0IGl0cyBIVCBpbnRlcnZhbCwgYWRqdXN0IHRoZQ0KPiA+ID4gPiA+ID4gPiA+IGludGVybmFs IElQIGFkZHJlc3Nlcy9wcmVmaXhlcyB0bw0KPiA+IGJlDQo+ID4gPiBwcm90ZWN0ZWQsIGV0Yy4N Cj4gPiA+ID4gT3BpbmlvbnM/DQo+ID4gPiA+ID4gPiA+ID4gSXQgc291bmRzIGFwcGVhbGluZywg YnV0IGl0J3MgdmVyeSBkaWZmaWN1bHQgdG8gZG8gdGhpcw0KPiA+ID4gPiA+ID4gPiA+IHJlbGlh Ymx5LCBhbmQgaXQncyBub3QganVzdCBOQVRzIHRoYXQgYXJlIGFuIGlzc3VlIGhlcmU7DQo+ID4g PiA+ID4gPiA+ID4gRmlyZXdhbGxzIHByZXNlbnQgc2ltaWxhciBjaGFsbGVuZ2VzIChhbmQgdGhl eSBtYXkgb3IgbWF5DQo+ID4gPiA+ID4gPiA+ID4gbm90IGJlIE5BVCdpbmcgaW5kaXZpZHVhbA0K PiA+ID4gPiA+IGZsb3dzKS4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPiBbTWVkXSBJIGZ1bGx5IGFncmVlIHRoYXQgZmlyZXdhbGxzIGRldGVjdCBpcyBtb3Jl IGNvbXBsZXguDQo+ID4gPiA+ID4gPiA+IExldCdzIHB1dCBpdA0KPiA+ID4gPiA+ID4gYXNpZGUN Cj4gPiA+ID4gPiA+ID4gYW5kIGZvY3VzIG9uIHRoZSBOQVQgY2FzZS4NCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiBUaGUgcHJlc2VuY2UgYW5kIGJlaGF2aW9yIG9mIE5BVCBhbmQgRmlyZXdhbGws IGFuZCBrZWVwYWxpdmUNCj4gPiA+ID4gPiA+IGludGVydmFsIGNhbiBiZSBkZXRlcm1pbmVkIHVz aW5nIFNUVU4gKGRpc2N1c3NlZCBpbg0KPiA+ID4gPiA+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzU3ODApLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC1UaXJ1DQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBXZSBjYW4gY29uc2lkZXIgbWFueSBh cHByb2FjaGVzIHRvIGRldGVjdCBhIE5BVCwgZS5nLiwNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ID4gKDEpIFRoZSBET1RTIGNsaWVudCBpbnNlcnRzIGluIHRoZSBjb3JlIG1lc3NhZ2UgdGhl IElQDQo+ID4gPiA+ID4gPiA+IGFkZHJlc3MvcG9ydCBpdA0KPiA+ID4gPiA+ID4gdXNlcyB0bw0K PiA+ID4gPiA+ID4gPiBzZW5kIHRoZSByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4gVXBvbiBy ZWNlaXB0IG9mIHRoZQ0KPiA+ID4gPiA+ID4gPiByZXF1ZXN0IGJ5IHRoZSBET1RTIHNlcnZlciwg aXQgY2hlY2tzIGlmIHRoZSBlbmNsb3NlZCBJUA0KPiA+ID4gPiA+ID4gPiBhZGRyZXNzL3BvcnQg bWF0Y2ggdGhlIHNvdXJjZQ0KPiA+ID4gPiA+ID4gSVANCj4gPiA+ID4gPiA+ID4gYWRkcmVzcy9w b3J0IG9mIHRoZSByZWNlaXZlZCBwYWNrZXQuIElmIHllcywgdGhlIHNlcnZlciBzZXRzDQo+ID4g PiA+ID4gPiA+IGluIHRoZQ0KPiA+ID4gPiA+ID4gcmVzcG9uc2UgYQ0KPiA+ID4gPiA+ID4gPiBk ZWRpY2F0ZWQgcGFyYW1ldGVyIHRvIGluZGljYXRlIHRoYXQgYSB0cmFuc2xhdG9yIGlzDQo+ID4g PiA+ID4gPiA+IGRldGVjdGVkDQo+ID4gPiA+ID4gPiA+IG9uLQ0KPiA+ID4gPiBwYXRoLg0KPiA+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAoMikgVGhlIERPVFMgc2VydmVyIGluc2VydHMgc3lz dGVtYXRpY2FsbHkgdGhlIHNvdXJjZSBJUA0KPiA+ID4gPiA+ID4gPiBhZGRyZXNzL3BvcnQgaW4N Cj4gPiA+ID4gPiA+IGENCj4gPiA+ID4gPiA+ID4gcmVzcG9uc2UgdG8gYSBtZXNzYWdlIGZyb20g YSBET1RTIGNsaWVudC4gVXBvbiByZWNlaXB0IG9mDQo+ID4gPiA+ID4gPiA+IHRoYXQgcmVzcG9u c2UsIHRoZSBET1RTIGNsaWVudCBjb21wYXJlcyB0aGUgZW5jbG9zZWQNCj4gPiA+ID4gPiA+ID4g YWRkcmVzcy9wb3J0IHdpdGggdGhlIG9uZXMgaXQgdXNlZA0KPiA+ID4gPiA+ID4gdG8NCj4gPiA+ ID4gPiA+ID4gc2VuZCB0aGUgcmVxdWVzdCB0byBkZXRlY3QgYW55IG1pc21hdGNoLg0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IC0tIEZsZW1taW5nDQo+ID4g PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gQ2hlZXJzLA0K PiA+ID4gPiA+ID4gPiA+ID4gTWVkDQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLSBEZcKgOiBEb3RzDQo+ID4gPiA+ID4gPiA+ ID4gPj4gW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSm9uDQo+ ID4gPiA+ID4gPiA+ID4gPj4gU2hhbGxvdyBFbnZvecOpwqA6IGx1bmRpIDIzIG9jdG9icmUgMjAx NyAxMzoxOCDDgMKgOg0KPiA+ID4gPiA+ID4gPiA+ID4+ICdGbGVtbWluZyBBbmRyZWFzZW4nOyBk b3RzQGlldGYub3JnIE9iamV0wqA6IFJlOiBbRG90c10NCj4gPiA+ID4gPiA+ID4gPiA+PiBET1RT IFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikNCj4gPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ ID4gPiA+ID4+IEhpIEZsZW1taW5nLA0KPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ ID4gPj4gVGhlIHdheSBteSBtaW5kIHdvcmtzIGlzIHRvIHRoaW5rIG9mIGEgcHJhY3RpY2FsDQo+ ID4gPiA+ID4gPiA+ID4gPj4gc2l0dWF0aW9uIGFuZCBzZWUgaWYgdGhpbmdzIGZpdC4NCj4gPiA+ ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4+IEFzIEkgcmVhZCBTSUctMDEwLCB0aGVy ZSBjb3VsZCBiZSBhIERPVFMgY2xpZW50IHdpdGggYQ0KPiA+ID4gPiA+ID4gPiA+ID4+IG1hbmFn ZW1lbnQgSVAgYWRkcmVzcyB0aGF0IGlzIFJGQzE5MTggLSB0aGlzIGNsaWVudA0KPiA+ID4gPiA+ ID4gPiA+ID4+IGNvdWxkIGJlIG1vbml0b3JpbmcgTmV0ZmxvdyBpbmZvcm1hdGlvbiBhbmQgY2Fu IHJlcXVlc3QNCj4gPiA+ID4gPiA+ID4gPiA+PiBtaXRpZ2F0aW9uIGZvciB0aGUgYXBwcm9wcmlh dGUgcHVibGljIElQcw0KPiA+ID4gPiA+ID4gPiA+IHRoYXQNCj4gPiA+ID4gPiA+ID4gPiA+PiBh cmUgYmVpbmcgbW9uaXRvcmVkLiAgU28gU0lHLTAxMCBpcyBuZWVkZWQgZm9yIHRoaXMgdXNlDQo+ ID4gY2FzZS4NCj4gPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4+IEl0IGlzIHRo ZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgRE9UUyBzZXJ2ZXIgYXMgdG8NCj4gPiA+ID4gPiA+ID4g PiA+PiB3aGV0aGVyIGl0IGFjY2VwdHMgYSBtaXRpZ2F0aW9uIHJlcXVlc3QgZm9yIGENCj4gPiA+ ID4gPiA+ID4gPiA+PiBwYXJ0aWN1bGFyIHRhcmdldCBpcCAob3IgZG9tYWluDQo+ID4gPiA+ID4g PiBldGMuKSBvcg0KPiA+ID4gPiA+ID4gPiBub3QuDQo+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ ID4gPiA+ID4gPiA+PiBJZiB0aGVyZSBpcyBnb2luZyB0byBiZSBhIE5BVCBib3JkZXIgd2hlcmUg cHVibGljIElQcw0KPiA+ID4gPiA+ID4gPiA+ID4+IGFyZSBtYXBwZWQgaW50byBwcml2YXRlIElQ cyAoYW5kIHZpY2UgdmVyc2EpLCBJIHdvdWxkDQo+ID4gPiA+ID4gPiA+ID4gPj4gdGhlbiBleHBl Y3QgdGhlcmUgdG8gYmUgYSBET1RTIGdhdGV3YXkgYmV0d2VlbiB0aGVzZSAyDQo+ID4gPiA+ID4g PiA+ID4gPj4gem9uZXMsIGFuZCBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIERPVFMg Z2F0ZXdheQ0KPiA+ID4gPiA+ID4gPiA+ID4+IHRvIGRvIGFueSB0YXJnZXQtaXANCj4gPiA+ID4g bWFwcGluZ3MuDQo+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPiA+PiBSZWdhcmRz DQo+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPiA+PiBKb24NCj4gPiA+ID4gPiA+ ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gPiA+ID4gPiA+ID4gPj4gRnJvbTogRG90cyBbbWFpbHRvOmlldGYtc3VwanBzLWRvdHMtYm91 bmNlc0BpZXRmLm9yZ10NCj4gPiA+ID4gPiA+ID4gPiA+PiBPbiBCZWhhbGYgT2YgRmxlbW1pbmcg QW5kcmVhc2VuDQo+ID4gPiA+ID4gPiA+ID4gPj4gU2VudDogMjIgT2N0b2JlciAyMDE3IDIwOjE3 DQo+ID4gPiA+ID4gPiA+ID4gPj4gVG86IGRvdHM7IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVu dHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4gPiA+PiBTdWJqZWN0OiBbRG90c10gRE9UUyBSZXF1 aXJlbWVudHMgcmV2aWV3ICgtMDYpDQo+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4g PiA+PiBHcmVldGluZ3MNCj4gPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4+IEkg aGF2ZSByZXZpZXdlZCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIERPVFMNCj4gPiA+ID4gPiA+ ID4gPiA+PiByZXF1aXJlbWVudHMgZHJhZnQNCj4gPiA+ID4gPiA+ID4gPiA+PiAoaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0NCj4gPiAwNi50eHQp Lg0KPiA+ID4gPiA+ID4gPiA+ID4+IEluDQo+ID4gPiA+ID4gPiA+ID4gZ2VuZXJhbCwNCj4gPiA+ ID4gPiA+ID4gPiA+PiBJIHRoaW5rIHRoZSBkcmFmdCBpcyBpbiBnb29kIHNoYXBlIHdpdGggb25s eSBhIGZldw0KPiA+ID4gPiA+ID4gPiA+ID4+IGVkaXRzIHJlcXVpcmVkLCBzbyBJIGhvcGUgd2Ug Y2FuIG1vdmUgdG8gV0dMQyBzb29uLiBJDQo+ID4gPiA+ID4gPiA+ID4gPj4gaGF2ZSBhIGZldyBj b21tZW50cyBiZWxvdyAob2Ygd2hpY2gNCj4gPiA+ID4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+ ID4gPiA+PiBOQVQgb25lIGlzIHRoZSBvbmx5IHJlYWwgc3Vic3RhbnRpYWwgb25lKS4gSSBoYXZl IGFsc28NCj4gPiA+ID4gPiA+ID4gPiA+PiBzdWJtaXR0ZWQgYSBwdWxsIHJlcXVlc3Qgd2l0aCBh IGZldyBuaXQgZml4ZXMgb24gR2l0SHViOg0KPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4g PiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPiA+PiBTZWN0aW9uIDEuMg0KPiA+ID4gPiA+ID4gPiA+ ID4+IC0gVGhlIGRlZmluaXRpb24gb2YgIkRPVFMgU2lnbmFsIiBpcyBzbGlnaHRseQ0KPiA+ID4g PiA+ID4gPiA+ID4+IGluY29uc2lzdGVudCB3aXRoIHRoZSByZXNwZWN0aXZlICJDbGllbnQgU2ln bmFsIiBhbmQgIlNlcnZlcg0KPiBTaWduYWwiDQo+ID4gZGVmaW5pdGlvbnMuDQo+ID4gPiA+ID4g PiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPiA+PiBTSUctMDA1Og0KPiA+ID4gPiA+ID4gPiA+ID4+ IC0gTm90IGNsZWFyIHRoYXQgYWx3YXlzIHJlcXVpcmluZyAibnVtYmVyIG9mIHBhY2tldHMiDQo+ ID4gPiA+ID4gPiA+ID4gPj4gbWV0cmljcyBpcyBtZWFuaW5nZnVsLiBDb25zaWRlciBUQ1AtYmFz ZWQgYXR0YWNrcyBmb3INCj4gPiA+ID4gPiA+ID4gPiA+PiBleGFtcGxlLiBOdW1iZXIgb2YgYnl0 ZXMgbWF5IGFsd2F5cyBiZSBvayAtIGFib3ZlIGFuZA0KPiA+ID4gPiA+ID4gPiA+ID4+IGJleW9u ZCB0aGF0IGl0IHNob3VsZCBwcm9iYWJseSBiZSBleHRlbnNpYmxlIGFuZC9vcg0KPiA+ID4gPiA+ ID4gPiA+ID4+IGF0dGFjaw0KPiA+ID4gZGVwZW5kZW50Lg0KPiA+ID4gPiA+ID4gPiA+ID4+IC0g SSBkb24ndCB0aGluayB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50IHNob3VsZCBnZXQNCj4gPiA+ ID4gPiA+ID4gPiA+PiBpbnRvIHNwZWNpZnlpbmcNCj4gPiA+ID4gPiA+ID4gPiB0aW1lcg0KPiA+ ID4gPiA+ID4gPiA+ID4+IHZhbHVlcyAtIGV4cG9udGlhbCBiYWNrb2ZmIHdpdGggc29tZSBtYXhp bXVtIHZhbHVlDQo+ID4gPiA+ID4gPiA+ID4gPj4gc2VlbXMgYWJvdXQgdGhlDQo+ID4gPiA+ID4g PiA+ID4gcmlnaHQNCj4gPiA+ID4gPiA+ID4gPiA+PiBsZXZlbCBvZiBkZXRhaWwgaGVyZS4NCj4g PiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4+IFNJRy0wMDk6DQo+ID4gPiA+ID4g PiA+ID4gPj4gLSBUbyBiZSBjbGVhciwgdGhlIGNvbmZsaWN0cyBvbmx5IGFwcGx5IHdpdGhpbiBh IHNpbmdsZQ0KPiA+ID4gPiA+ID4gPiA+ID4+IGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgcmlnaHQg PyBGb3IgZXhhbXBsZSwgaWYgYSBjbGllbnQNCj4gPiA+ID4gPiA+ID4gPiA+PiB0ZWxscyB0aGUg c2FtZSBkb21haW4gdG8gYWx0ZXJuYXRlbHkgdHVybiBvbi9vZmYNCj4gPiA+ID4gPiA+ID4gPiA+ PiBtaXRpZ2F0aW9uIGZvciBhIGdpdmVuIHByZWZpeCwgcm91dGUgZmxhcHBpbmcNCj4gPiA+ID4g PiA+ID4gPiBtYXkNCj4gPiA+ID4gPiA+ID4gPiA+PiBvY2N1ci4gVGhlIHNhbWUgY29uY2VybiBk b2VzIG5vdCBhcHBseSBpZiBhIGNsaWVudA0KPiA+ID4gPiA+ID4gPiA+ID4+IHRlbGxzIHR3byBk aWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUgZG9tYWlucyB0bw0KPiA+ID4gPiA+ID4gPiA+ID4+IHJl c3BlY3RpdmUgdHVybiBtaXRpZ2F0aW9uIG9uIChkb21haW4gMSkgYW5kDQo+ID4gPiA+ID4gPiA+ ID4gb2ZmDQo+ID4gPiA+ID4gPiA+ID4gPj4gKGRvbWFpbiAyKS4gSWYgc28sIGNhbiB3ZSBjbGFy aWZ5IHRoYXQgKGFsc28gaW4gbGlldSBvZg0KPiA+ID4gPiA+ID4gPiA+ID4+IHNvbWUgb2YgdGhl DQo+ID4gPiA+ID4gPiA+ID4gbXVsdGktDQo+ID4gPiA+ID4gPiA+ID4gPj4gaG9taW5nIGNvbW1l bnRzIHJhaXNlZCBwcmV2aW91c2x5KSA/DQo+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ ID4gPiA+PiBTSUctMDEwOg0KPiA+ID4gPiA+ID4gPiA+ID4+IC0gRE9UUyBDbGllbnQgYmVoaW5k IE5BVC4gT24gb25lIGhhbmQsIGl0IHNlZW1zDQo+ID4gPiA+ID4gPiA+ID4gPj4gcmVhc29uYWJs ZSB0byBoYXZlIHRoaXMgcmVxdWlyZW1lbnQgc2luY2UgY2xpZW50cyBmb3INCj4gPiA+ID4gPiA+ ID4gPiA+PiBzdXJlIGNhbiBiZSBiZWhpbmQgTkFUcywgYW5kDQo+ID4gPiA+ID4gPiB3aXRoDQo+ ID4gPiA+ID4gPiA+IHRoaW5ncw0KPiA+ID4gPiA+ID4gPiA+ID4+IGxpa2UgZHluYW1pYyBETlMs IHRoZXkgY2FuICAgICBjZXJ0YWlubHkgYmUgcmVhY2hhYmxlLg0KPiA+IEhvd2V2ZXIsDQo+ID4g PiA+IGlmDQo+ID4gPiA+ID4gPiB3ZQ0KPiA+ID4gPiA+ID4gPiA+IGRvDQo+ID4gPiA+ID4gPiA+ ID4gPj4gd2FudCB0byBhbGxvdyBmb3IgdGhpcyBzY2VuYXJpbywgYW5kIGluIHBhcnRpY3VsYXIg Zm9yDQo+ID4gPiA+ID4gPiA+ID4gPj4gdGhlIERPVFMgY2xpZW50DQo+ID4gPiA+ID4gPiA+ID4g dG8NCj4gPiA+ID4gPiA+ID4gPiA+PiBoYXZlIGEgcHJpdmF0ZSBJUC1hZGRyZXNzIChwb3RlbnRp YWxseSBiZWhpbmQgbXVsdGlwbGUNCj4gPiA+ID4gPiA+ID4gPiA+PiBOQVRzKSwgdGhlbiB3ZQ0K PiA+ID4gPiA+ID4gPiA+IGhhdmUNCj4gPiA+ID4gPiA+ID4gPiA+PiBtb3JlIHdvcmsgdG8gZG8g YmVjYXVzZSBpdCB3b24ndCBkbyB0aGUgRE9UUyBzZXJ2ZXIgYW55DQo+ID4gPiA+ID4gPiA+ID4g Pj4gZ29vZCB0byBnZXQgYSBtaXRpZ2F0aW9uIHJlcXVlc3QgcmVmZXJyaW5nIHRvIHRoYXQNCj4g PiA+ID4gPiA+ID4gPiA+PiBwcml2YXRlIElQLWFkZHJlc3MgKG9yDQo+ID4gPiA+ID4gPiBwcmVm aXgpLg0KPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ ID4gPiA+PiBUaGFua3MNCj4gPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4+IC0t IEZsZW1taW5nDQo+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPiA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gPiA+ ID4+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gPiA+ID4gPj4gRG90c0BpZXRmLm9yZw0K PiA+ID4gPiA+ID4gPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG90cw0KPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4gPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ID4gPiA+PiBE b3RzIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+ID4gPiA+ID4+IERvdHNAaWV0Zi5vcmcNCj4gPiA+ ID4gPiA+ID4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMN Cj4gPiA+ID4gPiA+ID4gPiA+IC4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gPiA+ID4gPiA+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gPiA+IERvdHNA aWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kb3RzDQo= From nobody Thu Oct 26 06:13:15 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A15137A70 for ; Thu, 26 Oct 2017 06:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-SG3daGBImz for ; Thu, 26 Oct 2017 06:13:10 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0274913F4A9 for ; Thu, 26 Oct 2017 06:13:10 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.176) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 26 Oct 2017 09:13:08 -0400 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 26 Oct 2017 09:13:08 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "Konda, Tirumaleswar Reddy" , Flemming Andreasen , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAO8GKAACQhAQAAYkTigAABViKAAAB+EIAAAH6pgAAEb54AAAfog1AADcdhsP//Lswy///9vXD///ihsA== Date: Thu, 26 Oct 2017 13:13:07 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> , <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.245.35.5] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:13:14 -0000 I'm not pushing for this. I saw the working group struggling with the firew= all/NAT problem, and offered a different way of thinking about it. To be clear, my suggestion is to remove unsolicited messages from the serve= r to client. -Dave -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Thursday, October 26, 2017 3:06 PM To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon Shallow= ; dots@ietf.org Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Re-, Not sure how to get rid of the constraint imposed by the NAT/FW timer, Dave= .=20 The current text says the following:=20 To provide a metric of signal health and distinguish an 'idle' signal channel from a 'disconnected' or 'defunct' session, the DOTS agent sends a heartbeat over the signal channel to maintain its half of the channel. The DOTS agent similarly expects a heartbeat from its peer DOTS agent, and may consider a session terminated in the extended absence of a peer agent heartbeat. Which covers your proposal. No?=20 Solicited messages from the server do not prevent from failures. Consider t= he case where a DOTS server has to send a mitigation status update back to = the client, but the client didn't refreshed the state. Or when the NAT fire= d out a mapping and assigns the external port to another host than the DOTS= client.=20 Did I missed something? Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9=A0: jeudi 26=20 > octobre 2017 14:50 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar= =20 > Reddy; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet=A0: Re:=20 > [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >=20 > My point was that if server status was solicited, keep-alive interval=20 > would be independent of firewall/NAT timeout. Keep-alives would be=20 > optional. >=20 > Solicited means that client says "get status" vs. the server just=20 > sending updates. >=20 >=20 >=20 > David Dolson > Sandvine > Original Message > From: mohamed.boucadair@orange.com > Sent: Thursday, October 26, 2017 2:11 PM > To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon=20 > Shallow; dots@ietf.org > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review=20 > (-06)) >=20 >=20 > Hi Dave, >=20 > The protocol does already support a mechanism to send keepalive=20 > messages every 30s (recommended value). >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 26=20 > > octobre 2017 13:15 =C0 : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed=20 > > IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : RE:=20 > > [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > > I think there is another option to handle the NAT/firewall problems=20 > > by changing the protocol. > > > > If I understand correctly, currently the NAT and firewall need to be > kept > > open to permit unsolicited server packets. > > > > If the protocol is changed to require client polling of the server=20 > > updates, the NAT and firewall problems go away. > > > > -Dave > > > > > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar > > Reddy > > Sent: Thursday, October 26, 2017 12:58 PM > > To: mohamed.boucadair@orange.com; Flemming Andreasen; Jon Shallow;=20 > > dots@ietf.org > > Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review=20 > > (-06)) > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com=20 > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Thursday, October 26, 2017 2:21 PM > > > To: Konda, Tirumaleswar Reddy=20 > > > ; > > > Flemming Andreasen ; Jon Shallow > > ietf@jpshallow.com>; dots@ietf.org > > > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review > > > (-06)) > > > > > > Re-, > > > > > > I hear you. My take is that we don't need to recommend which=20 > > > companion "protocols/mechanisms" need to be supported for NAT/FW=20 > > > traversal purposes. Having a discussion at the same level in 8085=20 > > > would be sufficient, IMHO. > > > > > > Let's focus on the simple built-in feature for NAT detect. > > > > I don't think the simple built-in feature is sufficient, DOTS client > will > > have to rely on mechanisms discussed in 8085 for both firewall and=20 > > NAT traversal. > > > > -Tiru > > > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9 : jeudi 26 octobre 2017 10:36 =C0 : BOUCADAIR Mohamed=20 > > > > IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet :=20 > > > > RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > > > > > > But NATs are not the only problem, firewalls will also be most=20 > > > > likely present, and STUN helps discover both NATs and firewalls=20 > > > > and useful even in IPv6 networks to determine the keepalive=20 > > > > interval of > > firewall. > > > > > > > > -Tiru > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucadair@orange.com=20 > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > Sent: Thursday, October 26, 2017 1:52 PM > > > > > To: Konda, Tirumaleswar Reddy > > > ; > > > > > Flemming Andreasen ; Jon Shallow > > > > ietf@jpshallow.com>; dots@ietf.org > > > > > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements=20 > > > > > review > > > > > (-06)) > > > > > > > > > > Tiru, > > > > > > > > > > Yes, STUN can be listed as part of the existing tools box=20 > > > > > (among the > > > > lines of > > > > > what is already discussed in 8085). > > > > > > > > > > I don't think that it makes sense to require STUN support by=20 > > > > > DOTS > > > > clients. > > > > > > > > > > The proposal is to include a simple built-in feature in the=20 > > > > > DOTS > > > > protocol itself > > > > > that can help to detect NATs. The support of such feature=20 > > > > > will, e.g., > > > > ease > > > > > troubleshooting when connectivity problems are experienced on=20 > > > > > the path between a client and a server. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Konda, Tirumaleswar Reddy=20 > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9 : jeudi 26 octobre 2017 09:44 =C0 : BOUCADAIR Mohamed= =20 > > > > > > IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : > > > > > > RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review=20 > > > > > > (-06)) > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of=20 > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: Tuesday, October 24, 2017 2:20 PM > > > > > > > To: Flemming Andreasen ; Jon Shallow > > > > > > > ; dots@ietf.org > > > > > > > Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements=20 > > > > > > > review > > > > > > > (-06)) > > > > > > > > > > > > > > Hi Flemming, all, > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De : Flemming Andreasen=20 > > > > > > > > [mailto:fandreas@cisco.com] Envoy=E9 : > > > > > > > > lundi > > > > > > > > 23 octobre 2017 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon= =20 > > > > > > > > Shallow; dots@ietf.org Objet : Re: DOTS & NAT (was RE: > > > > > > > > [Dots] DOTS Requirements review (-06)) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/23/17 8:28 AM, mohamed.boucadair@orange.com wrote: > > > > > > > > > Hi Jon, all, > > > > > > > > > > > > > > > > > > I agree with Flemming that "some more work" is needed. > > > > > > > > > IMHO, this is a > > > > > > > > typical discussion to include in a dedicated section in=20 > > > > > > > > the DOTS architecture I-D. > > > > > > > > Agreed. > > > > > > > > > >From a requirement standpoint, we don't need to=20 > > > > > > > > > >elaborate how the > > > > > > > > protocols will fulfil it. SIG-10 does even a nice job by=20 > > > > > > > > citing > > > > > > > > RFC8085 which points to NAT traversal mechanisms. One=20 > > > > > > > > could pick his/her favorite protocol from the list in=20 > > > > > > > > 8085 to discover the external IP address/prefix, if=20 > > > > > > > > needed. External IP addresses/prefixes can be IPv4 for a=20 > > > > > > > > NAT44 or NAT64, but can be > > > > > > > > IPv6 prefixes for enterprises deploying NPTv6, and so on. > > > > > > > > Part of the challenge here is that the attack target and=20 > > > > > > > > the DOTS client are not necessarily one and the same,=20 > > > > > > > > which makes it more difficult to determine the=20 > > > > > > > > public-facing IP-address/port under attack (at least if=20 > > > > > > > > the DOTS client is going to > > > do it). > > > > > > > > > > > > > > [Med] This is exactly the kind of the discussion to have. > > Thanks. > > > > > > > > > > > > > > With or without NAT, DOTS clients are assumed to be fed=20 > > > > > > > with the > > > > > > internal > > > > > > > target(s). This can be achieved by provisioning (likely)=20 > > > > > > > or by discovery > > > > > > means > > > > > > > (e.g., residential or small enterprise networks). > > > > > > > > > > > > > > Can we assume that the discovery of the external IP=20 > > > > > > > address/prefix/.. is > > > > > > done > > > > > > > by a DOTS client only if it is explicitly instructed to do so= ? > > > > > > > > > > > > > > > > > > > > > > > In some deployments, DOTS clients may be provisioned=20 > > > > > > > > > with the set of > > > > > > > > internal resources, so there is no need for discovery. > > > > > > > > > > > > > > > > > > Also, as Jon mentioned, DOTS gateways can be of help=20 > > > > > > > > > to set the > > > > > > > > appropriate IP addresses/prefixes/port numbers in the=20 > > > > > > > > presence of translators. > > > > > > > > Agreed - but they still need a way to figure out the=20 > > > > > > > > private/public mapping for a given attack target. > > > > > > > > > > > > > > [Med] Because a DDoS attack is observed from the internal=20 > > > > > > > network, > > > > > > > mapping(s) are necessarily maintained by the on-path > > translator(s). > > > > > > > Otherwise, the incoming attack traffic couldn't be=20 > > > > > > > forwarded to internal > > > > > > hosts. > > > > > > > This model assumes that the gateway is collocated with the > NAT. > > > > > > > So, the gateway can replace the internal IP address/prefix=20 > > > > > > > with the one > > > > > > retrieves > > > > > > > from the NAT mapping table. > > > > > > > > > > > > > > Do you see any issue with this scheme? > > > > > > > > > > > > > > > > An open question though would be to discuss if there=20 > > > > > > > > > is a value in > > > > > > > > having a feature in the DOTS protocol to inform a DOTS=20 > > > > > > > > client that a NAT is detected on-path. This can be=20 > > > > > > > > presented as an information element returned by the=20 > > > > > > > > server to the client. This information can be, for=20 > > > > > > > > example, used by the client to adjust its HT interval,=20 > > > > > > > > adjust the internal IP addresses/prefixes to be > > > protected, etc. > > > > Opinions? > > > > > > > > It sounds appealing, but it's very difficult to do this=20 > > > > > > > > reliably, and it's not just NATs that are an issue here;=20 > > > > > > > > Firewalls present similar challenges (and they may or=20 > > > > > > > > may not be NAT'ing individual > > > > > flows). > > > > > > > > > > > > > > > > > > > > > > [Med] I fully agree that firewalls detect is more complex. > > > > > > > Let's put it > > > > > > aside > > > > > > > and focus on the NAT case. > > > > > > > > > > > > The presence and behavior of NAT and Firewall, and keepalive=20 > > > > > > interval can be determined using STUN (discussed in=20 > > > > > > https://tools.ietf.org/html/rfc5780). > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > We can consider many approaches to detect a NAT, e.g., > > > > > > > > > > > > > > (1) The DOTS client inserts in the core message the IP=20 > > > > > > > address/port it > > > > > > uses to > > > > > > > send the request to the DOTS server. Upon receipt of the=20 > > > > > > > request by the DOTS server, it checks if the enclosed IP=20 > > > > > > > address/port match the source > > > > > > IP > > > > > > > address/port of the received packet. If yes, the server=20 > > > > > > > sets in the > > > > > > response a > > > > > > > dedicated parameter to indicate that a translator is=20 > > > > > > > detected > > > > > > > on- > > > > path. > > > > > > > > > > > > > > (2) The DOTS server inserts systematically the source IP=20 > > > > > > > address/port in > > > > > > a > > > > > > > response to a message from a DOTS client. Upon receipt of=20 > > > > > > > that response, the DOTS client compares the enclosed=20 > > > > > > > address/port with the ones it used > > > > > > to > > > > > > > send the request to detect any mismatch. > > > > > > > > > > > > > > > > > > > > > > -- Flemming > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Med > > > > > > > > > > > > > > > > > >> -----Message d'origine----- De : Dots=20 > > > > > > > > >> [mailto:dots-bounces@ietf.org] De la part de Jon=20 > > > > > > > > >> Shallow Envoy=E9 : lundi 23 octobre 2017 13:18 =C0 :=20 > > > > > > > > >> 'Flemming Andreasen'; dots@ietf.org Objet : Re:=20 > > > > > > > > >> [Dots] DOTS Requirements review (-06) > > > > > > > > >> > > > > > > > > >> Hi Flemming, > > > > > > > > >> > > > > > > > > >> The way my mind works is to think of a practical=20 > > > > > > > > >> situation and see if things fit. > > > > > > > > >> > > > > > > > > >> As I read SIG-010, there could be a DOTS client with=20 > > > > > > > > >> a management IP address that is RFC1918 - this client=20 > > > > > > > > >> could be monitoring Netflow information and can=20 > > > > > > > > >> request mitigation for the appropriate public IPs > > > > > > > > that > > > > > > > > >> are being monitored. So SIG-010 is needed for this=20 > > > > > > > > >> use > > case. > > > > > > > > >> > > > > > > > > >> It is the responsibility of the DOTS server as to=20 > > > > > > > > >> whether it accepts a mitigation request for a=20 > > > > > > > > >> particular target ip (or domain > > > > > > etc.) or > > > > > > > not. > > > > > > > > >> > > > > > > > > >> If there is going to be a NAT border where public IPs=20 > > > > > > > > >> are mapped into private IPs (and vice versa), I would=20 > > > > > > > > >> then expect there to be a DOTS gateway between these=20 > > > > > > > > >> 2 zones, and it is the responsibility of the DOTS=20 > > > > > > > > >> gateway to do any target-ip > > > > mappings. > > > > > > > > >> > > > > > > > > >> Regards > > > > > > > > >> > > > > > > > > >> Jon > > > > > > > > >> > > > > > > > > >> -----Original Message----- > > > > > > > > >> From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org]=20 > > > > > > > > >> On Behalf Of Flemming Andreasen > > > > > > > > >> Sent: 22 October 2017 20:17 > > > > > > > > >> To: dots; draft-ietf-dots-requirements@ietf.org > > > > > > > > >> Subject: [Dots] DOTS Requirements review (-06) > > > > > > > > >> > > > > > > > > >> Greetings > > > > > > > > >> > > > > > > > > >> I have reviewed the latest version of the DOTS=20 > > > > > > > > >> requirements draft > > > > > > > > >> (https://www.ietf.org/id/draft-ietf-dots-requirements > > > > > > > > >> - > > 06.txt). > > > > > > > > >> In > > > > > > > > general, > > > > > > > > >> I think the draft is in good shape with only a few=20 > > > > > > > > >> edits required, so I hope we can move to WGLC soon. I=20 > > > > > > > > >> have a few comments below (of which > > > > > > > > the > > > > > > > > >> NAT one is the only real substantial one). I have=20 > > > > > > > > >> also submitted a pull request with a few nit fixes on Gi= tHub: > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> Section 1.2 > > > > > > > > >> - The definition of "DOTS Signal" is slightly=20 > > > > > > > > >> inconsistent with the respective "Client Signal" and > > "Server Signal" definitions. > > > > > > > > >> > > > > > > > > >> SIG-005: > > > > > > > > >> - Not clear that always requiring "number of packets" > > > > > > > > >> metrics is meaningful. Consider TCP-based attacks for=20 > > > > > > > > >> example. Number of bytes may always be ok - above and=20 > > > > > > > > >> beyond that it should probably be extensible and/or=20 > > > > > > > > >> attack > > > dependent. > > > > > > > > >> - I don't think the requirements document should get=20 > > > > > > > > >> into specifying > > > > > > > > timer > > > > > > > > >> values - expontial backoff with some maximum value=20 > > > > > > > > >> seems about the > > > > > > > > right > > > > > > > > >> level of detail here. > > > > > > > > >> > > > > > > > > >> SIG-009: > > > > > > > > >> - To be clear, the conflicts only apply within a=20 > > > > > > > > >> single administrative domain, right ? For example, if=20 > > > > > > > > >> a client tells the same domain to alternately turn=20 > > > > > > > > >> on/off mitigation for a given prefix, route flapping > > > > > > > > may > > > > > > > > >> occur. The same concern does not apply if a client=20 > > > > > > > > >> tells two different administrative domains to=20 > > > > > > > > >> respective turn mitigation on (domain 1) and > > > > > > > > off > > > > > > > > >> (domain 2). If so, can we clarify that (also in lieu=20 > > > > > > > > >> of some of the > > > > > > > > multi- > > > > > > > > >> homing comments raised previously) ? > > > > > > > > >> > > > > > > > > >> SIG-010: > > > > > > > > >> - DOTS Client behind NAT. On one hand, it seems=20 > > > > > > > > >> reasonable to have this requirement since clients for=20 > > > > > > > > >> sure can be behind NATs, and > > > > > > with > > > > > > > things > > > > > > > > >> like dynamic DNS, they can certainly be reachable. > > However, > > > > if > > > > > > we > > > > > > > > do > > > > > > > > >> want to allow for this scenario, and in particular=20 > > > > > > > > >> for the DOTS client > > > > > > > > to > > > > > > > > >> have a private IP-address (potentially behind=20 > > > > > > > > >> multiple NATs), then we > > > > > > > > have > > > > > > > > >> more work to do because it won't do the DOTS server=20 > > > > > > > > >> any good to get a mitigation request referring to=20 > > > > > > > > >> that private IP-address (or > > > > > > prefix). > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> Thanks > > > > > > > > >> > > > > > > > > >> -- Flemming > > > > > > > > >> > > > > > > > > >> _______________________________________________ > > > > > > > > >> Dots mailing list > > > > > > > > >> Dots@ietf.org > > > > > > > > >> https://www.ietf.org/mailman/listinfo/dots > > > > > > > > >> > > > > > > > > >> _______________________________________________ > > > > > > > > >> Dots mailing list > > > > > > > > >> Dots@ietf.org > > > > > > > > >> https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Oct 26 06:32:04 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569A113F5A2 for ; Thu, 26 Oct 2017 06:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3cXZphtyNyf for ; Thu, 26 Oct 2017 06:31:57 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0509A13F59F for ; Thu, 26 Oct 2017 06:31:56 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id B63CF101036; Thu, 26 Oct 2017 15:31:54 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 9691118006A; Thu, 26 Oct 2017 15:31:54 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0361.001; Thu, 26 Oct 2017 15:31:54 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Flemming Andreasen" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAGjp6AACQhAAAAYgT5UAABUQNgAACCGwAAAIl5gAAA3jTgAAYVpgAAAg5UIAAA0A0Q Date: Thu, 26 Oct 2017 13:31:53 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05E93B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E858@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:32:00 -0000 UmUtLA0KDQpHbGFkIHRvIHNlZSB0aGF0IHdlIGFyZSBpbiBhZ3JlZW1lbnQgdGhhdCBhbGwgdGhp cyBpcyBhYm91dCBvcHRpbWl6YXRpb25zLiANCg0KQmFjayB0byB0aGUgaW5pdGlhbCBwcm9wb3Nh bCwgaXMgdGhlcmUgYW55IHByb2JsZW0gaWYgd2Ugc3VwcG9ydCBhbiBvcHRpb25hbCBmZWF0dXJl IGluIHRoZSBwcm90b2NvbCB0byBkZXRlY3Qgb24tcGF0aCB0cmFuc2xhdG9ycz8gV291bGRuJ3Qg dGhlIGJlIGhlbHBmdWwgdG8gdHJvdWJsZXNob290IHdoZW4gc29tZSBjb25uZWN0aXZpdHkgYXJl IGV4cGVyaWVuY2VkPyANCg0KQXMgYSByZW1pbmRlciwgdGhlIHByb3Bvc2FsIGlzIGFzIGZvbGxv d3M6DQotIGluY2x1ZGUgdGhlIGlwLWFkZHJlc3MvcG9ydCB1c2VkIGJ5IHRoZSBET1RTIGFnZW50 IHdoZW4gc2VuZGluZyB0aGUgcmVxdWVzdA0KLSBpZiB0aGF0IGluZm9ybWF0aW9uIGlzIHByZXNl bnQgaW4gdGhlIHJlcXVlc3QsIHRoZSBzZXJ2ZXIgaW5jbHVkZXMgdGhlIHNvdXJjZSBJUCBhZGRy ZXNzL3BvcnQgaW4gdGhlIHJlc3BvbnNlLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSBbbWFp bHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb21dDQo+IEVudm95w6nCoDogamV1 ZGkgMjYgb2N0b2JyZSAyMDE3IDE1OjEyDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9P TE47IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7DQo+IGRvdHNAaWV0Zi5vcmcNCj4g T2JqZXTCoDogUkU6IFtEb3RzXSBET1RTICYgTkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRz IHJldmlldyAoLTA2KSkNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBG cm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4gW21haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tXQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3 IDU6MzkgUE0NCj4gPiBUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2Fy UmVkZHlfS29uZGFATWNBZmVlLmNvbT47DQo+ID4gRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVh c0BjaXNjby5jb20+OyBKb24gU2hhbGxvdyA8c3VwanBzLQ0KPiA+IGlldGZAanBzaGFsbG93LmNv bT47IGRvdHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgJiBOQVQgKHdh cyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKQ0KPiA+DQo+ID4gUmUtLA0KPiA+ DQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4N Cj4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gRGXCoDogS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeQ0KPiA+ID4gW21haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBN Y0FmZWUuY29tXQ0KPiA+ID4gRW52b3nDqcKgOiBqZXVkaSAyNiBvY3RvYnJlIDIwMTcgMTI6NTgN Cj4gPiA+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEZsZW1taW5nIEFuZHJlYXNl bjsgSm9uIFNoYWxsb3c7DQo+ID4gPiBkb3RzQGlldGYub3JnIE9iamV0wqA6IFJFOiBbRG90c10g RE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cw0KPiA+ID4gcmV2aWV3ICgtMDYp KQ0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJv bTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+ID4gPiBbbWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb21dDQo+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2 LCAyMDE3IDI6MjEgUE0NCj4gPiA+ID4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4g PiA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47DQo+ID4gPiA+IEZsZW1taW5n IEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPjsgSm9uIFNoYWxsb3cgPHN1cGpwcy0NCj4g PiA+ID4gaWV0ZkBqcHNoYWxsb3cuY29tPjsgZG90c0BpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0 OiBSRTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3 DQo+ID4gPiA+ICgtMDYpKQ0KPiA+ID4gPg0KPiA+ID4gPiBSZS0sDQo+ID4gPiA+DQo+ID4gPiA+ IEkgaGVhciB5b3UuIE15IHRha2UgaXMgdGhhdCB3ZSBkb24ndCBuZWVkIHRvIHJlY29tbWVuZCB3 aGljaA0KPiA+ID4gPiBjb21wYW5pb24gInByb3RvY29scy9tZWNoYW5pc21zIiBuZWVkIHRvIGJl IHN1cHBvcnRlZCBmb3IgTkFUL0ZXDQo+ID4gPiA+IHRyYXZlcnNhbCBwdXJwb3Nlcy4gSGF2aW5n IGEgZGlzY3Vzc2lvbiBhdCB0aGUgc2FtZSBsZXZlbCBpbiA4MDg1DQo+ID4gPiA+IHdvdWxkIGJl DQo+ID4gPiBzdWZmaWNpZW50LA0KPiA+ID4gPiBJTUhPLg0KPiA+ID4gPg0KPiA+ID4gPiBMZXQn cyBmb2N1cyBvbiB0aGUgc2ltcGxlIGJ1aWx0LWluIGZlYXR1cmUgZm9yIE5BVCBkZXRlY3QuDQo+ ID4gPg0KPiA+ID4gSSBkb27igJl0IHRoaW5rIHRoZSBzaW1wbGUgYnVpbHQtaW4gZmVhdHVyZSBp cyBzdWZmaWNpZW50LA0KPiA+DQo+ID4gW01lZF0gSXQgZGVwZW5kcyBmb3Igd2hhdCBwdXJwb3Nl LiBGb3IgZXhhbXBsZSwgdGhlIGJ1aWx0LWluIGZlYXR1cmUNCj4gd2lsbA0KPiA+IGhlbHAgdHJv dWJsZXNob290aW5nIHdoZW4gcHJvYmxlbXMgYXJlIGV4cGVyaWVuY2VkIHRvIGRlbGl2ZXIgRE9U Uw0KPiA+IG1lc3NhZ2VzIGluIHRoZSBwcmVzZW5jZSBvZiBOQVRzLg0KPiANCj4gTkFUcyB3aWxs IG5vdCBjYXVzZSBhbnkgc3BlY2lmaWMgcHJvYmxlbSBmb3IganVzdCB0aGUgRE9UUyBzaWduYWwg Y2hhbm5lbA0KPiBwcm90b2NvbC4NCj4gSW4gdGhlIHByZXNlbmNlIG9mICBOQVQsIERPVFMgd2ls bCBmYWNlIHRoZSBzYW1lIHByb2JsZW1zIGFzIGFueSBvdGhlcg0KPiBwcm90b2NvbCBsaWtlIFFV SUMsIENvQVAgZXRjLiBydW5uaW5nIG92ZXIgVURQLg0KPiANCj4gPg0KPiA+ICBET1RTIGNsaWVu dCB3aWxsDQo+ID4gPiBoYXZlIHRvIHJlbHkgb24gbWVjaGFuaXNtcyBkaXNjdXNzZWQgaW4gODA4 NSBmb3IgYm90aCBmaXJld2FsbCBhbmQgTkFUDQo+ID4gPiB0cmF2ZXJzYWwuDQo+ID4NCj4gPiBb TWVkXSBJJ20gbm90IHN1cmUuIEFjdHVhbGx5LCBpdCBkZXBlbmRzIHdoZXRoZXIgd2Ugd2FudCB0 byAqKiBvcHRpbWl6ZQ0KPiAqKg0KPiA+IHRoZSBrZWVwYWxpdmUgbWVzc2FnZXMgYW5kIGF2b2lk IG92ZXJsb2FkaW5nIHRoZSBuZXR3b3JrLiBIYXZpbmcgYQ0KPiA+IE5BVC9GVyB0cmF2ZXJzYWwg cHJvdG9jb2wgdGhhdCBhbGxvd3MgdG8gbGVhcm4gdGhlIE5BVC9GVyB2YWxpZGl0eQ0KPiBsaWZl dGltZQ0KPiA+IHdpbGwgYWxsb3cgdG8gYWRqdXN0IHRoZSBrZWVwIGFsaXZlIGludGVydmFsLiBU aGF0J3Mgb25seSBhbg0KPiBvcHRpbWl6YXRpb24uDQo+IA0KPiBZZXMsIHRoZXNlIG1lY2hhbmlz bXMgb25seSBoZWxwIHRvIG9wdGltaXplIHRoZSBrZWVwLWFsaXZlIGludGVydmFsLg0KPiANCj4g LVRpcnUNCj4gDQo+ID4NCj4gPiA+DQo+ID4gPiAtVGlydQ0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ ID4gQ2hlZXJzLA0KPiA+ID4gPiBNZWQNCj4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS0NCj4gPiA+ID4gPiBEZcKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5 DQo+ID4gPiA+ID4gW21haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0K PiA+ID4gPiA+IEVudm95w6nCoDogamV1ZGkgMjYgb2N0b2JyZSAyMDE3IDEwOjM2IMOAwqA6IEJP VUNBREFJUiBNb2hhbWVkDQo+ID4gPiA+ID4gSU1UL09MTjsgRmxlbW1pbmcgQW5kcmVhc2VuOyBK b24gU2hhbGxvdzsgZG90c0BpZXRmLm9yZyBPYmpldMKgOg0KPiA+ID4gPiA+IFJFOiBbRG90c10g RE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBCdXQgTkFUcyBhcmUgbm90IHRoZSBvbmx5IHByb2JsZW0sIGZpcmV3 YWxscyB3aWxsIGFsc28gYmUgbW9zdA0KPiA+ID4gPiA+IGxpa2VseSBwcmVzZW50LCBhbmQgU1RV TiBoZWxwcyBkaXNjb3ZlciBib3RoIE5BVHMgYW5kIGZpcmV3YWxscw0KPiA+ID4gPiA+IGFuZCB1 c2VmdWwgZXZlbiBpbiBJUHY2IG5ldHdvcmtzIHRvIGRldGVybWluZSB0aGUga2VlcGFsaXZlDQo+ IGludGVydmFsIG9mDQo+ID4gZmlyZXdhbGwuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAtVGlydQ0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g PiA+ID4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+ID4gPiA+ID4gW21h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPiA+ID4gPiA+ID4gU2VudDogVGh1 cnNkYXksIE9jdG9iZXIgMjYsIDIwMTcgMTo1MiBQTQ0KPiA+ID4gPiA+ID4gVG86IEtvbmRhLCBU aXJ1bWFsZXN3YXIgUmVkZHkNCj4gPiA+ID4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZl ZS5jb20+Ow0KPiA+ID4gPiA+ID4gRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0BjaXNjby5j b20+OyBKb24gU2hhbGxvdyA8c3VwanBzLQ0KPiA+ID4gPiA+ID4gaWV0ZkBqcHNoYWxsb3cuY29t PjsgZG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gU3ViamVjdDogUkU6IFtEb3RzXSBET1RTICYg TkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJldmlldw0KPiA+ID4gPiA+ID4gKC0wNikp DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVGlydSwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiBZZXMsIFNUVU4gY2FuIGJlIGxpc3RlZCBhcyBwYXJ0IG9mIHRoZSBleGlzdGluZyB0b29scyBi b3ggKGFtb25nDQo+ID4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiBsaW5lcyBvZg0KPiA+ID4gPiA+ ID4gd2hhdCBpcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiA4MDg1KS4NCj4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiBJIGRvbid0IHRoaW5rIHRoYXQgaXQgbWFrZXMgc2Vuc2UgdG8gcmVxdWlyZSBTVFVO IHN1cHBvcnQgYnkNCj4gPiA+ID4gPiA+IERPVFMNCj4gPiA+ID4gPiBjbGllbnRzLg0KPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+IFRoZSBwcm9wb3NhbCBpcyB0byBpbmNsdWRlIGEgc2ltcGxlIGJ1 aWx0LWluIGZlYXR1cmUgaW4gdGhlIERPVFMNCj4gPiA+ID4gPiBwcm90b2NvbCBpdHNlbGYNCj4g PiA+ID4gPiA+IHRoYXQgY2FuIGhlbHAgdG8gZGV0ZWN0IE5BVHMuIFRoZSBzdXBwb3J0IG9mIHN1 Y2ggZmVhdHVyZSB3aWxsLA0KPiA+ID4gPiA+ID4gZS5nLiwNCj4gPiA+ID4gPiBlYXNlDQo+ID4g PiA+ID4gPiB0cm91Ymxlc2hvb3Rpbmcgd2hlbiBjb25uZWN0aXZpdHkgcHJvYmxlbXMgYXJlIGV4 cGVyaWVuY2VkIG9uDQo+ID4gPiA+ID4gPiB0aGUgcGF0aCBiZXR3ZWVuIGEgY2xpZW50IGFuZCBh IHNlcnZlci4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+ID4gPiBN ZWQNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiA+ID4gPiA+ID4gPiBEZcKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+ID4gPiA+ ID4gPiA+IFttYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0NCj4gPiA+ ID4gPiA+ID4gRW52b3nDqcKgOiBqZXVkaSAyNiBvY3RvYnJlIDIwMTcgMDk6NDQgw4DCoDogQk9V Q0FEQUlSIE1vaGFtZWQNCj4gPiA+ID4gPiA+ID4gSU1UL09MTjsgRmxlbW1pbmcgQW5kcmVhc2Vu OyBKb24gU2hhbGxvdzsgZG90c0BpZXRmLm9yZw0KPiBPYmpldMKgOg0KPiA+ID4gPiA+ID4gPiBS RTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgt MDYpKQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPiA+ID4gPiA+ID4gRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4gPiA+ID4gPiA+ID4gbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbQ0KPiA+ID4gPiA+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjQsIDIw MTcgMjoyMCBQTQ0KPiA+ID4gPiA+ID4gPiA+IFRvOiBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRy ZWFzQGNpc2NvLmNvbT47IEpvbiBTaGFsbG93DQo+ID4gPiA+ID4gPiA+ID4gPHN1cGpwcy0gaWV0 ZkBqcHNoYWxsb3cuY29tPjsgZG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiA+IFN1YmplY3Q6 IFJlOiBbRG90c10gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cw0KPiA+ID4g PiA+ID4gPiA+IHJldmlldw0KPiA+ID4gPiA+ID4gPiA+ICgtMDYpKQ0KPiA+ID4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiA+ID4gSGkgRmxlbW1pbmcsIGFsbCwNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+ID4gPiA+IE1lZA0KPiA+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0gRGXCoDogRmxlbW1p bmcgQW5kcmVhc2VuDQo+ID4gPiA+ID4gPiA+ID4gPiBbbWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNv bV0gRW52b3nDqcKgOg0KPiA+ID4gPiA+ID4gPiA+ID4gbHVuZGkNCj4gPiA+ID4gPiA+ID4gPiA+ IDIzIG9jdG9icmUgMjAxNyAxNzozNiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBK b24NCj4gPiA+ID4gPiA+ID4gPiA+IFNoYWxsb3c7IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDogUmU6 IERPVFMgJiBOQVQgKHdhcyBSRToNCj4gPiA+ID4gPiA+ID4gPiA+IFtEb3RzXSBET1RTIFJlcXVp cmVtZW50cyByZXZpZXcgKC0wNikpDQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBPbiAxMC8yMy8xNyA4OjI4 IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+ID4gPiA+ID4gPiA+ ID4gPiBIaSBKb24sIGFsbCwNCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ ID4gSSBhZ3JlZSB3aXRoIEZsZW1taW5nIHRoYXQgInNvbWUgbW9yZSB3b3JrIiBpcyBuZWVkZWQu DQo+ID4gPiA+ID4gPiA+ID4gPiA+IElNSE8sIHRoaXMgaXMgYQ0KPiA+ID4gPiA+ID4gPiA+ID4g dHlwaWNhbCBkaXNjdXNzaW9uIHRvIGluY2x1ZGUgaW4gYSBkZWRpY2F0ZWQgc2VjdGlvbiBpbg0K PiA+ID4gPiA+ID4gPiA+ID4gdGhlIERPVFMgYXJjaGl0ZWN0dXJlIEktRC4NCj4gPiA+ID4gPiA+ ID4gPiA+IEFncmVlZC4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPkZyb20gYSByZXF1aXJlbWVudCBz dGFuZHBvaW50LCB3ZSBkb24ndCBuZWVkIHRvDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID5lbGFib3Jh dGUgaG93IHRoZQ0KPiA+ID4gPiA+ID4gPiA+ID4gcHJvdG9jb2xzIHdpbGwgZnVsZmlsIGl0LiBT SUctMTAgZG9lcyBldmVuIGEgbmljZSBqb2IgYnkNCj4gPiA+ID4gPiA+ID4gPiA+IGNpdGluZw0K PiA+ID4gPiA+ID4gPiA+ID4gUkZDODA4NSB3aGljaCBwb2ludHMgdG8gTkFUIHRyYXZlcnNhbCBt ZWNoYW5pc21zLiBPbmUNCj4gPiA+ID4gPiA+ID4gPiA+IGNvdWxkIHBpY2sgaGlzL2hlciBmYXZv cml0ZSBwcm90b2NvbCBmcm9tIHRoZSBsaXN0IGluIDgwODUNCj4gPiA+ID4gPiA+ID4gPiA+IHRv IGRpc2NvdmVyIHRoZSBleHRlcm5hbCBJUCBhZGRyZXNzL3ByZWZpeCwgaWYgbmVlZGVkLg0KPiA+ ID4gPiA+ID4gPiA+ID4gRXh0ZXJuYWwgSVAgYWRkcmVzc2VzL3ByZWZpeGVzIGNhbiBiZSBJUHY0 IGZvciBhIE5BVDQ0IG9yDQo+ID4gPiA+ID4gPiA+ID4gPiBOQVQ2NCwgYnV0IGNhbiBiZQ0KPiA+ ID4gPiA+ID4gPiA+ID4gSVB2NiBwcmVmaXhlcyBmb3IgZW50ZXJwcmlzZXMgZGVwbG95aW5nIE5Q VHY2LCBhbmQgc28gb24uDQo+ID4gPiA+ID4gPiA+ID4gPiBQYXJ0IG9mIHRoZSBjaGFsbGVuZ2Ug aGVyZSBpcyB0aGF0IHRoZSBhdHRhY2sgdGFyZ2V0IGFuZA0KPiA+ID4gPiA+ID4gPiA+ID4gdGhl IERPVFMgY2xpZW50IGFyZSBub3QgbmVjZXNzYXJpbHkgb25lIGFuZCB0aGUgc2FtZSwNCj4gPiA+ ID4gPiA+ID4gPiA+IHdoaWNoIG1ha2VzIGl0IG1vcmUgZGlmZmljdWx0IHRvIGRldGVybWluZSB0 aGUNCj4gPiA+ID4gPiA+ID4gPiA+IHB1YmxpYy1mYWNpbmcgSVAtYWRkcmVzcy9wb3J0IHVuZGVy IGF0dGFjayAoYXQgbGVhc3QgaWYNCj4gPiA+ID4gPiA+ID4gPiA+IHRoZSBET1RTIGNsaWVudCBp cw0KPiA+ID4gZ29pbmcgdG8NCj4gPiA+ID4gZG8gaXQpLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+ID4gW01lZF0gVGhpcyBpcyBleGFjdGx5IHRoZSBraW5kIG9mIHRoZSBkaXNjdXNz aW9uIHRvIGhhdmUuDQo+ID4gPiBUaGFua3MuDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gPiBXaXRoIG9yIHdpdGhvdXQgTkFULCBET1RTIGNsaWVudHMgYXJlIGFzc3VtZWQgdG8gYmUg ZmVkIHdpdGgNCj4gPiA+ID4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+ID4gaW50ZXJuYWwNCj4g PiA+ID4gPiA+ID4gPiB0YXJnZXQocykuIFRoaXMgY2FuIGJlIGFjaGlldmVkIGJ5IHByb3Zpc2lv bmluZyAobGlrZWx5KSBvcg0KPiA+ID4gPiA+ID4gPiA+IGJ5IGRpc2NvdmVyeQ0KPiA+ID4gPiA+ ID4gPiBtZWFucw0KPiA+ID4gPiA+ID4gPiA+IChlLmcuLCByZXNpZGVudGlhbCBvciBzbWFsbCBl bnRlcnByaXNlIG5ldHdvcmtzKS4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IENh biB3ZSBhc3N1bWUgdGhhdCB0aGUgZGlzY292ZXJ5IG9mIHRoZSBleHRlcm5hbCBJUA0KPiA+ID4g PiA+ID4gPiA+IGFkZHJlc3MvcHJlZml4Ly4uIGlzDQo+ID4gPiA+ID4gPiA+IGRvbmUNCj4gPiA+ ID4gPiA+ID4gPiBieSBhIERPVFMgY2xpZW50IG9ubHkgaWYgaXQgaXMgZXhwbGljaXRseSBpbnN0 cnVjdGVkIHRvIGRvDQo+IHNvPw0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+ID4gPiA+ID4gSW4gc29tZSBkZXBsb3ltZW50cywgRE9UUyBjbGllbnRzIG1heSBi ZSBwcm92aXNpb25lZA0KPiA+ID4gPiA+ID4gPiA+ID4gPiB3aXRoIHRoZSBzZXQgb2YNCj4gPiA+ ID4gPiA+ID4gPiA+IGludGVybmFsIHJlc291cmNlcywgc28gdGhlcmUgaXMgbm8gbmVlZCBmb3Ig ZGlzY292ZXJ5Lg0KPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBBbHNv LCBhcyBKb24gbWVudGlvbmVkLCBET1RTIGdhdGV3YXlzIGNhbiBiZSBvZiBoZWxwIHRvDQo+ID4g PiA+ID4gPiA+ID4gPiA+IHNldCB0aGUNCj4gPiA+ID4gPiA+ID4gPiA+IGFwcHJvcHJpYXRlIElQ IGFkZHJlc3Nlcy9wcmVmaXhlcy9wb3J0IG51bWJlcnMgaW4gdGhlDQo+ID4gPiA+ID4gPiA+ID4g PiBwcmVzZW5jZSBvZiB0cmFuc2xhdG9ycy4NCj4gPiA+ID4gPiA+ID4gPiA+IEFncmVlZCAtIGJ1 dCB0aGV5IHN0aWxsIG5lZWQgYSB3YXkgdG8gZmlndXJlIG91dCB0aGUNCj4gPiA+ID4gPiA+ID4g PiA+IHByaXZhdGUvcHVibGljIG1hcHBpbmcgZm9yIGEgZ2l2ZW4gYXR0YWNrIHRhcmdldC4NCj4g PiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IFtNZWRdIEJlY2F1c2UgYSBERG9TIGF0dGFj ayBpcyBvYnNlcnZlZCBmcm9tIHRoZSBpbnRlcm5hbA0KPiA+ID4gPiA+ID4gPiA+IG5ldHdvcmss DQo+ID4gPiA+ID4gPiA+ID4gbWFwcGluZyhzKSBhcmUgbmVjZXNzYXJpbHkgbWFpbnRhaW5lZCBi eSB0aGUgb24tcGF0aA0KPiA+ID4gdHJhbnNsYXRvcihzKS4NCj4gPiA+ID4gPiA+ID4gPiBPdGhl cndpc2UsIHRoZSBpbmNvbWluZyBhdHRhY2sgdHJhZmZpYyBjb3VsZG4ndCBiZSBmb3J3YXJkZWQN Cj4gPiA+ID4gPiA+ID4gPiB0byBpbnRlcm5hbA0KPiA+ID4gPiA+ID4gPiBob3N0cy4NCj4gPiA+ ID4gPiA+ID4gPiBUaGlzIG1vZGVsIGFzc3VtZXMgdGhhdCB0aGUgZ2F0ZXdheSBpcyBjb2xsb2Nh dGVkIHdpdGggdGhlDQo+IE5BVC4NCj4gPiA+ID4gPiA+ID4gPiBTbywgdGhlIGdhdGV3YXkgY2Fu IHJlcGxhY2UgdGhlIGludGVybmFsIElQIGFkZHJlc3MvcHJlZml4DQo+ID4gPiA+ID4gPiA+ID4g d2l0aCB0aGUgb25lDQo+ID4gPiA+ID4gPiA+IHJldHJpZXZlcw0KPiA+ID4gPiA+ID4gPiA+IGZy b20gdGhlIE5BVCBtYXBwaW5nIHRhYmxlLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ ID4gRG8geW91IHNlZSBhbnkgaXNzdWUgd2l0aCB0aGlzIHNjaGVtZT8NCj4gPiA+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBBbiBvcGVuIHF1ZXN0aW9uIHRob3VnaCB3b3VsZCBiZSB0 byBkaXNjdXNzIGlmIHRoZXJlIGlzDQo+ID4gPiA+ID4gPiA+ID4gPiA+IGEgdmFsdWUgaW4NCj4g PiA+ID4gPiA+ID4gPiA+IGhhdmluZyBhIGZlYXR1cmUgaW4gdGhlIERPVFMgcHJvdG9jb2wgdG8g aW5mb3JtIGEgRE9UUw0KPiA+ID4gPiA+ID4gPiA+ID4gY2xpZW50IHRoYXQgYSBOQVQgaXMgZGV0 ZWN0ZWQgb24tcGF0aC4gVGhpcyBjYW4gYmUNCj4gPiA+ID4gPiA+ID4gPiA+IHByZXNlbnRlZCBh cyBhbiBpbmZvcm1hdGlvbiBlbGVtZW50IHJldHVybmVkIGJ5IHRoZSBzZXJ2ZXINCj4gPiA+ID4g PiA+ID4gPiA+IHRvIHRoZSBjbGllbnQuIFRoaXMgaW5mb3JtYXRpb24gY2FuIGJlLCBmb3IgZXhh bXBsZSwgdXNlZA0KPiA+ID4gPiA+ID4gPiA+ID4gYnkgdGhlIGNsaWVudCB0byBhZGp1c3QgaXRz IEhUIGludGVydmFsLCBhZGp1c3QgdGhlDQo+ID4gPiA+ID4gPiA+ID4gPiBpbnRlcm5hbCBJUCBh ZGRyZXNzZXMvcHJlZml4ZXMgdG8NCj4gPiA+IGJlDQo+ID4gPiA+IHByb3RlY3RlZCwgZXRjLg0K PiA+ID4gPiA+IE9waW5pb25zPw0KPiA+ID4gPiA+ID4gPiA+ID4gSXQgc291bmRzIGFwcGVhbGlu ZywgYnV0IGl0J3MgdmVyeSBkaWZmaWN1bHQgdG8gZG8gdGhpcw0KPiA+ID4gPiA+ID4gPiA+ID4g cmVsaWFibHksIGFuZCBpdCdzIG5vdCBqdXN0IE5BVHMgdGhhdCBhcmUgYW4gaXNzdWUgaGVyZTsN Cj4gPiA+ID4gPiA+ID4gPiA+IEZpcmV3YWxscyBwcmVzZW50IHNpbWlsYXIgY2hhbGxlbmdlcyAo YW5kIHRoZXkgbWF5IG9yIG1heQ0KPiA+ID4gPiA+ID4gPiA+ID4gbm90IGJlIE5BVCdpbmcgaW5k aXZpZHVhbA0KPiA+ID4gPiA+ID4gZmxvd3MpLg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IFtNZWRdIEkgZnVsbHkgYWdyZWUgdGhhdCBmaXJld2Fs bHMgZGV0ZWN0IGlzIG1vcmUgY29tcGxleC4NCj4gPiA+ID4gPiA+ID4gPiBMZXQncyBwdXQgaXQN Cj4gPiA+ID4gPiA+ID4gYXNpZGUNCj4gPiA+ID4gPiA+ID4gPiBhbmQgZm9jdXMgb24gdGhlIE5B VCBjYXNlLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBUaGUgcHJlc2VuY2UgYW5kIGJl aGF2aW9yIG9mIE5BVCBhbmQgRmlyZXdhbGwsIGFuZCBrZWVwYWxpdmUNCj4gPiA+ID4gPiA+ID4g aW50ZXJ2YWwgY2FuIGJlIGRldGVybWluZWQgdXNpbmcgU1RVTiAoZGlzY3Vzc2VkIGluDQo+ID4g PiA+ID4gPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzgwKS4NCj4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gLVRpcnUNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gPiA+IFdlIGNhbiBjb25zaWRlciBtYW55IGFwcHJvYWNoZXMgdG8gZGV0 ZWN0IGEgTkFULCBlLmcuLA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gKDEpIFRo ZSBET1RTIGNsaWVudCBpbnNlcnRzIGluIHRoZSBjb3JlIG1lc3NhZ2UgdGhlIElQDQo+ID4gPiA+ ID4gPiA+ID4gYWRkcmVzcy9wb3J0IGl0DQo+ID4gPiA+ID4gPiA+IHVzZXMgdG8NCj4gPiA+ID4g PiA+ID4gPiBzZW5kIHRoZSByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4gVXBvbiByZWNlaXB0 IG9mIHRoZQ0KPiA+ID4gPiA+ID4gPiA+IHJlcXVlc3QgYnkgdGhlIERPVFMgc2VydmVyLCBpdCBj aGVja3MgaWYgdGhlIGVuY2xvc2VkIElQDQo+ID4gPiA+ID4gPiA+ID4gYWRkcmVzcy9wb3J0IG1h dGNoIHRoZSBzb3VyY2UNCj4gPiA+ID4gPiA+ID4gSVANCj4gPiA+ID4gPiA+ID4gPiBhZGRyZXNz L3BvcnQgb2YgdGhlIHJlY2VpdmVkIHBhY2tldC4gSWYgeWVzLCB0aGUgc2VydmVyIHNldHMNCj4g PiA+ID4gPiA+ID4gPiBpbiB0aGUNCj4gPiA+ID4gPiA+ID4gcmVzcG9uc2UgYQ0KPiA+ID4gPiA+ ID4gPiA+IGRlZGljYXRlZCBwYXJhbWV0ZXIgdG8gaW5kaWNhdGUgdGhhdCBhIHRyYW5zbGF0b3Ig aXMNCj4gPiA+ID4gPiA+ID4gPiBkZXRlY3RlZA0KPiA+ID4gPiA+ID4gPiA+IG9uLQ0KPiA+ID4g PiA+IHBhdGguDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiAoMikgVGhlIERPVFMg c2VydmVyIGluc2VydHMgc3lzdGVtYXRpY2FsbHkgdGhlIHNvdXJjZSBJUA0KPiA+ID4gPiA+ID4g PiA+IGFkZHJlc3MvcG9ydCBpbg0KPiA+ID4gPiA+ID4gPiBhDQo+ID4gPiA+ID4gPiA+ID4gcmVz cG9uc2UgdG8gYSBtZXNzYWdlIGZyb20gYSBET1RTIGNsaWVudC4gVXBvbiByZWNlaXB0IG9mDQo+ ID4gPiA+ID4gPiA+ID4gdGhhdCByZXNwb25zZSwgdGhlIERPVFMgY2xpZW50IGNvbXBhcmVzIHRo ZSBlbmNsb3NlZA0KPiA+ID4gPiA+ID4gPiA+IGFkZHJlc3MvcG9ydCB3aXRoIHRoZSBvbmVzIGl0 IHVzZWQNCj4gPiA+ID4gPiA+ID4gdG8NCj4gPiA+ID4gPiA+ID4gPiBzZW5kIHRoZSByZXF1ZXN0 IHRvIGRldGVjdCBhbnkgbWlzbWF0Y2guDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gPiA+ID4gLS0gRmxlbW1pbmcNCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+ID4gPiA+ ID4gPiA+IE1lZA0KPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tIERlwqA6IERvdHMNCj4gPiA+ID4gPiA+ID4gPiA+ID4+ IFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvbg0KPiA+ID4g PiA+ID4gPiA+ID4gPj4gU2hhbGxvdyBFbnZvecOpwqA6IGx1bmRpIDIzIG9jdG9icmUgMjAxNyAx MzoxOCDDgMKgOg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gJ0ZsZW1taW5nIEFuZHJlYXNlbic7IGRv dHNAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFtEb3RzXQ0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gRE9U UyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpDQo+ID4gPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4g PiA+ID4gPiA+ID4gPj4gSGkgRmxlbW1pbmcsDQo+ID4gPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4g PiA+ID4gPiA+ID4gPj4gVGhlIHdheSBteSBtaW5kIHdvcmtzIGlzIHRvIHRoaW5rIG9mIGEgcHJh Y3RpY2FsDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBzaXR1YXRpb24gYW5kIHNlZSBpZiB0aGluZ3Mg Zml0Lg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPiA+ID4+IEFzIEkgcmVh ZCBTSUctMDEwLCB0aGVyZSBjb3VsZCBiZSBhIERPVFMgY2xpZW50IHdpdGggYQ0KPiA+ID4gPiA+ ID4gPiA+ID4gPj4gbWFuYWdlbWVudCBJUCBhZGRyZXNzIHRoYXQgaXMgUkZDMTkxOCAtIHRoaXMg Y2xpZW50DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBjb3VsZCBiZSBtb25pdG9yaW5nIE5ldGZsb3cg aW5mb3JtYXRpb24gYW5kIGNhbiByZXF1ZXN0DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBtaXRpZ2F0 aW9uIGZvciB0aGUgYXBwcm9wcmlhdGUgcHVibGljIElQcw0KPiA+ID4gPiA+ID4gPiA+ID4gdGhh dA0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gYXJlIGJlaW5nIG1vbml0b3JlZC4gIFNvIFNJRy0wMTAg aXMgbmVlZGVkIGZvciB0aGlzIHVzZQ0KPiA+ID4gY2FzZS4NCj4gPiA+ID4gPiA+ID4gPiA+ID4+ DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBJdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIERP VFMgc2VydmVyIGFzIHRvDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiB3aGV0aGVyIGl0IGFjY2VwdHMg YSBtaXRpZ2F0aW9uIHJlcXVlc3QgZm9yIGENCj4gPiA+ID4gPiA+ID4gPiA+ID4+IHBhcnRpY3Vs YXIgdGFyZ2V0IGlwIChvciBkb21haW4NCj4gPiA+ID4gPiA+ID4gZXRjLikgb3INCj4gPiA+ID4g PiA+ID4gPiBub3QuDQo+ID4gPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4g SWYgdGhlcmUgaXMgZ29pbmcgdG8gYmUgYSBOQVQgYm9yZGVyIHdoZXJlIHB1YmxpYyBJUHMNCj4g PiA+ID4gPiA+ID4gPiA+ID4+IGFyZSBtYXBwZWQgaW50byBwcml2YXRlIElQcyAoYW5kIHZpY2Ug dmVyc2EpLCBJIHdvdWxkDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiB0aGVuIGV4cGVjdCB0aGVyZSB0 byBiZSBhIERPVFMgZ2F0ZXdheSBiZXR3ZWVuIHRoZXNlIDINCj4gPiA+ID4gPiA+ID4gPiA+ID4+ IHpvbmVzLCBhbmQgaXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBET1RTIGdhdGV3YXkN Cj4gPiA+ID4gPiA+ID4gPiA+ID4+IHRvIGRvIGFueSB0YXJnZXQtaXANCj4gPiA+ID4gPiBtYXBw aW5ncy4NCj4gPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBSZWdhcmRz DQo+ID4gPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gSm9uDQo+ID4gPiA+ ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiA+ID4gPiA+ID4gPiA+ID4+IEZyb206IERvdHMgW21haWx0bzppZXRmLXN1cGpw cy1kb3RzLWJvdW5jZXNAaWV0Zi5vcmddDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBPbiBCZWhhbGYg T2YgRmxlbW1pbmcgQW5kcmVhc2VuDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBTZW50OiAyMiBPY3Rv YmVyIDIwMTcgMjA6MTcNCj4gPiA+ID4gPiA+ID4gPiA+ID4+IFRvOiBkb3RzOyBkcmFmdC1pZXRm LWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBTdWJqZWN0 OiBbRG90c10gRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpDQo+ID4gPiA+ID4gPiA+ID4g PiA+Pg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gR3JlZXRpbmdzDQo+ID4gPiA+ID4gPiA+ID4gPiA+ Pg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gSSBoYXZlIHJldmlld2VkIHRoZSBsYXRlc3QgdmVyc2lv biBvZiB0aGUgRE9UUw0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gcmVxdWlyZW1lbnRzIGRyYWZ0DQo+ ID4gPiA+ID4gPiA+ID4gPiA+PiAoaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1k b3RzLXJlcXVpcmVtZW50cy0NCj4gPiA+IDA2LnR4dCkuDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBJ bg0KPiA+ID4gPiA+ID4gPiA+ID4gZ2VuZXJhbCwNCj4gPiA+ID4gPiA+ID4gPiA+ID4+IEkgdGhp bmsgdGhlIGRyYWZ0IGlzIGluIGdvb2Qgc2hhcGUgd2l0aCBvbmx5IGEgZmV3DQo+ID4gPiA+ID4g PiA+ID4gPiA+PiBlZGl0cyByZXF1aXJlZCwgc28gSSBob3BlIHdlIGNhbiBtb3ZlIHRvIFdHTEMg c29vbi4gSQ0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gaGF2ZSBhIGZldyBjb21tZW50cyBiZWxvdyAo b2Ygd2hpY2gNCj4gPiA+ID4gPiA+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gTkFU IG9uZSBpcyB0aGUgb25seSByZWFsIHN1YnN0YW50aWFsIG9uZSkuIEkgaGF2ZSBhbHNvDQo+ID4g PiA+ID4gPiA+ID4gPiA+PiBzdWJtaXR0ZWQgYSBwdWxsIHJlcXVlc3Qgd2l0aCBhIGZldyBuaXQg Zml4ZXMgb24NCj4gR2l0SHViOg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4g PiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBTZWN0aW9uIDEuMg0KPiA+ID4gPiA+ID4gPiA+ ID4gPj4gLSBUaGUgZGVmaW5pdGlvbiBvZiAiRE9UUyBTaWduYWwiIGlzIHNsaWdodGx5DQo+ID4g PiA+ID4gPiA+ID4gPiA+PiBpbmNvbnNpc3RlbnQgd2l0aCB0aGUgcmVzcGVjdGl2ZSAiQ2xpZW50 IFNpZ25hbCIgYW5kDQo+ICJTZXJ2ZXINCj4gPiBTaWduYWwiDQo+ID4gPiBkZWZpbml0aW9ucy4N Cj4gPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBTSUctMDA1Og0KPiA+ ID4gPiA+ID4gPiA+ID4gPj4gLSBOb3QgY2xlYXIgdGhhdCBhbHdheXMgcmVxdWlyaW5nICJudW1i ZXIgb2YgcGFja2V0cyINCj4gPiA+ID4gPiA+ID4gPiA+ID4+IG1ldHJpY3MgaXMgbWVhbmluZ2Z1 bC4gQ29uc2lkZXIgVENQLWJhc2VkIGF0dGFja3MgZm9yDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBl eGFtcGxlLiBOdW1iZXIgb2YgYnl0ZXMgbWF5IGFsd2F5cyBiZSBvayAtIGFib3ZlIGFuZA0KPiA+ ID4gPiA+ID4gPiA+ID4gPj4gYmV5b25kIHRoYXQgaXQgc2hvdWxkIHByb2JhYmx5IGJlIGV4dGVu c2libGUgYW5kL29yDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBhdHRhY2sNCj4gPiA+ID4gZGVwZW5k ZW50Lg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gLSBJIGRvbid0IHRoaW5rIHRoZSByZXF1aXJlbWVu dHMgZG9jdW1lbnQgc2hvdWxkIGdldA0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gaW50byBzcGVjaWZ5 aW5nDQo+ID4gPiA+ID4gPiA+ID4gPiB0aW1lcg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gdmFsdWVz IC0gZXhwb250aWFsIGJhY2tvZmYgd2l0aCBzb21lIG1heGltdW0gdmFsdWUNCj4gPiA+ID4gPiA+ ID4gPiA+ID4+IHNlZW1zIGFib3V0IHRoZQ0KPiA+ID4gPiA+ID4gPiA+ID4gcmlnaHQNCj4gPiA+ ID4gPiA+ID4gPiA+ID4+IGxldmVsIG9mIGRldGFpbCBoZXJlLg0KPiA+ID4gPiA+ID4gPiA+ID4g Pj4NCj4gPiA+ID4gPiA+ID4gPiA+ID4+IFNJRy0wMDk6DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiAt IFRvIGJlIGNsZWFyLCB0aGUgY29uZmxpY3RzIG9ubHkgYXBwbHkgd2l0aGluIGEgc2luZ2xlDQo+ ID4gPiA+ID4gPiA+ID4gPiA+PiBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIHJpZ2h0ID8gRm9yIGV4 YW1wbGUsIGlmIGEgY2xpZW50DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiB0ZWxscyB0aGUgc2FtZSBk b21haW4gdG8gYWx0ZXJuYXRlbHkgdHVybiBvbi9vZmYNCj4gPiA+ID4gPiA+ID4gPiA+ID4+IG1p dGlnYXRpb24gZm9yIGEgZ2l2ZW4gcHJlZml4LCByb3V0ZSBmbGFwcGluZw0KPiA+ID4gPiA+ID4g PiA+ID4gbWF5DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBvY2N1ci4gVGhlIHNhbWUgY29uY2VybiBk b2VzIG5vdCBhcHBseSBpZiBhIGNsaWVudA0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gdGVsbHMgdHdv IGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIHRvDQo+ID4gPiA+ID4gPiA+ID4gPiA+ PiByZXNwZWN0aXZlIHR1cm4gbWl0aWdhdGlvbiBvbiAoZG9tYWluIDEpIGFuZA0KPiA+ID4gPiA+ ID4gPiA+ID4gb2ZmDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiAoZG9tYWluIDIpLiBJZiBzbywgY2Fu IHdlIGNsYXJpZnkgdGhhdCAoYWxzbyBpbiBsaWV1IG9mDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBz b21lIG9mIHRoZQ0KPiA+ID4gPiA+ID4gPiA+ID4gbXVsdGktDQo+ID4gPiA+ID4gPiA+ID4gPiA+ PiBob21pbmcgY29tbWVudHMgcmFpc2VkIHByZXZpb3VzbHkpID8NCj4gPiA+ID4gPiA+ID4gPiA+ ID4+DQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBTSUctMDEwOg0KPiA+ID4gPiA+ID4gPiA+ID4gPj4g LSBET1RTIENsaWVudCBiZWhpbmQgTkFULiBPbiBvbmUgaGFuZCwgaXQgc2VlbXMNCj4gPiA+ID4g PiA+ID4gPiA+ID4+IHJlYXNvbmFibGUgdG8gaGF2ZSB0aGlzIHJlcXVpcmVtZW50IHNpbmNlIGNs aWVudHMgZm9yDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBzdXJlIGNhbiBiZSBiZWhpbmQgTkFUcywg YW5kDQo+ID4gPiA+ID4gPiA+IHdpdGgNCj4gPiA+ID4gPiA+ID4gPiB0aGluZ3MNCj4gPiA+ID4g PiA+ID4gPiA+ID4+IGxpa2UgZHluYW1pYyBETlMsIHRoZXkgY2FuICAgICBjZXJ0YWlubHkgYmUg cmVhY2hhYmxlLg0KPiA+ID4gSG93ZXZlciwNCj4gPiA+ID4gPiBpZg0KPiA+ID4gPiA+ID4gPiB3 ZQ0KPiA+ID4gPiA+ID4gPiA+ID4gZG8NCj4gPiA+ID4gPiA+ID4gPiA+ID4+IHdhbnQgdG8gYWxs b3cgZm9yIHRoaXMgc2NlbmFyaW8sIGFuZCBpbiBwYXJ0aWN1bGFyIGZvcg0KPiA+ID4gPiA+ID4g PiA+ID4gPj4gdGhlIERPVFMgY2xpZW50DQo+ID4gPiA+ID4gPiA+ID4gPiB0bw0KPiA+ID4gPiA+ ID4gPiA+ID4gPj4gaGF2ZSBhIHByaXZhdGUgSVAtYWRkcmVzcyAocG90ZW50aWFsbHkgYmVoaW5k IG11bHRpcGxlDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBOQVRzKSwgdGhlbiB3ZQ0KPiA+ID4gPiA+ ID4gPiA+ID4gaGF2ZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gbW9yZSB3b3JrIHRvIGRvIGJlY2F1 c2UgaXQgd29uJ3QgZG8gdGhlIERPVFMgc2VydmVyIGFueQ0KPiA+ID4gPiA+ID4gPiA+ID4gPj4g Z29vZCB0byBnZXQgYSBtaXRpZ2F0aW9uIHJlcXVlc3QgcmVmZXJyaW5nIHRvIHRoYXQNCj4gPiA+ ID4gPiA+ID4gPiA+ID4+IHByaXZhdGUgSVAtYWRkcmVzcyAob3INCj4gPiA+ID4gPiA+ID4gcHJl Zml4KS4NCj4gPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4g PiA+ID4gPiA+ID4gPj4gVGhhbmtzDQo+ID4gPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4g PiA+ID4gPj4gLS0gRmxlbW1pbmcNCj4gPiA+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ ID4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gPiA+ID4gPiA+ID4gPj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+ID4gPiA+ ID4+IERvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4gPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+ID4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4g PiA+ID4gPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gPiA+ID4gPiA+ID4gPiA+PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+ID4g PiA+ID4gPj4gRG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiA+ID4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4gPiA+ID4gPiA+ID4gPiA+IC4NCj4g PiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gPiA+ ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+ID4gPiBEb3RzQGlldGYub3JnDQo+ID4g PiA+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo= From nobody Thu Oct 26 06:39:10 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1C1138BCD for ; Thu, 26 Oct 2017 06:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMNCFiKE3liz for ; Thu, 26 Oct 2017 06:39:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DA413F4A9 for ; Thu, 26 Oct 2017 06:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8609; q=dns/txt; s=iport; t=1509025146; x=1510234746; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=VgoAs26pyx8dVt7U4osUf24AOVGNzR8az3jgpXk+7ao=; b=Hst1OFJSv0lZSegSGcIQuyrwoJOsUNVi9r0mD8WYlp28mvj7a3CPrnnC vYaZQqTW5vezvxirynnOWvyn+alEbjmyuxULVti58aG3xHjTdeV/CtgOn 7TNGK0PJqL7X8U/T4jv3HizeYfEiPpghjG7ueqV0JZ1ijZicidVUofkC+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAADo5PFZ/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbieDeoofjw6BenyVRIIRChgLhRgChEA/GAECAQEBAQEBAWs?= =?us-ascii?q?ohR0BAQEBAgEBASEPAQU2FwQLEQEDAQEBAgIjAwICJx8DBggGAQwGAgEBFYl6B?= =?us-ascii?q?QgQqVWCJ4p0AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4IbBIEqXYFQgWkpgkw?= =?us-ascii?q?1hG+DKoJhBaF7iHyLfYIVhX+DXiSHFZYKgTkfOIFoVSUVSYJkglkfggMlNgGMR?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.43,434,1503360000"; d="scan'208";a="302225160" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Oct 2017 13:39:05 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v9QDd459008370; Thu, 26 Oct 2017 13:39:05 GMT To: mohamed.boucadair@orange.com, Jon Shallow , "dots@ietf.org" References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Flemming Andreasen Message-ID: Date: Thu, 26 Oct 2017 09:39:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:39:09 -0000 On 10/24/17 4:50 AM, mohamed.boucadair@orange.com wrote: > Hi Flemming, all, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Flemming Andreasen [mailto:fandreas@cisco.com] >> Envoyé : lundi 23 octobre 2017 17:36 >> À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org >> Objet : Re: DOTS & NAT (was RE: [Dots] DOTS Requirements review (-06)) >> >> >> >> On 10/23/17 8:28 AM, mohamed.boucadair@orange.com wrote: >>> Hi Jon, all, >>> >>> I agree with Flemming that "some more work" is needed. IMHO, this is a >> typical discussion to include in a dedicated section in the DOTS >> architecture I-D. >> Agreed. >>> >From a requirement standpoint, we don't need to elaborate how the >> protocols will fulfil it. SIG-10 does even a nice job by citing RFC8085 >> which points to NAT traversal mechanisms. One could pick his/her favorite >> protocol from the list in 8085 to discover the external IP address/prefix, >> if needed. External IP addresses/prefixes can be IPv4 for a NAT44 or >> NAT64, but can be IPv6 prefixes for enterprises deploying NPTv6, and so >> on. >> Part of the challenge here is that the attack target and the DOTS client >> are not necessarily one and the same, which makes it more difficult to >> determine the public-facing IP-address/port under attack (at least if >> the DOTS client is going to do it). > [Med] This is exactly the kind of the discussion to have. Thanks. > > With or without NAT, DOTS clients are assumed to be fed with the internal target(s). This can be achieved by provisioning (likely) or by discovery means (e.g., residential or small enterprise networks). > > Can we assume that the discovery of the external IP address/prefix/.. is done by a DOTS client only if it is explicitly instructed to do so? > Seems reasonable, however having the DOTS client instead of the attack target doing the discovery may not always work. >>> In some deployments, DOTS clients may be provisioned with the set of >> internal resources, so there is no need for discovery. >>> Also, as Jon mentioned, DOTS gateways can be of help to set the >> appropriate IP addresses/prefixes/port numbers in the presence of >> translators. >> Agreed - but they still need a way to figure out the private/public >> mapping for a given attack target. > [Med] Because a DDoS attack is observed from the internal network, mapping(s) are necessarily maintained by the on-path translator(s). Otherwise, the incoming attack traffic couldn't be forwarded to internal hosts. > This model assumes that the gateway is collocated with the NAT. So, the gateway can replace the internal IP address/prefix with the one retrieves from the NAT mapping table. > > Do you see any issue with this scheme? Requiring co-location of the DOTS gateway and the NAT seems like a significant obstacle to real-life deployment. >>> An open question though would be to discuss if there is a value in >> having a feature in the DOTS protocol to inform a DOTS client that a NAT >> is detected on-path. This can be presented as an information element >> returned by the server to the client. This information can be, for >> example, used by the client to adjust its HT interval, adjust the internal >> IP addresses/prefixes to be protected, etc. Opinions? >> It sounds appealing, but it's very difficult to do this reliably, and >> it's not just NATs that are an issue here; Firewalls present similar >> challenges (and they may or may not be NAT'ing individual flows). >> > [Med] I fully agree that firewalls detect is more complex. Let's put it aside and focus on the NAT case. > > We can consider many approaches to detect a NAT, e.g., > > (1) The DOTS client inserts in the core message the IP address/port it uses to send the request to the DOTS server. Upon receipt of the request by the DOTS server, it checks if the enclosed IP address/port match the source IP address/port of the received packet. If yes, the server sets in the response a dedicated parameter to indicate that a translator is detected on-path. > > (2) The DOTS server inserts systematically the source IP address/port in a response to a message from a DOTS client. Upon receipt of that response, the DOTS client compares the enclosed address/port with the ones it used to send the request to detect any mismatch. We will probably end up reinventing STUN before we are done, so I'd rather leverage that. Thanks -- Flemming > >> -- Flemming >> >> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow >>>> Envoyé : lundi 23 octobre 2017 13:18 >>>> À : 'Flemming Andreasen'; dots@ietf.org >>>> Objet : Re: [Dots] DOTS Requirements review (-06) >>>> >>>> Hi Flemming, >>>> >>>> The way my mind works is to think of a practical situation and see if >>>> things fit. >>>> >>>> As I read SIG-010, there could be a DOTS client with a management IP >>>> address that is RFC1918 - this client could be monitoring Netflow >>>> information and can request mitigation for the appropriate public IPs >> that >>>> are being monitored. So SIG-010 is needed for this use case. >>>> >>>> It is the responsibility of the DOTS server as to whether it accepts a >>>> mitigation request for a particular target ip (or domain etc.) or not. >>>> >>>> If there is going to be a NAT border where public IPs are mapped into >>>> private IPs (and vice versa), I would then expect there to be a DOTS >>>> gateway between these 2 zones, and it is the responsibility of the DOTS >>>> gateway to do any target-ip mappings. >>>> >>>> Regards >>>> >>>> Jon >>>> >>>> -----Original Message----- >>>> From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of >>>> Flemming Andreasen >>>> Sent: 22 October 2017 20:17 >>>> To: dots; draft-ietf-dots-requirements@ietf.org >>>> Subject: [Dots] DOTS Requirements review (-06) >>>> >>>> Greetings >>>> >>>> I have reviewed the latest version of the DOTS requirements draft >>>> (https://www.ietf.org/id/draft-ietf-dots-requirements-06.txt). In >> general, >>>> I think the draft is in good shape with only a few edits required, so I >>>> hope we can move to WGLC soon. I have a few comments below (of which >> the >>>> NAT one is the only real substantial one). I have also submitted a pull >>>> request with a few nit fixes on GitHub: >>>> >>>> >>>> Section 1.2 >>>> - The definition of "DOTS Signal" is slightly inconsistent with the >>>> respective "Client Signal" and "Server Signal" definitions. >>>> >>>> SIG-005: >>>> - Not clear that always requiring "number of packets" metrics is >>>> meaningful. Consider TCP-based attacks for example. Number of bytes may >>>> always be ok - above and beyond that it should probably be extensible >>>> and/or attack dependent. >>>> - I don't think the requirements document should get into specifying >> timer >>>> values - expontial backoff with some maximum value seems about the >> right >>>> level of detail here. >>>> >>>> SIG-009: >>>> - To be clear, the conflicts only apply within a single administrative >>>> domain, right ? For example, if a client tells the same domain to >>>> alternately turn on/off mitigation for a given prefix, route flapping >> may >>>> occur. The same concern does not apply if a client tells two different >>>> administrative domains to respective turn mitigation on (domain 1) and >> off >>>> (domain 2). If so, can we clarify that (also in lieu of some of the >> multi- >>>> homing comments raised previously) ? >>>> >>>> SIG-010: >>>> - DOTS Client behind NAT. On one hand, it seems reasonable to have this >>>> requirement since clients for sure can be behind NATs, and with things >>>> like dynamic DNS, they can certainly be reachable. However, if we >> do >>>> want to allow for this scenario, and in particular for the DOTS client >> to >>>> have a private IP-address (potentially behind multiple NATs), then we >> have >>>> more work to do because it won't do the DOTS server any good to get a >>>> mitigation request referring to that private IP-address (or prefix). >>>> >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>>> >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>> . >>> From nobody Thu Oct 26 06:41:19 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E8113F588 for ; Thu, 26 Oct 2017 06:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNi17enyxPYQ for ; Thu, 26 Oct 2017 06:41:14 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F20138BCD for ; Thu, 26 Oct 2017 06:41:14 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 7D81F1C0C60; Thu, 26 Oct 2017 15:41:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4B69780079; Thu, 26 Oct 2017 15:41:12 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0361.001; Thu, 26 Oct 2017 15:41:12 +0200 From: To: Dave Dolson , "Konda, Tirumaleswar Reddy" , Flemming Andreasen , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AdNL+l99lPlWVCbZSf+V6RvD3Al94QAO8GKAACQhAQAAYkTigAABViKAAAB+EIAAAH6pgAAEb54AAAfog1AADcdhsP//Lswy///9vXD///ihsP//6eQQ Date: Thu, 26 Oct 2017 13:41:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05E978@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> , <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:41:18 -0000 Re-, Thanks Dave for the clarification.=20 That's indeed an option.=20 I do personally prefer to maintain the current design which allows for the = following with one single message from the client:=20 DOTS Client DOTS Server | | | GET / | | Token: 0x4a | Registration | Observe: 0 | +------------------------------>| | | | 2.05 Content | | Token: 0x4a | Notification = of | Observe: 12 | the current s= tate | status: "mitigation | | in progress" | |<------------------------------+ | 2.05 Content | | Token: 0x4a | Notification = upon | Observe: 44 | a state chan= ge | status: "mitigation | | complete" | |<------------------------------+ | 2.05 Content | | Token: 0x4a | Notification = upon | Observe: 60 | a state chang= e | status: "attack stopped" | |<------------------------------+ | | If we disallow this behavior, the client will need to regulatory poke the s= erver to get a status update. =20 Cheers, Med > -----Message d'origine----- > De=A0: Dave Dolson [mailto:ddolson@sandvine.com] > Envoy=E9=A0: jeudi 26 octobre 2017 15:13 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; Flemming > Andreasen; Jon Shallow; dots@ietf.org > Objet=A0: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >=20 > I'm not pushing for this. I saw the working group struggling with the > firewall/NAT problem, and offered a different way of thinking about it. > To be clear, my suggestion is to remove unsolicited messages from the > server to client. >=20 > -Dave >=20 >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Thursday, October 26, 2017 3:06 PM > To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon > Shallow; dots@ietf.org > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >=20 > Re-, >=20 > Not sure how to get rid of the constraint imposed by the NAT/FW timer, > Dave. >=20 > The current text says the following: >=20 > To provide a metric of signal health and distinguish an 'idle' signal > channel from a 'disconnected' or 'defunct' session, the DOTS agent > sends a heartbeat over the signal channel to maintain its half of the > channel. The DOTS agent similarly expects a heartbeat from its peer > DOTS agent, and may consider a session terminated in the extended > absence of a peer agent heartbeat. >=20 > Which covers your proposal. No? >=20 > Solicited messages from the server do not prevent from failures. Consider > the case where a DOTS server has to send a mitigation status update back > to the client, but the client didn't refreshed the state. Or when the NAT > fired out a mapping and assigns the external port to another host than th= e > DOTS client. >=20 > Did I missed something? >=20 > Thank you. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9=A0: jeudi 26 > > octobre 2017 14:50 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumalesw= ar > > Reddy; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet=A0: Re: > > [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > > My point was that if server status was solicited, keep-alive interval > > would be independent of firewall/NAT timeout. Keep-alives would be > > optional. > > > > Solicited means that client says "get status" vs. the server just > > sending updates. > > > > > > > > David Dolson > > Sandvine > > Original Message > > From: mohamed.boucadair@orange.com > > Sent: Thursday, October 26, 2017 2:11 PM > > To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon > > Shallow; dots@ietf.org > > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review > > (-06)) > > > > > > Hi Dave, > > > > The protocol does already support a mechanism to send keepalive > > messages every 30s (recommended value). > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 26 > > > octobre 2017 13:15 =C0 : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed > > > IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : RE: > > > [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > > > > I think there is another option to handle the NAT/firewall problems > > > by changing the protocol. > > > > > > If I understand correctly, currently the NAT and firewall need to be > > kept > > > open to permit unsolicited server packets. > > > > > > If the protocol is changed to require client polling of the server > > > updates, the NAT and firewall problems go away. > > > > > > -Dave > > > > > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda, > > Tirumaleswar > > > Reddy > > > Sent: Thursday, October 26, 2017 12:58 PM > > > To: mohamed.boucadair@orange.com; Flemming Andreasen; Jon Shallow; > > > dots@ietf.org > > > Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review > > > (-06)) > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com] > > > > Sent: Thursday, October 26, 2017 2:21 PM > > > > To: Konda, Tirumaleswar Reddy > > > > ; > > > > Flemming Andreasen ; Jon Shallow > > > ietf@jpshallow.com>; dots@ietf.org > > > > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review > > > > (-06)) > > > > > > > > Re-, > > > > > > > > I hear you. My take is that we don't need to recommend which > > > > companion "protocols/mechanisms" need to be supported for NAT/FW > > > > traversal purposes. Having a discussion at the same level in 8085 > > > > would be sufficient, IMHO. > > > > > > > > Let's focus on the simple built-in feature for NAT detect. > > > > > > I don't think the simple built-in feature is sufficient, DOTS client > > will > > > have to rely on mechanisms discussed in 8085 for both firewall and > > > NAT traversal. > > > > > > -Tiru > > > > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De : Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9 : jeudi 26 octobre 2017 10:36 =C0 : BOUCADAIR Mohamed > > > > > IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : > > > > > RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > > > > > > > > > But NATs are not the only problem, firewalls will also be most > > > > > likely present, and STUN helps discover both NATs and firewalls > > > > > and useful even in IPv6 networks to determine the keepalive > > > > > interval of > > > firewall. > > > > > > > > > > -Tiru > > > > > > > > > > > -----Original Message----- > > > > > > From: mohamed.boucadair@orange.com > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > Sent: Thursday, October 26, 2017 1:52 PM > > > > > > To: Konda, Tirumaleswar Reddy > > > > ; > > > > > > Flemming Andreasen ; Jon Shallow > > > > > ietf@jpshallow.com>; dots@ietf.org > > > > > > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements > > > > > > review > > > > > > (-06)) > > > > > > > > > > > > Tiru, > > > > > > > > > > > > Yes, STUN can be listed as part of the existing tools box > > > > > > (among the > > > > > lines of > > > > > > what is already discussed in 8085). > > > > > > > > > > > > I don't think that it makes sense to require STUN support by > > > > > > DOTS > > > > > clients. > > > > > > > > > > > > The proposal is to include a simple built-in feature in the > > > > > > DOTS > > > > > protocol itself > > > > > > that can help to detect NATs. The support of such feature > > > > > > will, e.g., > > > > > ease > > > > > > troubleshooting when connectivity problems are experienced on > > > > > > the path between a client and a server. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De : Konda, Tirumaleswar Reddy > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > Envoy=E9 : jeudi 26 octobre 2017 09:44 =C0 : BOUCADAIR Mohame= d > > > > > > > IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet > : > > > > > > > RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review > > > > > > > (-06)) > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > Sent: Tuesday, October 24, 2017 2:20 PM > > > > > > > > To: Flemming Andreasen ; Jon Shallow > > > > > > > > ; dots@ietf.org > > > > > > > > Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements > > > > > > > > review > > > > > > > > (-06)) > > > > > > > > > > > > > > > > Hi Flemming, all, > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > -----Message d'origine----- De : Flemming Andreasen > > > > > > > > > [mailto:fandreas@cisco.com] Envoy=E9 : > > > > > > > > > lundi > > > > > > > > > 23 octobre 2017 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Jo= n > > > > > > > > > Shallow; dots@ietf.org Objet : Re: DOTS & NAT (was RE: > > > > > > > > > [Dots] DOTS Requirements review (-06)) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/23/17 8:28 AM, mohamed.boucadair@orange.com wrote: > > > > > > > > > > Hi Jon, all, > > > > > > > > > > > > > > > > > > > > I agree with Flemming that "some more work" is needed. > > > > > > > > > > IMHO, this is a > > > > > > > > > typical discussion to include in a dedicated section in > > > > > > > > > the DOTS architecture I-D. > > > > > > > > > Agreed. > > > > > > > > > > >From a requirement standpoint, we don't need to > > > > > > > > > > >elaborate how the > > > > > > > > > protocols will fulfil it. SIG-10 does even a nice job by > > > > > > > > > citing > > > > > > > > > RFC8085 which points to NAT traversal mechanisms. One > > > > > > > > > could pick his/her favorite protocol from the list in > > > > > > > > > 8085 to discover the external IP address/prefix, if > > > > > > > > > needed. External IP addresses/prefixes can be IPv4 for a > > > > > > > > > NAT44 or NAT64, but can be > > > > > > > > > IPv6 prefixes for enterprises deploying NPTv6, and so on. > > > > > > > > > Part of the challenge here is that the attack target and > > > > > > > > > the DOTS client are not necessarily one and the same, > > > > > > > > > which makes it more difficult to determine the > > > > > > > > > public-facing IP-address/port under attack (at least if > > > > > > > > > the DOTS client is going to > > > > do it). > > > > > > > > > > > > > > > > [Med] This is exactly the kind of the discussion to have. > > > Thanks. > > > > > > > > > > > > > > > > With or without NAT, DOTS clients are assumed to be fed > > > > > > > > with the > > > > > > > internal > > > > > > > > target(s). This can be achieved by provisioning (likely) > > > > > > > > or by discovery > > > > > > > means > > > > > > > > (e.g., residential or small enterprise networks). > > > > > > > > > > > > > > > > Can we assume that the discovery of the external IP > > > > > > > > address/prefix/.. is > > > > > > > done > > > > > > > > by a DOTS client only if it is explicitly instructed to do > so? > > > > > > > > > > > > > > > > > > > > > > > > > > In some deployments, DOTS clients may be provisioned > > > > > > > > > > with the set of > > > > > > > > > internal resources, so there is no need for discovery. > > > > > > > > > > > > > > > > > > > > Also, as Jon mentioned, DOTS gateways can be of help > > > > > > > > > > to set the > > > > > > > > > appropriate IP addresses/prefixes/port numbers in the > > > > > > > > > presence of translators. > > > > > > > > > Agreed - but they still need a way to figure out the > > > > > > > > > private/public mapping for a given attack target. > > > > > > > > > > > > > > > > [Med] Because a DDoS attack is observed from the internal > > > > > > > > network, > > > > > > > > mapping(s) are necessarily maintained by the on-path > > > translator(s). > > > > > > > > Otherwise, the incoming attack traffic couldn't be > > > > > > > > forwarded to internal > > > > > > > hosts. > > > > > > > > This model assumes that the gateway is collocated with the > > NAT. > > > > > > > > So, the gateway can replace the internal IP address/prefix > > > > > > > > with the one > > > > > > > retrieves > > > > > > > > from the NAT mapping table. > > > > > > > > > > > > > > > > Do you see any issue with this scheme? > > > > > > > > > > > > > > > > > > An open question though would be to discuss if there > > > > > > > > > > is a value in > > > > > > > > > having a feature in the DOTS protocol to inform a DOTS > > > > > > > > > client that a NAT is detected on-path. This can be > > > > > > > > > presented as an information element returned by the > > > > > > > > > server to the client. This information can be, for > > > > > > > > > example, used by the client to adjust its HT interval, > > > > > > > > > adjust the internal IP addresses/prefixes to be > > > > protected, etc. > > > > > Opinions? > > > > > > > > > It sounds appealing, but it's very difficult to do this > > > > > > > > > reliably, and it's not just NATs that are an issue here; > > > > > > > > > Firewalls present similar challenges (and they may or > > > > > > > > > may not be NAT'ing individual > > > > > > flows). > > > > > > > > > > > > > > > > > > > > > > > > > [Med] I fully agree that firewalls detect is more complex. > > > > > > > > Let's put it > > > > > > > aside > > > > > > > > and focus on the NAT case. > > > > > > > > > > > > > > The presence and behavior of NAT and Firewall, and keepalive > > > > > > > interval can be determined using STUN (discussed in > > > > > > > https://tools.ietf.org/html/rfc5780). > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > We can consider many approaches to detect a NAT, e.g., > > > > > > > > > > > > > > > > (1) The DOTS client inserts in the core message the IP > > > > > > > > address/port it > > > > > > > uses to > > > > > > > > send the request to the DOTS server. Upon receipt of the > > > > > > > > request by the DOTS server, it checks if the enclosed IP > > > > > > > > address/port match the source > > > > > > > IP > > > > > > > > address/port of the received packet. If yes, the server > > > > > > > > sets in the > > > > > > > response a > > > > > > > > dedicated parameter to indicate that a translator is > > > > > > > > detected > > > > > > > > on- > > > > > path. > > > > > > > > > > > > > > > > (2) The DOTS server inserts systematically the source IP > > > > > > > > address/port in > > > > > > > a > > > > > > > > response to a message from a DOTS client. Upon receipt of > > > > > > > > that response, the DOTS client compares the enclosed > > > > > > > > address/port with the ones it used > > > > > > > to > > > > > > > > send the request to detect any mismatch. > > > > > > > > > > > > > > > > > > > > > > > > > -- Flemming > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > >> -----Message d'origine----- De : Dots > > > > > > > > > >> [mailto:dots-bounces@ietf.org] De la part de Jon > > > > > > > > > >> Shallow Envoy=E9 : lundi 23 octobre 2017 13:18 =C0 : > > > > > > > > > >> 'Flemming Andreasen'; dots@ietf.org Objet : Re: > > > > > > > > > >> [Dots] DOTS Requirements review (-06) > > > > > > > > > >> > > > > > > > > > >> Hi Flemming, > > > > > > > > > >> > > > > > > > > > >> The way my mind works is to think of a practical > > > > > > > > > >> situation and see if things fit. > > > > > > > > > >> > > > > > > > > > >> As I read SIG-010, there could be a DOTS client with > > > > > > > > > >> a management IP address that is RFC1918 - this client > > > > > > > > > >> could be monitoring Netflow information and can > > > > > > > > > >> request mitigation for the appropriate public IPs > > > > > > > > > that > > > > > > > > > >> are being monitored. So SIG-010 is needed for this > > > > > > > > > >> use > > > case. > > > > > > > > > >> > > > > > > > > > >> It is the responsibility of the DOTS server as to > > > > > > > > > >> whether it accepts a mitigation request for a > > > > > > > > > >> particular target ip (or domain > > > > > > > etc.) or > > > > > > > > not. > > > > > > > > > >> > > > > > > > > > >> If there is going to be a NAT border where public IPs > > > > > > > > > >> are mapped into private IPs (and vice versa), I would > > > > > > > > > >> then expect there to be a DOTS gateway between these > > > > > > > > > >> 2 zones, and it is the responsibility of the DOTS > > > > > > > > > >> gateway to do any target-ip > > > > > mappings. > > > > > > > > > >> > > > > > > > > > >> Regards > > > > > > > > > >> > > > > > > > > > >> Jon > > > > > > > > > >> > > > > > > > > > >> -----Original Message----- > > > > > > > > > >> From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] > > > > > > > > > >> On Behalf Of Flemming Andreasen > > > > > > > > > >> Sent: 22 October 2017 20:17 > > > > > > > > > >> To: dots; draft-ietf-dots-requirements@ietf.org > > > > > > > > > >> Subject: [Dots] DOTS Requirements review (-06) > > > > > > > > > >> > > > > > > > > > >> Greetings > > > > > > > > > >> > > > > > > > > > >> I have reviewed the latest version of the DOTS > > > > > > > > > >> requirements draft > > > > > > > > > >> (https://www.ietf.org/id/draft-ietf-dots-requirements > > > > > > > > > >> - > > > 06.txt). > > > > > > > > > >> In > > > > > > > > > general, > > > > > > > > > >> I think the draft is in good shape with only a few > > > > > > > > > >> edits required, so I hope we can move to WGLC soon. I > > > > > > > > > >> have a few comments below (of which > > > > > > > > > the > > > > > > > > > >> NAT one is the only real substantial one). I have > > > > > > > > > >> also submitted a pull request with a few nit fixes on > GitHub: > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> Section 1.2 > > > > > > > > > >> - The definition of "DOTS Signal" is slightly > > > > > > > > > >> inconsistent with the respective "Client Signal" and > > > "Server Signal" definitions. > > > > > > > > > >> > > > > > > > > > >> SIG-005: > > > > > > > > > >> - Not clear that always requiring "number of packets" > > > > > > > > > >> metrics is meaningful. Consider TCP-based attacks for > > > > > > > > > >> example. Number of bytes may always be ok - above and > > > > > > > > > >> beyond that it should probably be extensible and/or > > > > > > > > > >> attack > > > > dependent. > > > > > > > > > >> - I don't think the requirements document should get > > > > > > > > > >> into specifying > > > > > > > > > timer > > > > > > > > > >> values - expontial backoff with some maximum value > > > > > > > > > >> seems about the > > > > > > > > > right > > > > > > > > > >> level of detail here. > > > > > > > > > >> > > > > > > > > > >> SIG-009: > > > > > > > > > >> - To be clear, the conflicts only apply within a > > > > > > > > > >> single administrative domain, right ? For example, if > > > > > > > > > >> a client tells the same domain to alternately turn > > > > > > > > > >> on/off mitigation for a given prefix, route flapping > > > > > > > > > may > > > > > > > > > >> occur. The same concern does not apply if a client > > > > > > > > > >> tells two different administrative domains to > > > > > > > > > >> respective turn mitigation on (domain 1) and > > > > > > > > > off > > > > > > > > > >> (domain 2). If so, can we clarify that (also in lieu > > > > > > > > > >> of some of the > > > > > > > > > multi- > > > > > > > > > >> homing comments raised previously) ? > > > > > > > > > >> > > > > > > > > > >> SIG-010: > > > > > > > > > >> - DOTS Client behind NAT. On one hand, it seems > > > > > > > > > >> reasonable to have this requirement since clients for > > > > > > > > > >> sure can be behind NATs, and > > > > > > > with > > > > > > > > things > > > > > > > > > >> like dynamic DNS, they can certainly be reachable. > > > However, > > > > > if > > > > > > > we > > > > > > > > > do > > > > > > > > > >> want to allow for this scenario, and in particular > > > > > > > > > >> for the DOTS client > > > > > > > > > to > > > > > > > > > >> have a private IP-address (potentially behind > > > > > > > > > >> multiple NATs), then we > > > > > > > > > have > > > > > > > > > >> more work to do because it won't do the DOTS server > > > > > > > > > >> any good to get a mitigation request referring to > > > > > > > > > >> that private IP-address (or > > > > > > > prefix). > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> Thanks > > > > > > > > > >> > > > > > > > > > >> -- Flemming > > > > > > > > > >> > > > > > > > > > >> _______________________________________________ > > > > > > > > > >> Dots mailing list > > > > > > > > > >> Dots@ietf.org > > > > > > > > > >> https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > >> > > > > > > > > > >> _______________________________________________ > > > > > > > > > >> Dots mailing list > > > > > > > > > >> Dots@ietf.org > > > > > > > > > >> https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Oct 26 06:46:32 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F6413F4A9 for ; Thu, 26 Oct 2017 06:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or-UohIJEuEJ for ; Thu, 26 Oct 2017 06:46:26 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B547413F59D for ; Thu, 26 Oct 2017 06:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18320; q=dns/txt; s=iport; t=1509025586; x=1510235186; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=4zz9aNkEYqOQlugCjF7P4sJw8Nf00nwevjP5cphyXsM=; b=jOaTj8SCnUOCBW/z1xjGV9306qHAcifxMemBj6D+Rl7qfs4OZ+YgVFWT R5NkGyJyqGPZm5Y5lJF5zK15DORj0xolE98HvGA714758FfjZ7Vy/X6Vk 6dqKVWWb7lxr4ukmVYJ6vzAKkEOVJJ94i+SD/1x9RoRifkTXZHmBsT5CI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgAADk5fFZ/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbieDeoofjw+BVCZ8lUSCEQoYC4UYAoRAPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUdAQEBAQMBASEPAQU2FwQLDgMBAwEBAQICIwMCAicfAwYIBgEMBgIBAReJe?= =?us-ascii?q?A0QqUyCJ4QVAYZeAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4IbBIEqXYFQgWk?= =?us-ascii?q?pC4JBNYRvgyqCYQWhe4dlgReLfYIVhX+DXiSHFYopi2GBOR84gWhVJRVJgmSCW?= =?us-ascii?q?QMcgSwBViU2jEYBAQE?= X-IronPort-AV: E=Sophos;i="5.43,434,1503360000"; d="scan'208";a="21914900" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Oct 2017 13:46:25 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9QDkO7C031848; Thu, 26 Oct 2017 13:46:24 GMT To: Dave Dolson , "mohamed.boucadair@orange.com" , "Konda, Tirumaleswar Reddy" , Jon Shallow , "dots@ietf.org" References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Flemming Andreasen Message-ID: <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> Date: Thu, 26 Oct 2017 09:46:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:46:30 -0000 As I have stated several times before, I'm not all that comfortable with the current requirement around always sending keep-alives, whether attacks are in progress or now. My concerns are around scalability/cost of the overall solution, so I think it's worth considering during peace-time at least. -- Flemming On 10/26/17 9:13 AM, Dave Dolson wrote: > I'm not pushing for this. I saw the working group struggling with the firewall/NAT problem, and offered a different way of thinking about it. > To be clear, my suggestion is to remove unsolicited messages from the server to client. > > -Dave > > > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Thursday, October 26, 2017 3:06 PM > To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon Shallow; dots@ietf.org > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > > Re-, > > Not sure how to get rid of the constraint imposed by the NAT/FW timer, Dave. > > The current text says the following: > > To provide a metric of signal health and distinguish an 'idle' signal > channel from a 'disconnected' or 'defunct' session, the DOTS agent > sends a heartbeat over the signal channel to maintain its half of the > channel. The DOTS agent similarly expects a heartbeat from its peer > DOTS agent, and may consider a session terminated in the extended > absence of a peer agent heartbeat. > > Which covers your proposal. No? > > Solicited messages from the server do not prevent from failures. Consider the case where a DOTS server has to send a mitigation status update back to the client, but the client didn't refreshed the state. Or when the NAT fired out a mapping and assigns the external port to another host than the DOTS client. > > Did I missed something? > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Dave Dolson [mailto:ddolson@sandvine.com] Envoyé : jeudi 26 >> octobre 2017 14:50 À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar >> Reddy; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : Re: >> [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >> >> My point was that if server status was solicited, keep-alive interval >> would be independent of firewall/NAT timeout. Keep-alives would be >> optional. >> >> Solicited means that client says "get status" vs. the server just >> sending updates. >> >> >> >> David Dolson >> Sandvine >> Original Message >> From: mohamed.boucadair@orange.com >> Sent: Thursday, October 26, 2017 2:11 PM >> To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon >> Shallow; dots@ietf.org >> Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review >> (-06)) >> >> >> Hi Dave, >> >> The protocol does already support a mechanism to send keepalive >> messages every 30s (recommended value). >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Dave Dolson [mailto:ddolson@sandvine.com] Envoyé : jeudi 26 >>> octobre 2017 13:15 À : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed >>> IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : RE: >>> [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >>> >>> I think there is another option to handle the NAT/firewall problems >>> by changing the protocol. >>> >>> If I understand correctly, currently the NAT and firewall need to be >> kept >>> open to permit unsolicited server packets. >>> >>> If the protocol is changed to require client polling of the server >>> updates, the NAT and firewall problems go away. >>> >>> -Dave >>> >>> >>> -----Original Message----- >>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda, >> Tirumaleswar >>> Reddy >>> Sent: Thursday, October 26, 2017 12:58 PM >>> To: mohamed.boucadair@orange.com; Flemming Andreasen; Jon Shallow; >>> dots@ietf.org >>> Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review >>> (-06)) >>> >>>> -----Original Message----- >>>> From: mohamed.boucadair@orange.com >>>> [mailto:mohamed.boucadair@orange.com] >>>> Sent: Thursday, October 26, 2017 2:21 PM >>>> To: Konda, Tirumaleswar Reddy >>>> ; >>>> Flemming Andreasen ; Jon Shallow >>> ietf@jpshallow.com>; dots@ietf.org >>>> Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review >>>> (-06)) >>>> >>>> Re-, >>>> >>>> I hear you. My take is that we don't need to recommend which >>>> companion "protocols/mechanisms" need to be supported for NAT/FW >>>> traversal purposes. Having a discussion at the same level in 8085 >>>> would be sufficient, IMHO. >>>> >>>> Let's focus on the simple built-in feature for NAT detect. >>> I don't think the simple built-in feature is sufficient, DOTS client >> will >>> have to rely on mechanisms discussed in 8085 for both firewall and >>> NAT traversal. >>> >>> -Tiru >>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Konda, Tirumaleswar Reddy >>>>> [mailto:TirumaleswarReddy_Konda@McAfee.com] >>>>> Envoyé : jeudi 26 octobre 2017 10:36 À : BOUCADAIR Mohamed >>>>> IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : >>>>> RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >>>>> >>>>> But NATs are not the only problem, firewalls will also be most >>>>> likely present, and STUN helps discover both NATs and firewalls >>>>> and useful even in IPv6 networks to determine the keepalive >>>>> interval of >>> firewall. >>>>> -Tiru >>>>> >>>>>> -----Original Message----- >>>>>> From: mohamed.boucadair@orange.com >>>>>> [mailto:mohamed.boucadair@orange.com] >>>>>> Sent: Thursday, October 26, 2017 1:52 PM >>>>>> To: Konda, Tirumaleswar Reddy >>>> ; >>>>>> Flemming Andreasen ; Jon Shallow >>>>> ietf@jpshallow.com>; dots@ietf.org >>>>>> Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements >>>>>> review >>>>>> (-06)) >>>>>> >>>>>> Tiru, >>>>>> >>>>>> Yes, STUN can be listed as part of the existing tools box >>>>>> (among the >>>>> lines of >>>>>> what is already discussed in 8085). >>>>>> >>>>>> I don't think that it makes sense to require STUN support by >>>>>> DOTS >>>>> clients. >>>>>> The proposal is to include a simple built-in feature in the >>>>>> DOTS >>>>> protocol itself >>>>>> that can help to detect NATs. The support of such feature >>>>>> will, e.g., >>>>> ease >>>>>> troubleshooting when connectivity problems are experienced on >>>>>> the path between a client and a server. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Konda, Tirumaleswar Reddy >>>>>>> [mailto:TirumaleswarReddy_Konda@McAfee.com] >>>>>>> Envoyé : jeudi 26 octobre 2017 09:44 À : BOUCADAIR Mohamed >>>>>>> IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : >>>>>>> RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review >>>>>>> (-06)) >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of >>>>>>>> mohamed.boucadair@orange.com >>>>>>>> Sent: Tuesday, October 24, 2017 2:20 PM >>>>>>>> To: Flemming Andreasen ; Jon Shallow >>>>>>>> ; dots@ietf.org >>>>>>>> Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements >>>>>>>> review >>>>>>>> (-06)) >>>>>>>> >>>>>>>> Hi Flemming, all, >>>>>>>> >>>>>>>> Please see inline. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>> >>>>>>>>> -----Message d'origine----- De : Flemming Andreasen >>>>>>>>> [mailto:fandreas@cisco.com] Envoyé : >>>>>>>>> lundi >>>>>>>>> 23 octobre 2017 17:36 À : BOUCADAIR Mohamed IMT/OLN; Jon >>>>>>>>> Shallow; dots@ietf.org Objet : Re: DOTS & NAT (was RE: >>>>>>>>> [Dots] DOTS Requirements review (-06)) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/23/17 8:28 AM, mohamed.boucadair@orange.com wrote: >>>>>>>>>> Hi Jon, all, >>>>>>>>>> >>>>>>>>>> I agree with Flemming that "some more work" is needed. >>>>>>>>>> IMHO, this is a >>>>>>>>> typical discussion to include in a dedicated section in >>>>>>>>> the DOTS architecture I-D. >>>>>>>>> Agreed. >>>>>>>>>> >From a requirement standpoint, we don't need to >>>>>>>>>>> elaborate how the >>>>>>>>> protocols will fulfil it. SIG-10 does even a nice job by >>>>>>>>> citing >>>>>>>>> RFC8085 which points to NAT traversal mechanisms. One >>>>>>>>> could pick his/her favorite protocol from the list in >>>>>>>>> 8085 to discover the external IP address/prefix, if >>>>>>>>> needed. External IP addresses/prefixes can be IPv4 for a >>>>>>>>> NAT44 or NAT64, but can be >>>>>>>>> IPv6 prefixes for enterprises deploying NPTv6, and so on. >>>>>>>>> Part of the challenge here is that the attack target and >>>>>>>>> the DOTS client are not necessarily one and the same, >>>>>>>>> which makes it more difficult to determine the >>>>>>>>> public-facing IP-address/port under attack (at least if >>>>>>>>> the DOTS client is going to >>>> do it). >>>>>>>> [Med] This is exactly the kind of the discussion to have. >>> Thanks. >>>>>>>> With or without NAT, DOTS clients are assumed to be fed >>>>>>>> with the >>>>>>> internal >>>>>>>> target(s). This can be achieved by provisioning (likely) >>>>>>>> or by discovery >>>>>>> means >>>>>>>> (e.g., residential or small enterprise networks). >>>>>>>> >>>>>>>> Can we assume that the discovery of the external IP >>>>>>>> address/prefix/.. is >>>>>>> done >>>>>>>> by a DOTS client only if it is explicitly instructed to do so? >>>>>>>> >>>>>>>> >>>>>>>>>> In some deployments, DOTS clients may be provisioned >>>>>>>>>> with the set of >>>>>>>>> internal resources, so there is no need for discovery. >>>>>>>>>> Also, as Jon mentioned, DOTS gateways can be of help >>>>>>>>>> to set the >>>>>>>>> appropriate IP addresses/prefixes/port numbers in the >>>>>>>>> presence of translators. >>>>>>>>> Agreed - but they still need a way to figure out the >>>>>>>>> private/public mapping for a given attack target. >>>>>>>> [Med] Because a DDoS attack is observed from the internal >>>>>>>> network, >>>>>>>> mapping(s) are necessarily maintained by the on-path >>> translator(s). >>>>>>>> Otherwise, the incoming attack traffic couldn't be >>>>>>>> forwarded to internal >>>>>>> hosts. >>>>>>>> This model assumes that the gateway is collocated with the >> NAT. >>>>>>>> So, the gateway can replace the internal IP address/prefix >>>>>>>> with the one >>>>>>> retrieves >>>>>>>> from the NAT mapping table. >>>>>>>> >>>>>>>> Do you see any issue with this scheme? >>>>>>>> >>>>>>>>>> An open question though would be to discuss if there >>>>>>>>>> is a value in >>>>>>>>> having a feature in the DOTS protocol to inform a DOTS >>>>>>>>> client that a NAT is detected on-path. This can be >>>>>>>>> presented as an information element returned by the >>>>>>>>> server to the client. This information can be, for >>>>>>>>> example, used by the client to adjust its HT interval, >>>>>>>>> adjust the internal IP addresses/prefixes to be >>>> protected, etc. >>>>> Opinions? >>>>>>>>> It sounds appealing, but it's very difficult to do this >>>>>>>>> reliably, and it's not just NATs that are an issue here; >>>>>>>>> Firewalls present similar challenges (and they may or >>>>>>>>> may not be NAT'ing individual >>>>>> flows). >>>>>>>> [Med] I fully agree that firewalls detect is more complex. >>>>>>>> Let's put it >>>>>>> aside >>>>>>>> and focus on the NAT case. >>>>>>> The presence and behavior of NAT and Firewall, and keepalive >>>>>>> interval can be determined using STUN (discussed in >>>>>>> https://tools.ietf.org/html/rfc5780). >>>>>>> >>>>>>> -Tiru >>>>>>> >>>>>>>> We can consider many approaches to detect a NAT, e.g., >>>>>>>> >>>>>>>> (1) The DOTS client inserts in the core message the IP >>>>>>>> address/port it >>>>>>> uses to >>>>>>>> send the request to the DOTS server. Upon receipt of the >>>>>>>> request by the DOTS server, it checks if the enclosed IP >>>>>>>> address/port match the source >>>>>>> IP >>>>>>>> address/port of the received packet. If yes, the server >>>>>>>> sets in the >>>>>>> response a >>>>>>>> dedicated parameter to indicate that a translator is >>>>>>>> detected >>>>>>>> on- >>>>> path. >>>>>>>> (2) The DOTS server inserts systematically the source IP >>>>>>>> address/port in >>>>>>> a >>>>>>>> response to a message from a DOTS client. Upon receipt of >>>>>>>> that response, the DOTS client compares the enclosed >>>>>>>> address/port with the ones it used >>>>>>> to >>>>>>>> send the request to detect any mismatch. >>>>>>>> >>>>>>>> >>>>>>>>> -- Flemming >>>>>>>>> >>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Med >>>>>>>>>> >>>>>>>>>>> -----Message d'origine----- De : Dots >>>>>>>>>>> [mailto:dots-bounces@ietf.org] De la part de Jon >>>>>>>>>>> Shallow Envoyé : lundi 23 octobre 2017 13:18 À : >>>>>>>>>>> 'Flemming Andreasen'; dots@ietf.org Objet : Re: >>>>>>>>>>> [Dots] DOTS Requirements review (-06) >>>>>>>>>>> >>>>>>>>>>> Hi Flemming, >>>>>>>>>>> >>>>>>>>>>> The way my mind works is to think of a practical >>>>>>>>>>> situation and see if things fit. >>>>>>>>>>> >>>>>>>>>>> As I read SIG-010, there could be a DOTS client with >>>>>>>>>>> a management IP address that is RFC1918 - this client >>>>>>>>>>> could be monitoring Netflow information and can >>>>>>>>>>> request mitigation for the appropriate public IPs >>>>>>>>> that >>>>>>>>>>> are being monitored. So SIG-010 is needed for this >>>>>>>>>>> use >>> case. >>>>>>>>>>> It is the responsibility of the DOTS server as to >>>>>>>>>>> whether it accepts a mitigation request for a >>>>>>>>>>> particular target ip (or domain >>>>>>> etc.) or >>>>>>>> not. >>>>>>>>>>> If there is going to be a NAT border where public IPs >>>>>>>>>>> are mapped into private IPs (and vice versa), I would >>>>>>>>>>> then expect there to be a DOTS gateway between these >>>>>>>>>>> 2 zones, and it is the responsibility of the DOTS >>>>>>>>>>> gateway to do any target-ip >>>>> mappings. >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Jon >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] >>>>>>>>>>> On Behalf Of Flemming Andreasen >>>>>>>>>>> Sent: 22 October 2017 20:17 >>>>>>>>>>> To: dots; draft-ietf-dots-requirements@ietf.org >>>>>>>>>>> Subject: [Dots] DOTS Requirements review (-06) >>>>>>>>>>> >>>>>>>>>>> Greetings >>>>>>>>>>> >>>>>>>>>>> I have reviewed the latest version of the DOTS >>>>>>>>>>> requirements draft >>>>>>>>>>> (https://www.ietf.org/id/draft-ietf-dots-requirements >>>>>>>>>>> - >>> 06.txt). >>>>>>>>>>> In >>>>>>>>> general, >>>>>>>>>>> I think the draft is in good shape with only a few >>>>>>>>>>> edits required, so I hope we can move to WGLC soon. I >>>>>>>>>>> have a few comments below (of which >>>>>>>>> the >>>>>>>>>>> NAT one is the only real substantial one). I have >>>>>>>>>>> also submitted a pull request with a few nit fixes on GitHub: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Section 1.2 >>>>>>>>>>> - The definition of "DOTS Signal" is slightly >>>>>>>>>>> inconsistent with the respective "Client Signal" and >>> "Server Signal" definitions. >>>>>>>>>>> SIG-005: >>>>>>>>>>> - Not clear that always requiring "number of packets" >>>>>>>>>>> metrics is meaningful. Consider TCP-based attacks for >>>>>>>>>>> example. Number of bytes may always be ok - above and >>>>>>>>>>> beyond that it should probably be extensible and/or >>>>>>>>>>> attack >>>> dependent. >>>>>>>>>>> - I don't think the requirements document should get >>>>>>>>>>> into specifying >>>>>>>>> timer >>>>>>>>>>> values - expontial backoff with some maximum value >>>>>>>>>>> seems about the >>>>>>>>> right >>>>>>>>>>> level of detail here. >>>>>>>>>>> >>>>>>>>>>> SIG-009: >>>>>>>>>>> - To be clear, the conflicts only apply within a >>>>>>>>>>> single administrative domain, right ? For example, if >>>>>>>>>>> a client tells the same domain to alternately turn >>>>>>>>>>> on/off mitigation for a given prefix, route flapping >>>>>>>>> may >>>>>>>>>>> occur. The same concern does not apply if a client >>>>>>>>>>> tells two different administrative domains to >>>>>>>>>>> respective turn mitigation on (domain 1) and >>>>>>>>> off >>>>>>>>>>> (domain 2). If so, can we clarify that (also in lieu >>>>>>>>>>> of some of the >>>>>>>>> multi- >>>>>>>>>>> homing comments raised previously) ? >>>>>>>>>>> >>>>>>>>>>> SIG-010: >>>>>>>>>>> - DOTS Client behind NAT. On one hand, it seems >>>>>>>>>>> reasonable to have this requirement since clients for >>>>>>>>>>> sure can be behind NATs, and >>>>>>> with >>>>>>>> things >>>>>>>>>>> like dynamic DNS, they can certainly be reachable. >>> However, >>>>> if >>>>>>> we >>>>>>>>> do >>>>>>>>>>> want to allow for this scenario, and in particular >>>>>>>>>>> for the DOTS client >>>>>>>>> to >>>>>>>>>>> have a private IP-address (potentially behind >>>>>>>>>>> multiple NATs), then we >>>>>>>>> have >>>>>>>>>>> more work to do because it won't do the DOTS server >>>>>>>>>>> any good to get a mitigation request referring to >>>>>>>>>>> that private IP-address (or >>>>>>> prefix). >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> -- Flemming >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Dots mailing list >>>>>>>>>>> Dots@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Dots mailing list >>>>>>>>>>> Dots@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots >>>>>>>>>> . >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dots mailing list >>>>>>>> Dots@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dots >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots > . > From nobody Thu Oct 26 06:55:01 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE51C13F588 for ; Thu, 26 Oct 2017 06:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx5G32DWQwW1 for ; Thu, 26 Oct 2017 06:54:58 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 B891D13F59C for ; Thu, 26 Oct 2017 06:54:57 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e7icY-0008WK-V6 for ietf-supjps-dots@ietf.org; Thu, 26 Oct 2017 14:54:55 +0100 From: "Jon Shallow" To: Date: Thu, 26 Oct 2017 14:54:54 +0100 Message-ID: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01D34E6A.627D8710" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdNOYfsbT1udcdezQbua6sZ/aw7wYA== Content-Language: en-gb Archived-At: Subject: [Dots] DOTS signal and resource path discovery X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:55:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006D_01D34E6A.627D8710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there Following on from the recent virtual conference with discussions about what should be the signal request path (should .wellknown be included in it etc.). RFC7252 7.1 Service Discovery "The CoAP default port number 5683 MUST be supported by a server that offers resources for resource discovery (see Section 7.2 below) and SHOULD be supported for providing access to other resources. The default port number 5684 for DTLS-secured CoAP MAY be supported by a server for resource discovery and for providing access to other resources. In addition, other endpoints may be hosted at other ports, e.g., in the dynamic port space." DOTS is not hosting non (D)TLS COAP, and so we will be breaking the MUST for port 5683. I propose that we do the following for the signal channel spec and support resource discovery. 1) Update the 2 paths (signal and configuration) in the specification, when can then be the default values. Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "signal" To Uri-Path: "v1" << We are v1 as described in the text Uri-Path: "dots-signal" Uri-Path: "mitigation" << overloaded use of signal, this is the mitigate part of dots-signal And Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "config" To Uri-Path: "v1" Uri-Path: "dots-signal" Uri-Path: "configuration" 2) Add in the following =============================================== 5.7 Resource Discovery As per [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support the CoRe Link Format of discoverable resource as described in [RFC6690], except where fully manual configuration is desired. The two discoverable resources that SHOULD be available to a DOTS client are "mitigation" and "configuration". If the appropriate URI paths are returned, the DOTS client MUST use them, overriding any default configuration. A DOTS client SHOULD do a resource discovery, which is done by a GET request to "/.wellknown/core" Header: GET (Code=0.01) Uri-Host: "host" Uri-Path: ".wellknown" Uri-Path: "core" Figure xxx: GET to retrieve dots-signal resources Content-Format:application/link-format ;rt="mitigation";title="DOTS Signal Mitigation";ct=60, ;rt="configuration";title="DOTS Signal Configuration";ct=60 Figure yyy: Example response to GET to retrieve dots-signal resources As to CoAP being on different ports on the server hosting DOTS server (or DOTS gateway), this may have to be configurable in the DOTS clients, or configurable on the Data Channel as an extension to "The DOTS client will perform the root resource discovery procedure discussed in Section 3.1 of [RFC8040] to determine the root of the RESTCONF API. After discovering the RESTCONF API root, the DOTS client uses this value as the initial part of the path in the request URI, in any subsequent request to the DOTS server. The DOTS server may support retrieval of the YANG modules it supports (Section 3.7 in [RFC8040]), for example, a DOTS client may use RESTCONF to retrieve the company proprietary YANG modules supported by the DOTS server." Regards Jon ------=_NextPart_000_006D_01D34E6A.627D8710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there

 

Following on from the recent virtual conference with = discussions about what should be the signal request path (should = .wellknown be included in it etc.).

 

RFC7252 7.1 = Service Discovery

“The CoAP = default port number 5683 MUST be supported by a server = that

   offers resources = for resource discovery (see Section 7.2 below) and

   SHOULD be supported for providing access = to other resources.  The

   default port number 5684 for DTLS-secured = CoAP MAY be supported by a

   server for resource discovery and for = providing access to other

   resources.  In addition, other = endpoints may be hosted at other

   ports, e.g., in the dynamic port = space.”

 

DOTS is not hosting non (D)TLS COAP, and so we will be = breaking the MUST for port 5683.  I propose that we do the = following for the signal channel spec and support resource = discovery.

 

1)      = Update the 2 paths (signal and configuration) in = the specification, when can then be the default values.

     Uri-Path: = "version"

     Uri-Path: = "dots-signal"

     Uri-Path: = "signal"

To

     Uri-Path: = "v1" =             &= nbsp;           &n= bsp;    << We are v1 as described in the = text

     = Uri-Path: "dots-signal"

     Uri-Path: = "mitigation"        &nb= sp;        << overloaded use of = signal, this is the mitigate part of dots-signal

         &= nbsp;     And

     Uri-Path: = "version"

     Uri-Path: = "dots-signal"

     Uri-Path: = "config"

To

     Uri-Path: = "v1"

     Uri-Path: = "dots-signal"

     Uri-Path: = "configuration"

2)      = Add in the following

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

5.7 Resource = Discovery

 

As per [RFC7252 7.2 Resource Discovery] the DOTS = server SHOULD support the CoRe Link Format of discoverable resource as = described in [RFC6690], except where fully manual configuration is = desired.

 

The two discoverable resources that SHOULD be = available to a DOTS client are “mitigation” and = “configuration”.  If the appropriate URI paths are = returned, the DOTS client MUST use them, overriding any default = configuration.  A DOTS client SHOULD do a resource discovery, which = is done by a GET request to = “/.wellknown/core”

 

Header: GET = (Code=3D0.01)

     Uri-Host: = "host"

     Uri-Path: = ".wellknown"

     Uri-Path: = "core"

 

Figure xxx: = GET to retrieve dots-signal resources

 

Content-Format:application/link-format

 

<v1/dots-signal/mitigation>;rt=3D"mitigation= ";title=3D"DOTS Signal = Mitigation";ct=3D60,

</v1/dots-signal/configuration>;rt=3D"config= uration";title=3D"DOTS Signal = Configuration";ct=3D60

 

Figure yyy: = Example response to GET to retrieve dots-signal = resources

 

 

As to CoAP = being on different ports on the server hosting DOTS server (or DOTS = gateway), this may have to be configurable in the DOTS clients, or = configurable on the Data Channel as an extension to

 

“The = DOTS client will perform the root resource discovery = procedure

   discussed in = Section 3.1 of [RFC8040] to determine the root of the

   RESTCONF API.  After discovering the = RESTCONF API root, the DOTS

   client uses this value as the initial = part of the path in the request

   URI, in any subsequent request to the = DOTS server.  The DOTS server

   may support retrieval of the YANG modules = it supports (Section 3.7 in

   [RFC8040]), for example, a DOTS client = may use RESTCONF to retrieve

   the company proprietary YANG modules = supported by the DOTS server.”

 

Regards

 

Jon

 

------=_NextPart_000_006D_01D34E6A.627D8710-- From nobody Thu Oct 26 07:01:56 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F358C13F59F for ; Thu, 26 Oct 2017 07:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXek8MFmFkus for ; Thu, 26 Oct 2017 07:01:46 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 C77C913F59E for ; Thu, 26 Oct 2017 07:01:45 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id n22so2515516uaj.13 for ; Thu, 26 Oct 2017 07:01:45 -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=b2g0r7xCwWLAGcmjPiHRuOctqYOQpgDQuFoOJsfaisw=; b=RNECoTRoKgwkv86+0tbCjze7NRRdf63pH7STEhbxLgRhrke/elgsrG5Jp+ghjywNMk 6r8LZY3SAgCJktR5OfUxgRTgWuXI1so8arhfC8VQ5+QHujcXHbURbSZqwLpE6phlsjB+ maz56jQBcndoRV68f20nvL7jQrVTlo3F09gI4io2DjU4GXAWvarLS5+US61w8F8Zyc+1 H4s72ob15w9XEk8LwHK70hvbMVJnczXhMy2q04HrKgPTQOcR4V6AIY7p/nMggQc2g3sl 9ogELjzNt8TfF05aHz5jbAK+aBMAtUmQY8qGP7diJzT44/JjvDIqeG5tCkHCmFWC/lvs 3BxA== 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=b2g0r7xCwWLAGcmjPiHRuOctqYOQpgDQuFoOJsfaisw=; b=Ozn3676S5M6bzmLdQfI1zLtCHZuDfFl8ihLyV/uEPX5kyhEdfOW4YzvwBRVPEywtER cVlJbh+wnVUkVeNS2Df94kd+2nNEWZPrVZp97KF94wpty2I5JDn3CsV/8hygeQ+kiZ5D 5om8n3qr/9jY3Iri29U7AOkmvEQ4hXkKTUw8QMTQZJd0uXSyyvpgIMprQJMDYsy4ugkq pA3Mv+KxzU08PXfcIcFZ0BEFRoAdsAOuxmHy+aL4U37cBnG0EAVp6GL0xO7mtSNMYT/I Ns8mRVSu11bSWHW+gNgqkukgSsfUpg4jMHLzZoMPGI8y1uAo0PqzlOxHixEpa+jhMi9R Xyww== X-Gm-Message-State: AMCzsaVZm8lCgv+JIeLoxgz2eSXCqnWDVtLd6q0DmsRe2nXunvu+E+zm G3k/TMxspMeofQ3YgylJpg4Nz3ZUaRw5eYjUThTHQA== X-Google-Smtp-Source: ABhQp+S0+/Bqo1Oa0UfxJCjlCdGv4dJsvI0W0OLIBTIk6zxk1Xi1t+1tGZ4T7+AjiquJ68fLiub8egs9NxRz+c7ywNQ= X-Received: by 10.176.64.131 with SMTP id i3mr4348872uad.195.1509026504567; Thu, 26 Oct 2017 07:01:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.71.134 with HTTP; Thu, 26 Oct 2017 07:01:43 -0700 (PDT) Received: by 10.176.71.134 with HTTP; Thu, 26 Oct 2017 07:01:43 -0700 (PDT) In-Reply-To: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> References: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> From: Artyom Gavrichenkov Date: Thu, 26 Oct 2017 17:01:43 +0300 Message-ID: To: Jon Shallow Cc: dots@ietf.org Content-Type: multipart/alternative; boundary="94eb2c12370ec2ef4f055c739c47" Archived-At: Subject: Re: [Dots] DOTS signal and resource path discovery X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 14:01:49 -0000 --94eb2c12370ec2ef4f055c739c47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, It's not ".wellknown", it's ".well-known", note "-". | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 26 =D0=BE=D0=BA=D1=82. 2017 =D0=B3. 4:55 =D0=9F=D0=9F =D0=BF=D0=BE=D0=BB=D1= =8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Jon Shallow" < supjps-ietf@jpshallow.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: Hi there Following on from the recent virtual conference with discussions about what should be the signal request path (should .wellknown be included in it etc.). RFC7252 7.1 Service Discovery =E2=80=9CThe CoAP default port number 5683 MUST be supported by a server th= at offers resources for resource discovery (see Section 7.2 below) and SHOULD be supported for providing access to other resources. The default port number 5684 for DTLS-secured CoAP MAY be supported by a server for resource discovery and for providing access to other resources. In addition, other endpoints may be hosted at other ports, e.g., in the dynamic port space.=E2=80=9D DOTS is not hosting non (D)TLS COAP, and so we will be breaking the MUST for port 5683. I propose that we do the following for the signal channel spec and support resource discovery. 1) Update the 2 paths (signal and configuration) in the specification, when can then be the default values. Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "signal" To Uri-Path: "v1" << We are v1 as described in the text Uri-Path: "dots-signal" Uri-Path: "mitigation" << overloaded use of signal, this is the mitigate part of dots-signal And Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "config" To Uri-Path: "v1" Uri-Path: "dots-signal" Uri-Path: "configuration" 2) Add in the following =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.7 Resource Discovery As per [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support the CoRe Link Format of discoverable resource as described in [RFC6690], except where fully manual configuration is desired. The two discoverable resources that SHOULD be available to a DOTS client are =E2=80=9Cmitigation=E2=80=9D and =E2=80=9Cconfiguration=E2=80=9D. If t= he appropriate URI paths are returned, the DOTS client MUST use them, overriding any default configuration. A DOTS client SHOULD do a resource discovery, which is done by a GET request to =E2=80=9C/.wellknown/core=E2=80=9D Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".wellknown" Uri-Path: "core" Figure xxx: GET to retrieve dots-signal resources Content-Format:application/link-format ;rt=3D"mitigation";title=3D"DOTS Signal Mitigation";ct=3D60, ;rt=3D"configuration";title=3D"DOTS Signal Configuration";ct=3D60 Figure yyy: Example response to GET to retrieve dots-signal resources As to CoAP being on different ports on the server hosting DOTS server (or DOTS gateway), this may have to be configurable in the DOTS clients, or configurable on the Data Channel as an extension to =E2=80=9CThe DOTS client will perform the root resource discovery procedure discussed in Section 3.1 of [RFC8040] to determine the root of the RESTCONF API. After discovering the RESTCONF API root, the DOTS client uses this value as the initial part of the path in the request URI, in any subsequent request to the DOTS server. The DOTS server may support retrieval of the YANG modules it supports (Section 3.7 in [RFC8040]), for example, a DOTS client may use RESTCONF to retrieve the company proprietary YANG modules supported by the DOTS server.=E2=80= =9D Regards Jon _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --94eb2c12370ec2ef4f055c739c47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

It&= #39;s not ".wellknown", it's ".well-known", note &q= uot;-".

| = Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 = 9191
| mailto:=C2=A0ximaera@gmail.com
| fb: ximaera
| telegram: xima_era
| skyp= e: xima_era
| tel. no: +7 916 515 49 58


26 =D0=BE=D0=BA=D1=82. 2017 =D0=B3= . 4:55 =D0=9F=D0=9F =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82= =D0=B5=D0=BB=D1=8C "Jon Shallow" <supjps-ietf@jpshallow.com> =D0=BD= =D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

Hi there

=C2=A0

Following on from the re= cent virtual conference with discussions about what should be the signal re= quest path (should .wellknown be included in it etc.).

=C2=A0

RFC7252 = 7.1 Service Discovery

=E2=80=9CThe = CoAP default port number 5683 MUST be supported by a server that<= /u>

=C2=A0=C2=A0 offers resources for resource di= scovery (see Section 7.2 below) and

=C2=A0=C2=A0 SHOULD be supported for providing access to other resources.= =C2=A0 The

=C2=A0=C2=A0 default por= t number 5684 for DTLS-secured CoAP MAY be supported by a

=

=C2=A0=C2=A0 server for resource discovery and for p= roviding access to other

=C2=A0=C2= =A0 resources.=C2=A0 In addition, other endpoints may be hosted at other=

=C2=A0=C2=A0 ports, e.g., in the dyna= mic port space.=E2=80=9D

=C2= =A0

DOTS is not hosting non (D)TLS COAP, a= nd so we will be breaking the MUST for port 5683.=C2=A0 I propose that we d= o the following for the signal channel spec and support resource discovery.=

=C2=A0

1)=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Update the 2 paths (signal and configu= ration) in the specification, when can then be the default values.

=C2=A0=C2=A0=C2=A0=C2=A0 Uri-Path: "version"<= /p>

= =C2=A0=C2=A0=C2=A0=C2=A0 Uri-Path: "dots-signal"

= =C2=A0=C2=A0=C2=A0=C2=A0 Uri-Path: "signal"

To

=C2=A0=C2=A0=C2=A0=C2=A0 Uri-Path: "v1" =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=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 << We are v1 as described in the text

=C2=A0=C2= =A0=C2=A0=C2=A0 Uri-Path: "dots-signal"

=C2=A0=C2= =A0=C2=A0=C2=A0 Uri-Path: "mitigation"=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=C2=A0=C2=A0 <&= lt; overloaded use of signal, this is the mitigate part of dots-signal

=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 And

=C2=A0=C2=A0=C2=A0=C2=A0 Uri-Pa= th: "version"

=C2=A0=C2=A0=C2=A0=C2=A0 Uri-Path: &q= uot;dots-signal"

=C2=A0=C2=A0=C2=A0=C2=A0 Uri-Path: &quo= t;config"

To

=C2=A0=C2=A0=C2=A0=C2=A0 Uri-= Path: "v1"

=C2=A0=C2=A0=C2=A0=C2=A0 Uri-Path: "= ;dots-signal"

=C2=A0=C2=A0=C2=A0=C2=A0 Uri-Path: "c= onfiguration"

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add in the following

= =C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

5.7 Resource Discovery

= =C2=A0

As per [RFC7252 7.2 Resource Discov= ery] the DOTS server SHOULD support the CoRe Link Format of discoverable re= source as described in [RFC6690], except where fully manual configuration i= s desired.

=C2=A0

=

The two discoverable resources that SHOULD be availa= ble to a DOTS client are =E2=80=9Cmitigation=E2=80=9D and =E2=80=9Cconfigur= ation=E2=80=9D.=C2=A0 If the appropriate URI paths are returned, the DOTS c= lient MUST use them, overriding any default configuration.=C2=A0 A DOTS cli= ent SHOULD do a resource discovery, which is done by a GET request to =E2= =80=9C/.wellknown/core=E2=80=9D

= =C2=A0

Header: GET (Code=3D0.01)

=C2=A0=C2=A0=C2=A0=C2=A0 Uri-Host: "= ;host"

=C2=A0=C2=A0=C2=A0=C2= =A0 Uri-Path: ".wellknown"

=C2=A0=C2=A0=C2=A0=C2=A0 Uri-Path: "core"

=C2=A0

Figure xx= x: GET to retrieve dots-signal resources

=C2=A0

Content-Format:applica= tion/link-format

=C2=A0=

<v1/dots-signal/mitigation>;rt= =3D"mitigation";title=3D"DOTS Signal Mitigation";ct=3D6= 0,

</v1/dots-signal/configuratio= n>;rt=3D"configuration";title=3D"DOTS Signal Co= nfiguration";ct=3D60

= =C2=A0

Figure yyy: Example response to GET= to retrieve dots-signal resources

=C2=A0

=

=C2=A0

As to CoAP being on different ports on the server hosting DOTS server (or = DOTS gateway), this may have to be configurable in the DOTS clients, or con= figurable on the Data Channel as an extension to

=C2=A0

=E2=80=9CThe = DOTS client will perform the root resource discovery procedure

=C2=A0=C2=A0 discussed in Section 3.1 of [RFC80= 40] to determine the root of the

= =C2=A0=C2=A0 RESTCONF API.=C2=A0 After discovering the RESTCONF API root, t= he DOTS

=C2=A0=C2=A0 client uses th= is value as the initial part of the path in the request

=C2=A0=C2=A0 URI, in any subsequent request to the DOT= S server.=C2=A0 The DOTS server

=C2= =A0=C2=A0 may support retrieval of the YANG modules it supports (Section 3.= 7 in

=C2=A0=C2=A0 [RFC8040]), for e= xample, a DOTS client may use RESTCONF to retrieve

=C2=A0=C2=A0 the company proprietary YANG modules supported= by the DOTS server.=E2=80=9D

=C2=A0

Regards

=C2=A0

Jon

=C2=A0


_________________= ______________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots


--94eb2c12370ec2ef4f055c739c47-- From nobody Thu Oct 26 07:26:39 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD0013F5A2 for ; Thu, 26 Oct 2017 07:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLF5zTGJotr5 for ; Thu, 26 Oct 2017 07:26:34 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 5C95A13F5A5 for ; Thu, 26 Oct 2017 07:26:34 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e7j7A-00006N-M1; Thu, 26 Oct 2017 15:26:32 +0100 From: "Jon Shallow" To: "'Artyom Gavrichenkov'" , References: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> In-Reply-To: Date: Thu, 26 Oct 2017 15:26:32 +0100 Message-ID: <009101d34e66$6bd1f930$4375eb90$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01D34E6E.CD980EE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJzltLgqVNK+TC2PfzhCbifUE2P7AGby1yroajAQZA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS signal and resource path discovery X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 14:26:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0092_01D34E6E.CD980EE0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oops =E2=80=93 well spotted =E2=80=93 thanks! =20 Text below corrected. =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Artyom Gavrichenkov Sent: 26 October 2017 15:02 To: Jon Shallow Cc: dots@ietf.org Subject: Re: [Dots] DOTS signal and resource path discovery =20 Hi, =20 It's not ".wellknown", it's ".well-known", note "-". | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 =20 =20 26 =D0=BE=D0=BA=D1=82. 2017 =D0=B3. 4:55 =D0=9F=D0=9F = =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C = "Jon Shallow" = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: Hi there =20 Following on from the recent virtual conference with discussions about = what should be the signal request path (should .wellknown be included in = it etc.). =20 RFC7252 7.1 Service Discovery =E2=80=9CThe CoAP default port number 5683 MUST be supported by a server = that offers resources for resource discovery (see Section 7.2 below) and SHOULD be supported for providing access to other resources. The default port number 5684 for DTLS-secured CoAP MAY be supported by a server for resource discovery and for providing access to other resources. In addition, other endpoints may be hosted at other ports, e.g., in the dynamic port space.=E2=80=9D =20 DOTS is not hosting non (D)TLS COAP, and so we will be breaking the MUST = for port 5683. I propose that we do the following for the signal = channel spec and support resource discovery. =20 1) Update the 2 paths (signal and configuration) in the = specification, when can then be the default values. Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "signal" To Uri-Path: "v1" << We are v1 as = described in the text Uri-Path: "dots-signal" Uri-Path: "mitigation" << overloaded use of signal, = this is the mitigate part of dots-signal And Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "config" To Uri-Path: "v1" Uri-Path: "dots-signal" Uri-Path: "configuration" 2) Add in the following =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.7 Resource Discovery =20 As per [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support = the CoRe Link Format of discoverable resource as described in [RFC6690], = except where fully manual configuration is desired. =20 The two discoverable resources that SHOULD be available to a DOTS client = are =E2=80=9Cmitigation=E2=80=9D and =E2=80=9Cconfiguration=E2=80=9D. = If the appropriate URI paths are returned, the DOTS client MUST use = them, overriding any default configuration. A DOTS client SHOULD do a = resource discovery, which is done by a GET request to = =E2=80=9C/.well-known/core=E2=80=9D =20 Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "core" =20 Figure xxx: GET to retrieve dots-signal resources =20 Content-Format:application/link-format =20 ;rt=3D"mitigation";title=3D"DOTS Signal = Mitigation";ct=3D60, ;rt=3D"configuration";title=3D"DOTS = Signal Configuration";ct=3D60 =20 Figure yyy: Example response to GET to retrieve dots-signal resources =20 =20 As to CoAP being on different ports on the server hosting DOTS server = (or DOTS gateway), this may have to be configurable in the DOTS clients, = or configurable on the Data Channel as an extension to =20 =E2=80=9CThe DOTS client will perform the root resource discovery = procedure discussed in Section 3.1 of [RFC8040] to determine the root of the RESTCONF API. After discovering the RESTCONF API root, the DOTS client uses this value as the initial part of the path in the request URI, in any subsequent request to the DOTS server. The DOTS server may support retrieval of the YANG modules it supports (Section 3.7 in [RFC8040]), for example, a DOTS client may use RESTCONF to retrieve the company proprietary YANG modules supported by the DOTS = server.=E2=80=9D =20 Regards =20 Jon =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0092_01D34E6E.CD980EE0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Oops =E2=80=93 well spotted =E2=80=93 thanks!

 

Text below corrected.

 

Regards

 

Jon

 

From:= Dots = [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Artyom = Gavrichenkov
Sent: 26 October 2017 15:02
To: Jon = Shallow
Cc: dots@ietf.org
Subject: Re: [Dots] DOTS = signal and resource path discovery

 

Hi,

 

It's not ".wellknown", it's = ".well-known", note "-".

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d = b67f 1ee5 00e7 94bc 4d08 9191
| mailto: ximaera@gmail.com
| fb: ximaera
| telegram: = xima_era
| skype: xima_era
| tel. no: +7 916 515 49 = 58

 

 

26 = =D0=BE=D0=BA=D1=82. 2017 =D0=B3. 4:55 =D0=9F=D0=9F = =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C = "Jon Shallow" <supjps-ietf@jpshallow.com> = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

Hi = there

 <= /o:p>

Following = on from the recent virtual conference with discussions about what should = be the signal request path (should .wellknown be included in it = etc.).

 <= /o:p>

RFC7252 7.1 = Service Discovery

=E2=80=9CThe= CoAP default port number 5683 MUST be supported by a server = that

  = offers resources for resource discovery (see Section 7.2 below) = and

  = SHOULD be supported for providing access to other resources.  = The

  = default port number 5684 for DTLS-secured CoAP MAY be supported by = a

  = server for resource discovery and for providing access to = other

  = resources.  In addition, other endpoints may be hosted at = other

  = ports, e.g., in the dynamic port space.=E2=80=9D

 <= /o:p>

DOTS is not = hosting non (D)TLS COAP, and so we will be breaking the MUST for port = 5683.  I propose that we do the following for the signal channel = spec and support resource discovery.

 <= /o:p>

1)      Update = the 2 paths (signal and configuration) in the specification, when can = then be the default values.

 &n= bsp;   Uri-Path: "version"

 &n= bsp;   Uri-Path: "dots-signal"

 &n= bsp;   Uri-Path: "signal"

To<= /o:p>

 &n= bsp;   Uri-Path: "v1" =             &= nbsp;           &n= bsp;    << We are v1 as described in the = text

 &n= bsp;   Uri-Path: "dots-signal"

 &n= bsp;   Uri-Path: = "mitigation"        &nb= sp;        << overloaded use of = signal, this is the mitigate part of dots-signal

  =              = And

     Uri-Path: = "version"

 &n= bsp;   Uri-Path: "dots-signal"

 &n= bsp;   Uri-Path: "config"

To<= /o:p>

 &n= bsp;   Uri-Path: "v1"

 &n= bsp;   Uri-Path: "dots-signal"

 &n= bsp;   Uri-Path: "configuration"

2)      Add in = the following

 <= /o:p>

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

5.7 = Resource Discovery

 <= /o:p>

As per = [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support the CoRe = Link Format of discoverable resource as described in [RFC6690], except = where fully manual configuration is desired.

 <= /o:p>

The two = discoverable resources that SHOULD be available to a DOTS client are = =E2=80=9Cmitigation=E2=80=9D and =E2=80=9Cconfiguration=E2=80=9D.  = If the appropriate URI paths are returned, the DOTS client MUST use = them, overriding any default configuration.  A DOTS client SHOULD = do a resource discovery, which is done by a GET request to = =E2=80=9C/.well-known/core=E2=80=9D

 <= /o:p>

Header: GET = (Code=3D0.01)

  =    Uri-Host: "host"

  =    Uri-Path: ".well-known"

  =    Uri-Path: "core"

 <= /o:p>

Figure xxx: = GET to retrieve dots-signal resources

 <= /o:p>

Content-Form= at:application/link-format

 <= /o:p>

<v1/dots-= signal/mitigation>;rt=3D"mitigation";title=3D"DOTS = Signal Mitigation";ct=3D60,

</v1/dots= -signal/configuration>;rt=3D"configuration";title=3D"DO= TS Signal Configuration";ct=3D60

 <= /o:p>

Figure yyy: = Example response to GET to retrieve dots-signal = resources

 <= /o:p>

 <= /o:p>

As to CoAP = being on different ports on the server hosting DOTS server (or DOTS = gateway), this may have to be configurable in the DOTS clients, or = configurable on the Data Channel as an extension to

 <= /o:p>

=E2=80=9CThe= DOTS client will perform the root resource discovery = procedure

  = discussed in Section 3.1 of [RFC8040] to determine the root of = the

  = RESTCONF API.  After discovering the RESTCONF API root, the = DOTS

  = client uses this value as the initial part of the path in the = request

  = URI, in any subsequent request to the DOTS server.  The DOTS = server

  = may support retrieval of the YANG modules it supports (Section 3.7 = in

  = [RFC8040]), for example, a DOTS client may use RESTCONF to = retrieve

  = the company proprietary YANG modules supported by the DOTS = server.=E2=80=9D

 <= /o:p>

Regards=

 

Jon

 


______________________________________= _________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

 

------=_NextPart_000_0092_01D34E6E.CD980EE0-- From nobody Thu Oct 26 07:30:47 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521F213F59B for ; Thu, 26 Oct 2017 07:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 fNwDJLZ_tR_n for ; Thu, 26 Oct 2017 07:30:44 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 C2B4C138BD6 for ; Thu, 26 Oct 2017 07:30:43 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509028234; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=+ pZO9NpZTOZItu0bpR+8NNzO4qiY3AuYGq5e/h4ZaX 0=; b=a45UZKRdLVqasHP2bJtciTvDNjBQAJHP6YAneywJe6j8 tIf9Ta2x5vRNu9GBTkupGrMbp2uQVvB3h0YbCFOCtT/oWOMeMl YwNmmKNEtAzf40sShhqXIes/bdm7Z00VlXwFJg9YWPg7Pxy379 xIBAJjTQ7Izz0L5Yb3alp8dAa0s= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 2c47_8a58_bc5bb4d1_cf7c_4fb2_a5c3_66d83dc44b4d; Thu, 26 Oct 2017 09:30:33 -0500 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 10:29:53 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 26 Oct 2017 10:29:53 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Oct 2017 10:29:52 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 26 Oct 2017 14:29:52 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0156.007; Thu, 26 Oct 2017 14:29:52 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS signal and resource path discovery Thread-Index: AdNOYfsbT1udcdezQbua6sZ/aw7wYAAAz3aw Date: Thu, 26 Oct 2017 14:29:52 +0000 Message-ID: References: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> In-Reply-To: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.171.88.198] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:eVOydual40HJ2G9J+9CCBw3oDjArMUvqyi5qFIN2TfgXtyUcQ03h5YSW5T6uxh9RfPq8S+kP/Irs9LADLIoKqg7hu63vM3U3TIVruB6ab20xx1T6IQbvm38bUcA6VYXgdNC6lALX1HK7nr2/nwfK2/4SHAZkkTvEvTDxCFoP3kuaf8a3A9EU60Ux5Ztz1A+vNEB09WAJY3mbKM6MWubHdryjOHwelDZ2tkfXgslyOmLOJra5ac3RaIta5jbS4B9/8i4yOtBBawaxwz7xEbPQLCs/2/9txQ7cIN0w99Fk+ybPnF02SrRFEobupfxaW5HxrTn1JXWzbB8xQ0HVp23S2A==; 5:WeqpaHEZGRbWORA8DBEsuVoJQO4xoOGZ2upVxTVNT5oefLYhdkU6Xc5eBEB66xJoOXo2lnJkmDI5NA6AyV1wAUV5wMIBLKtOOHdex8Ps/RbJXlFaw+NYKy4foaUpF4LgAI12gB6LZSohKMo/7lhDHQ==; 24:kgllroFFdIJP2FfdWhXpJmQxNsacRnQyxDTyuGEeCiFSZ7w6yVl6//a4B4RQudX/0/jHK9FyNgjFC8QQOuwCeZhRGgq7DqRlCZQqDtVxG+U=; 7:gRrQqm020hq8AGe6/Z1XTMdnDRZGUOILvq51IzbOnOlnyO/nMH3vXORymaDjJRhPRmbCOiq0q0F6R6I0X5faB9qYIidnJVQOUsXfvmqiNfE7/+5dXtQcazm5LX5SIWLkM53zx67a2wauhYi/F041x5VFp9Mz0V3LJljvy8F3C6JVQwpYfH6OUQE0GkmFDJmV1WAC/nKGDEc+zSebyi+s9XQtMlg0YncSeY+EiSV6vCE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c56d1cb4-5bb9-4f24-1d4b-08d51c7e0532 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603238); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(79290750141951); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231020)(3002001)(10201501046)(6041248)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(32952001)(189002)(199003)(6246003)(50986999)(5660300001)(9686003)(316002)(76176999)(74316002)(33656002)(54356999)(229853002)(99286003)(6306002)(54896002)(2950100002)(3280700002)(101416001)(110136005)(77096006)(25786009)(14454004)(2906002)(55016002)(72206003)(106356001)(53546010)(2501003)(6506006)(6436002)(7736002)(3660700001)(66066001)(86362001)(105586002)(80792005)(102836003)(8936002)(189998001)(7696004)(790700001)(2900100001)(966005)(53936002)(68736007)(6116002)(478600001)(81156014)(97736004)(81166006)(8676002)(3846002)(21314002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17887847922F3201C1B2AAE8EA450DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c56d1cb4-5bb9-4f24-1d4b-08d51c7e0532 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 14:29:52.0483 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6145> : inlines <6147> : streams <1768478> : uri <2522758> Archived-At: Subject: Re: [Dots] DOTS signal and resource path discovery X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 14:30:46 -0000 --_000_DM5PR16MB17887847922F3201C1B2AAE8EA450DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't see the need to complicate the DOTS signal channel by introducing r= esource discovery (see https://tools.ietf.org/html/rfc5785), Many protocols like EST use well-known locations (e.g. https://www.example.= com/.well-known/est/) where uri-suffix 'est' is allocated by the IANA to av= oid collisions. We can consider a similar approach and request IANA to allocate uri-suffix = 'dots'. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, October 26, 2017 7:25 PM To: dots@ietf.org Subject: [Dots] DOTS signal and resource path discovery Hi there Following on from the recent virtual conference with discussions about what= should be the signal request path (should .wellknown be included in it etc= .). RFC7252 7.1 Service Discovery "The CoAP default port number 5683 MUST be supported by a server that offers resources for resource discovery (see Section 7.2 below) and SHOULD be supported for providing access to other resources. The default port number 5684 for DTLS-secured CoAP MAY be supported by a server for resource discovery and for providing access to other resources. In addition, other endpoints may be hosted at other ports, e.g., in the dynamic port space." DOTS is not hosting non (D)TLS COAP, and so we will be breaking the MUST fo= r port 5683. I propose that we do the following for the signal channel spe= c and support resource discovery. 1) Update the 2 paths (signal and configuration) in the specification,= when can then be the default values. Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "signal" To Uri-Path: "v1" << We are v1 as described = in the text Uri-Path: "dots-signal" Uri-Path: "mitigation" << overloaded use of signal, th= is is the mitigate part of dots-signal And Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "config" To Uri-Path: "v1" Uri-Path: "dots-signal" Uri-Path: "configuration" 2) Add in the following =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.7 Resource Discovery As per [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support the = CoRe Link Format of discoverable resource as described in [RFC6690], except= where fully manual configuration is desired. The two discoverable resources that SHOULD be available to a DOTS client ar= e "mitigation" and "configuration". If the appropriate URI paths are retur= ned, the DOTS client MUST use them, overriding any default configuration. = A DOTS client SHOULD do a resource discovery, which is done by a GET reques= t to "/.wellknown/core" Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".wellknown" Uri-Path: "core" Figure xxx: GET to retrieve dots-signal resources Content-Format:application/link-format ;rt=3D"mitigation";title=3D"DOTS Signal Mitigati= on";ct=3D60, ;rt=3D"configuration";title=3D"DOTS Signal C= onfiguration";ct=3D60 Figure yyy: Example response to GET to retrieve dots-signal resources As to CoAP being on different ports on the server hosting DOTS server (or D= OTS gateway), this may have to be configurable in the DOTS clients, or conf= igurable on the Data Channel as an extension to "The DOTS client will perform the root resource discovery procedure discussed in Section 3.1 of [RFC8040] to determine the root of the RESTCONF API. After discovering the RESTCONF API root, the DOTS client uses this value as the initial part of the path in the request URI, in any subsequent request to the DOTS server. The DOTS server may support retrieval of the YANG modules it supports (Section 3.7 in [RFC8040]), for example, a DOTS client may use RESTCONF to retrieve the company proprietary YANG modules supported by the DOTS server." Regards Jon --_000_DM5PR16MB17887847922F3201C1B2AAE8EA450DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
I don’t see the need to complicate the DOTS signal channel by i=
ntroducing resource discovery (see https://tools.ietf.org/html/rfc5785), 
Many protocols like EST use well-known locations (e.g. https://www.ex=
ample.com/.well-known/est/) where uri-suffix 'est' is allocated by the IANA=
 to avoid collisions. 
We can consider a similar approach and request IANA to allocate uri-s=
uffix 'dots'.
 
-Tiru
 =

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Thursday, October 26, 2017 7:25 PM
To: dots@ietf.org
Subject: [Dots] DOTS signal and resource path discovery

 

Hi there

 

Following on from the recent vi= rtual conference with discussions about what should be the signal request p= ath (should .wellknown be included in it etc.).

 

RFC7252 7.1 Service Discovery

“The CoAP default port nu= mber 5683 MUST be supported by a server that

   offers resources f= or resource discovery (see Section 7.2 below) and

   SHOULD be supporte= d for providing access to other resources.  The

   default port numbe= r 5684 for DTLS-secured CoAP MAY be supported by a

   server for resourc= e discovery and for providing access to other

   resources.  I= n addition, other endpoints may be hosted at other

   ports, e.g., in th= e dynamic port space.”

 

DOTS is not hosting non (D)TLS = COAP, and so we will be breaking the MUST for port 5683.  I propose th= at we do the following for the signal channel spec and support resource dis= covery.

 

1)  = ;    Update the 2 paths (signal and configuration) in the specification, when = can then be the default values.

    = Uri-Path: "version"

    = Uri-Path: "dots-signal"

    = Uri-Path: "signal"

To

    = Uri-Path: "v1"         &= nbsp;           &nbs= p;        << We are v1 as describe= d in the text

    = Uri-Path: "dots-signal"

    = Uri-Path: "mitigation"       =           << overloaded = use of signal, this is the mitigate part of dots-signal

     &= nbsp;         And=

&nbs= p;    Uri-Path: "version"

    = Uri-Path: "dots-signal"

    = Uri-Path: "config"

To

    = Uri-Path: "v1"

    = Uri-Path: "dots-signal"

    = Uri-Path: "configuration"

2)  = ;    Add in the following

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

5.7 Resource Discovery

 

As per [RFC7252 7.2 Resource Di= scovery] the DOTS server SHOULD support the CoRe Link Format of discoverabl= e resource as described in [RFC6690], except where fully manual configurati= on is desired.

 

The two discoverable resources = that SHOULD be available to a DOTS client are “mitigation” and = “configuration”.  If the appropriate URI paths are returne= d, the DOTS client MUST use them, overriding any default configuration.&nbs= p; A DOTS client SHOULD do a resource discovery, which is done by a GET reque= st to “/.wellknown/core”

 

Header: GET (Code=3D0.01)<= /o:p>

     Uri-Ho= st: "host"

     Uri-Pa= th: ".wellknown"

     Uri-Pa= th: "core"

 

Figure xxx: GET to retrieve dot= s-signal resources

 

Content-Format:application/link= -format

 

<v1/dots-signal/mitigation&g= t;;rt=3D"mitigation";title=3D"DOTS Signal Mitigation";c= t=3D60,

</v1/dots-signal/configurati= on>;rt=3D"configuration";title=3D"DOTS Signal Configurati= on";ct=3D60

 

Figure yyy: Example response to= GET to retrieve dots-signal resources

 

 

As to CoAP being on different p= orts on the server hosting DOTS server (or DOTS gateway), this may have to = be configurable in the DOTS clients, or configurable on the Data Channel as= an extension to

 

“The DOTS client will per= form the root resource discovery procedure

   discussed in Secti= on 3.1 of [RFC8040] to determine the root of the

   RESTCONF API. = ; After discovering the RESTCONF API root, the DOTS

   client uses this v= alue as the initial part of the path in the request

   URI, in any subseq= uent request to the DOTS server.  The DOTS server

   may support retrie= val of the YANG modules it supports (Section 3.7 in

   [RFC8040]), for ex= ample, a DOTS client may use RESTCONF to retrieve

   the company propri= etary YANG modules supported by the DOTS server.”

 

Regards

 

Jon

 

--_000_DM5PR16MB17887847922F3201C1B2AAE8EA450DM5PR16MB1788namp_-- From nobody Thu Oct 26 07:49:37 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE38A1388A9 for ; Thu, 26 Oct 2017 07:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 SEGNKjfFwb2I for ; Thu, 26 Oct 2017 07:49:33 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0108.outbound.protection.outlook.com [104.47.40.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63951386DE for ; Thu, 26 Oct 2017 07:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8I03Pgnkdmm3ccR96Tp0WjCPNYiyXBGv/W97Cb0kKJU=; b=ktgZ0Nu0Q2LngCPJQHf8L1LGEa0iBSl2/J0LI/iCGcFBMgUGLRCBcaMai7RppwA+yAFPuV3qMiiF5F5CWrB2Ny5ArbhpAuyp7yJttdcG0M4x6JV8K4igvGzjlRZPYxcL0wjd9lMG4cgoZqP5zNlJiDamu/dKeyt3e75lFOXd9RY= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1988.prod.exchangelabs.com (10.166.71.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Thu, 26 Oct 2017 14:49:31 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0178.007; Thu, 26 Oct 2017 14:49:31 +0000 From: "Mortensen, Andrew" To: "Konda, Tirumaleswar Reddy" CC: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS signal and resource path discovery Thread-Index: AdNOYfsbT1udcdezQbua6sZ/aw7wYAAAz3awAAEZqQA= Date: Thu, 26 Oct 2017 14:49:30 +0000 Message-ID: <0CEBEED4-F958-467A-98D5-54F7C4CB0883@arbor.net> References: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; x-originating-ip: [216.130.192.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1988; 6:lxRbkBEmbUe2ye1BPQpCe7GXxgaC+c1G4yoN+02SRaYciPA3J0SqVZzZ74fawPhT3MakMd5qsNMpNRmo+c/LT8cm3U9pSY23cIFfwdpkrzaTpuBf+BlSErU2GC7631SmvHo7QxVY2KROMWTTWrWTP4JCzhecoTXy9a0PDAk8zy90WS3URWpnAazhBapA+6je72s71IgMawzoZbV4/ixItvfzffm1tutWJEzN41IrFlR3rKFvSzv/mLUQds+nZB5u/ltuncABW7OkjclHI5POVwP00R9Xo6NRMooX+VeG5V5IpaSiByvrEs0xnEZi+G6JCs6YiKBCrWtfVMSShHaSgjjRPoV2KLnG/WKXv3To9Lo=; 5:Ft+h2TpL81qduBf+jTaaNwt7owygwKVKKlG9jzMwC+AI0k0e5hAMNBeQ1RQ17u+36uYp3NHfITtqU95dSLphwvwA0/5rJVk2YQ4OpkBXxBlKSyF/GGq6n6jlRkfqTbwht37StyiKb8xP94MlAGljLMlyXLIl6tJzieCQEMuohsw=; 24:Z7+Cjpos53XdAZdJpexnnuJCmSmQcskCYZdpqnmedil7vnM4ljPieAbD3REBjkXI3nuFSVRRBIhkgCa1+1T1MYiimoE1ytBSQ5KqYqcv6mA=; 7:iqaxwa/SrWuLJ08mWt4bGv0xgP8tLLqwNQhldU3JB3TyhVJt5G6LdNQA8DVea4Ndb82zHC1xL39OdLJ1r/uXsUyVJkPUsQ6i+Ijwuna7QMsgdtvZ+7lc08q0Y6CEOJKClHaLko5fPHT+ZcYRxR5BproxV3mzT5VZKX8V2vSX9cRtz9swacqI71l9mUEC5T+ZFqVOpo0NPt5vKV8FoU5OVpMhderCwOaDEoTKm6x0bioDiLWI++5PdCKjK4dqlrSm x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4a75eb3e-092f-4ae7-c512-08d51c80c3e4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BN3PR01MB1988; x-ms-traffictypediagnostic: BN3PR01MB1988: x-exchange-antispam-report-test: UriScan:(158342451672863)(79290750141951)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231020)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR01MB1988; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR01MB1988; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(24454002)(189002)(199003)(6436002)(82746002)(106356001)(229853002)(5660300001)(6506006)(966005)(105586002)(54896002)(6916009)(14454004)(53936002)(2950100002)(36756003)(6306002)(236005)(6512007)(6116002)(97736004)(86362001)(3846002)(6246003)(53546010)(101416001)(4326008)(6486002)(3660700001)(99286003)(76176999)(77096006)(2906002)(3280700002)(606006)(102836003)(54356999)(50986999)(316002)(68736007)(189998001)(54906003)(25786009)(7736002)(478600001)(8936002)(33656002)(81166006)(66066001)(2900100001)(8676002)(83716003)(81156014)(21314002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1988; H:BN3PR01MB1987.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0CEBEED4F958467A98D554F7C4CB0883arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 4a75eb3e-092f-4ae7-c512-08d51c80c3e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 14:49:30.9172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1988 Archived-At: Subject: Re: [Dots] DOTS signal and resource path discovery X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 14:49:36 -0000 --_000_0CEBEED4F958467A98D554F7C4CB0883arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBPY3QgMjYsIDIwMTcsIGF0IDEwOjI5IEFNLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5 IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tPj4gd3JvdGU6DQoNCg0KSSBkb27igJl0IHNlZSB0aGUgbmVl ZCB0byBjb21wbGljYXRlIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIGJ5IGludHJvZHVjaW5nIHJl c291cmNlIGRpc2NvdmVyeSAoc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1Nzg1 KSwNCg0KTWFueSBwcm90b2NvbHMgbGlrZSBFU1QgdXNlIHdlbGwta25vd24gbG9jYXRpb25zIChl LmcuIGh0dHBzOi8vd3d3LmV4YW1wbGUuY29tLy53ZWxsLWtub3duL2VzdC8pIHdoZXJlIHVyaS1z dWZmaXggJ2VzdCcgaXMgYWxsb2NhdGVkIGJ5IHRoZSBJQU5BIHRvIGF2b2lkIGNvbGxpc2lvbnMu DQoNCldlIGNhbiBjb25zaWRlciBhIHNpbWlsYXIgYXBwcm9hY2ggYW5kIHJlcXVlc3QgSUFOQSB0 byBhbGxvY2F0ZSB1cmktc3VmZml4ICdkb3Rz4oCZLg0KDQpJIGxpa2UgdGhpcyBhcHByb2FjaC4N Cg0KYW5kcmV3DQoNCg0KDQoNCg0KDQoNCg0KDQpGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9uIFNoYWxsb3cNClNlbnQ6IFRodXJzZGF5LCBP Y3RvYmVyIDI2LCAyMDE3IDc6MjUgUE0NClRvOiBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGll dGYub3JnPg0KU3ViamVjdDogW0RvdHNdIERPVFMgc2lnbmFsIGFuZCByZXNvdXJjZSBwYXRoIGRp c2NvdmVyeQ0KDQpIaSB0aGVyZQ0KDQpGb2xsb3dpbmcgb24gZnJvbSB0aGUgcmVjZW50IHZpcnR1 YWwgY29uZmVyZW5jZSB3aXRoIGRpc2N1c3Npb25zIGFib3V0IHdoYXQgc2hvdWxkIGJlIHRoZSBz aWduYWwgcmVxdWVzdCBwYXRoIChzaG91bGQgLndlbGxrbm93biBiZSBpbmNsdWRlZCBpbiBpdCBl dGMuKS4NCg0KUkZDNzI1MiA3LjEgU2VydmljZSBEaXNjb3ZlcnkNCuKAnFRoZSBDb0FQIGRlZmF1 bHQgcG9ydCBudW1iZXIgNTY4MyBNVVNUIGJlIHN1cHBvcnRlZCBieSBhIHNlcnZlciB0aGF0DQog ICBvZmZlcnMgcmVzb3VyY2VzIGZvciByZXNvdXJjZSBkaXNjb3ZlcnkgKHNlZSBTZWN0aW9uIDcu MiBiZWxvdykgYW5kDQogICBTSE9VTEQgYmUgc3VwcG9ydGVkIGZvciBwcm92aWRpbmcgYWNjZXNz IHRvIG90aGVyIHJlc291cmNlcy4gIFRoZQ0KICAgZGVmYXVsdCBwb3J0IG51bWJlciA1Njg0IGZv ciBEVExTLXNlY3VyZWQgQ29BUCBNQVkgYmUgc3VwcG9ydGVkIGJ5IGENCiAgIHNlcnZlciBmb3Ig cmVzb3VyY2UgZGlzY292ZXJ5IGFuZCBmb3IgcHJvdmlkaW5nIGFjY2VzcyB0byBvdGhlcg0KICAg cmVzb3VyY2VzLiAgSW4gYWRkaXRpb24sIG90aGVyIGVuZHBvaW50cyBtYXkgYmUgaG9zdGVkIGF0 IG90aGVyDQogICBwb3J0cywgZS5nLiwgaW4gdGhlIGR5bmFtaWMgcG9ydCBzcGFjZS7igJ0NCg0K RE9UUyBpcyBub3QgaG9zdGluZyBub24gKEQpVExTIENPQVAsIGFuZCBzbyB3ZSB3aWxsIGJlIGJy ZWFraW5nIHRoZSBNVVNUIGZvciBwb3J0IDU2ODMuICBJIHByb3Bvc2UgdGhhdCB3ZSBkbyB0aGUg Zm9sbG93aW5nIGZvciB0aGUgc2lnbmFsIGNoYW5uZWwgc3BlYyBhbmQgc3VwcG9ydCByZXNvdXJj ZSBkaXNjb3ZlcnkuDQoNCjEpICAgICAgVXBkYXRlIHRoZSAyIHBhdGhzIChzaWduYWwgYW5kIGNv bmZpZ3VyYXRpb24pIGluIHRoZSBzcGVjaWZpY2F0aW9uLCB3aGVuIGNhbiB0aGVuIGJlIHRoZSBk ZWZhdWx0IHZhbHVlcy4NCiAgICAgVXJpLVBhdGg6ICJ2ZXJzaW9uIg0KICAgICBVcmktUGF0aDog ImRvdHMtc2lnbmFsIg0KICAgICBVcmktUGF0aDogInNpZ25hbCINClRvDQogICAgIFVyaS1QYXRo OiAidjEiICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPDwgV2UgYXJlIHYxIGFzIGRlc2Ny aWJlZCBpbiB0aGUgdGV4dA0KICAgICBVcmktUGF0aDogImRvdHMtc2lnbmFsIg0KICAgICBVcmkt UGF0aDogIm1pdGlnYXRpb24iICAgICAgICAgICAgICAgICA8PCBvdmVybG9hZGVkIHVzZSBvZiBz aWduYWwsIHRoaXMgaXMgdGhlIG1pdGlnYXRlIHBhcnQgb2YgZG90cy1zaWduYWwNCiAgICAgICAg ICAgICAgIEFuZA0KICAgICBVcmktUGF0aDogInZlcnNpb24iDQogICAgIFVyaS1QYXRoOiAiZG90 cy1zaWduYWwiDQogICAgIFVyaS1QYXRoOiAiY29uZmlnIg0KVG8NCiAgICAgVXJpLVBhdGg6ICJ2 MSINCiAgICAgVXJpLVBhdGg6ICJkb3RzLXNpZ25hbCINCiAgICAgVXJpLVBhdGg6ICJjb25maWd1 cmF0aW9uIg0KMikgICAgICBBZGQgaW4gdGhlIGZvbGxvd2luZw0KDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KNS43IFJlc291cmNlIERpc2NvdmVyeQ0K DQpBcyBwZXIgW1JGQzcyNTIgNy4yIFJlc291cmNlIERpc2NvdmVyeV0gdGhlIERPVFMgc2VydmVy IFNIT1VMRCBzdXBwb3J0IHRoZSBDb1JlIExpbmsgRm9ybWF0IG9mIGRpc2NvdmVyYWJsZSByZXNv dXJjZSBhcyBkZXNjcmliZWQgaW4gW1JGQzY2OTBdLCBleGNlcHQgd2hlcmUgZnVsbHkgbWFudWFs IGNvbmZpZ3VyYXRpb24gaXMgZGVzaXJlZC4NCg0KVGhlIHR3byBkaXNjb3ZlcmFibGUgcmVzb3Vy Y2VzIHRoYXQgU0hPVUxEIGJlIGF2YWlsYWJsZSB0byBhIERPVFMgY2xpZW50IGFyZSDigJxtaXRp Z2F0aW9u4oCdIGFuZCDigJxjb25maWd1cmF0aW9u4oCdLiAgSWYgdGhlIGFwcHJvcHJpYXRlIFVS SSBwYXRocyBhcmUgcmV0dXJuZWQsIHRoZSBET1RTIGNsaWVudCBNVVNUIHVzZSB0aGVtLCBvdmVy cmlkaW5nIGFueSBkZWZhdWx0IGNvbmZpZ3VyYXRpb24uICBBIERPVFMgY2xpZW50IFNIT1VMRCBk byBhIHJlc291cmNlIGRpc2NvdmVyeSwgd2hpY2ggaXMgZG9uZSBieSBhIEdFVCByZXF1ZXN0IHRv IOKAnC8ud2VsbGtub3duL2NvcmXigJ0NCg0KSGVhZGVyOiBHRVQgKENvZGU9MC4wMSkNCiAgICAg VXJpLUhvc3Q6ICJob3N0Ig0KICAgICBVcmktUGF0aDogIi53ZWxsa25vd24iDQogICAgIFVyaS1Q YXRoOiAiY29yZSINCg0KRmlndXJlIHh4eDogR0VUIHRvIHJldHJpZXZlIGRvdHMtc2lnbmFsIHJl c291cmNlcw0KDQpDb250ZW50LUZvcm1hdDphcHBsaWNhdGlvbi9saW5rLWZvcm1hdA0KDQo8djEv ZG90cy1zaWduYWwvbWl0aWdhdGlvbj47cnQ9Im1pdGlnYXRpb24iO3RpdGxlPSJET1RTIFNpZ25h bCBNaXRpZ2F0aW9uIjtjdD02MCwNCjwvdjEvZG90cy1zaWduYWwvY29uZmlndXJhdGlvbj47cnQ9 ImNvbmZpZ3VyYXRpb24iO3RpdGxlPSJET1RTIFNpZ25hbCBDb25maWd1cmF0aW9uIjtjdD02MA0K DQpGaWd1cmUgeXl5OiBFeGFtcGxlIHJlc3BvbnNlIHRvIEdFVCB0byByZXRyaWV2ZSBkb3RzLXNp Z25hbCByZXNvdXJjZXMNCg0KDQpBcyB0byBDb0FQIGJlaW5nIG9uIGRpZmZlcmVudCBwb3J0cyBv biB0aGUgc2VydmVyIGhvc3RpbmcgRE9UUyBzZXJ2ZXIgKG9yIERPVFMgZ2F0ZXdheSksIHRoaXMg bWF5IGhhdmUgdG8gYmUgY29uZmlndXJhYmxlIGluIHRoZSBET1RTIGNsaWVudHMsIG9yIGNvbmZp Z3VyYWJsZSBvbiB0aGUgRGF0YSBDaGFubmVsIGFzIGFuIGV4dGVuc2lvbiB0bw0KDQrigJxUaGUg RE9UUyBjbGllbnQgd2lsbCBwZXJmb3JtIHRoZSByb290IHJlc291cmNlIGRpc2NvdmVyeSBwcm9j ZWR1cmUNCiAgIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDMuMSBvZiBbUkZDODA0MF0gdG8gZGV0ZXJt aW5lIHRoZSByb290IG9mIHRoZQ0KICAgUkVTVENPTkYgQVBJLiAgQWZ0ZXIgZGlzY292ZXJpbmcg dGhlIFJFU1RDT05GIEFQSSByb290LCB0aGUgRE9UUw0KICAgY2xpZW50IHVzZXMgdGhpcyB2YWx1 ZSBhcyB0aGUgaW5pdGlhbCBwYXJ0IG9mIHRoZSBwYXRoIGluIHRoZSByZXF1ZXN0DQogICBVUkks IGluIGFueSBzdWJzZXF1ZW50IHJlcXVlc3QgdG8gdGhlIERPVFMgc2VydmVyLiAgVGhlIERPVFMg c2VydmVyDQogICBtYXkgc3VwcG9ydCByZXRyaWV2YWwgb2YgdGhlIFlBTkcgbW9kdWxlcyBpdCBz dXBwb3J0cyAoU2VjdGlvbiAzLjcgaW4NCiAgIFtSRkM4MDQwXSksIGZvciBleGFtcGxlLCBhIERP VFMgY2xpZW50IG1heSB1c2UgUkVTVENPTkYgdG8gcmV0cmlldmUNCiAgIHRoZSBjb21wYW55IHBy b3ByaWV0YXJ5IFlBTkcgbW9kdWxlcyBzdXBwb3J0ZWQgYnkgdGhlIERPVFMgc2VydmVyLuKAnQ0K DQpSZWdhcmRzDQoNCkpvbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg0K --_000_0CEBEED4F958467A98D554F7C4CB0883arbornet_ Content-Type: text/html; charset="utf-8" Content-ID: <99801894738D1E4CAF394465E5D1189B@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBPY3Qg MjYsIDIwMTcsIGF0IDEwOjI5IEFNLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDs8YSBo cmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSIgY2xhc3M9IiI+ VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3 JzsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+SSBkb27igJl0IHNlZSB0aGUgbmVlZCB0byBj b21wbGljYXRlIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIGJ5IGludHJvZHVjaW5nIHJlc291cmNl IGRpc2NvdmVyeSAoc2VlIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1 Nzg1IiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBj bGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc4NTwvYT4pLCA8bzpwIGNs YXNzPSIiPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+TWFueSBwcm90b2NvbHMgbGlrZSBFU1QgdXNlIHdlbGwt a25vd24gbG9jYXRpb25zIChlLmcuIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmV4YW1wbGUuY29tLy53 ZWxsLWtub3duL2VzdC8iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmV4YW1wbGUuY29tLy53ZWxsLWtub3duL2Vz dC88L2E+KSB3aGVyZSB1cmktc3VmZml4ICdlc3QnIGlzIGFsbG9jYXRlZCBieSB0aGUgSUFOQSB0 byBhdm9pZCBjb2xsaXNpb25zLiA8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+V2UgY2Fu IGNvbnNpZGVyIGEgc2ltaWxhciBhcHByb2FjaCBhbmQgcmVxdWVzdCBJQU5BIHRvIGFsbG9jYXRl IHVyaS1zdWZmaXggJ2RvdHPigJkuPC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkkgbGlrZSB0aGlzIGFw cHJvYWNoLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+YW5kcmV3PC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jzsi IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPHNwYW4gY2xhc3M9IiI+PC9zcGFuPg0K PGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxl ZnQtd2lkdGg6IDEuNXB0OyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsgcGFkZGluZzogMGluIDBp biAwaW4gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVy LXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3Atd2lkdGg6IDFwdDsgYm9yZGVyLXRv cC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUpOyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiIGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFz cz0iIj48c3BhbiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9IiI+PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkRvdHMgWzxhIGhyZWY9 Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YiBjbGFzcz0iIj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkpvbg0KIFNoYWxsb3c8YnIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+VGh1cnNkYXksIE9jdG9iZXIgMjYsIDIwMTcgNzoyNSBQTTxiciBjbGFzcz0i Ij4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciIGNsYXNzPSIiPmRv dHNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPltEb3RzXSBET1RT IHNpZ25hbCBhbmQgcmVzb3VyY2UgcGF0aCBkaXNjb3Zlcnk8bzpwIGNsYXNzPSIiPjwvbzpwPjwv c3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBj bGFzcz0iIj5IaSB0aGVyZTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIg Y2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBj bGFzcz0iIj5Gb2xsb3dpbmcgb24gZnJvbSB0aGUgcmVjZW50IHZpcnR1YWwgY29uZmVyZW5jZSB3 aXRoIGRpc2N1c3Npb25zIGFib3V0IHdoYXQgc2hvdWxkIGJlIHRoZSBzaWduYWwgcmVxdWVzdCBw YXRoIChzaG91bGQgLndlbGxrbm93biBiZSBpbmNsdWRlZCBpbiBpdCBldGMuKS48bzpwIGNsYXNz PSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+UkZDNzI1MiA3LjEgU2Vydmlj ZSBEaXNjb3Zlcnk8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNz PSIiPuKAnFRoZSBDb0FQIGRlZmF1bHQgcG9ydCBudW1iZXIgNTY4MyBNVVNUIGJlIHN1cHBvcnRl ZCBieSBhIHNlcnZlciB0aGF0PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdC IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgb2ZmZXJzIHJlc291cmNlcyBmb3IgcmVzb3VyY2UgZGlz Y292ZXJ5IChzZWUgU2VjdGlvbiA3LjIgYmVsb3cpIGFuZDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IFNIT1VMRCBiZSBzdXBwb3J0 ZWQgZm9yIHByb3ZpZGluZyBhY2Nlc3MgdG8gb3RoZXIgcmVzb3VyY2VzLiZuYnNwOyBUaGU8bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPiZuYnNwOyZuYnNw OyBkZWZhdWx0IHBvcnQgbnVtYmVyIDU2ODQgZm9yIERUTFMtc2VjdXJlZCBDb0FQIE1BWSBiZSBz dXBwb3J0ZWQgYnkgYTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xh c3M9IiI+Jm5ic3A7Jm5ic3A7IHNlcnZlciBmb3IgcmVzb3VyY2UgZGlzY292ZXJ5IGFuZCBmb3Ig cHJvdmlkaW5nIGFjY2VzcyB0byBvdGhlcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5n PSJFTi1HQiIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IHJlc291cmNlcy4mbmJzcDsgSW4gYWRkaXRp b24sIG90aGVyIGVuZHBvaW50cyBtYXkgYmUgaG9zdGVkIGF0IG90aGVyPG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgcG9ydHMsIGUu Zy4sIGluIHRoZSBkeW5hbWljIHBvcnQgc3BhY2Uu4oCdPG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxz cGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPkRPVFMgaXMgbm90IGhvc3Rpbmcgbm9uIChEKVRMUyBD T0FQLCBhbmQgc28gd2Ugd2lsbCBiZSBicmVha2luZyB0aGUgTVVTVCBmb3IgcG9ydCA1NjgzLiZu YnNwOyBJIHByb3Bvc2UgdGhhdCB3ZSBkbyB0aGUgZm9sbG93aW5nIGZvciB0aGUgc2lnbmFsIGNo YW5uZWwgc3BlYyBhbmQgc3VwcG9ydCByZXNvdXJjZSBkaXNjb3ZlcnkuPG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAw LjVpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg dGV4dC1pbmRlbnQ6IC0wLjI1aW47IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFz cz0iIj48c3BhbiBjbGFzcz0iIj4xKTxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTog N3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7 IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNw YW4gZGlyPSJMVFIiIGNsYXNzPSIiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+ VXBkYXRlDQogdGhlIDIgcGF0aHMgKHNpZ25hbCBhbmQgY29uZmlndXJhdGlvbikgaW4gdGhlIHNw ZWNpZmljYXRpb24sIHdoZW4gY2FuIHRoZW4gYmUgdGhlIGRlZmF1bHQgdmFsdWVzLjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0IDAuNWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDt2ZXJzaW9uJnF1b3Q7PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQgMC41aW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O2RvdHMtc2lnbmFsJnF1b3Q7PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQgMC41aW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O3NpZ25hbCZxdW90OzxvOnAgY2xhc3M9IiI+PC9v OnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAu NWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+VG88bzpwIGNsYXNzPSIiPjwv bzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAw LjVpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7djEmcXVvdDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsmbHQ7IFdlIGFyZSB2MSBhcyBkZXNj cmliZWQgaW4gdGhlIHRleHQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAwLjVpbjsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0i RU4tR0IiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7 ZG90cy1zaWduYWwmcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAwLjVpbjsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0i RU4tR0IiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7 bWl0aWdhdGlvbiZxdW90OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bHQ7Jmx0OyBvdmVybG9hZGVkIHVzZSBvZiBzaWduYWwsIHRoaXMgaXMgdGhlIG1pdGlnYXRlIHBh cnQgb2YgZG90cy1zaWduYWw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0Ii IGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbmQ8bzpwIGNsYXNzPSIiPjwv bzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAw LjVpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7dmVyc2lvbiZxdW90OzxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAuNWlu OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFVyaS1QYXRoOiAmcXVvdDtkb3RzLXNpZ25hbCZxdW90OzxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAuNWlu OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFVyaS1QYXRoOiAmcXVvdDtjb25maWcmcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAwLjVpbjsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPlRvPG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VXJpLVBhdGg6ICZxdW90O3YxJnF1b3Q7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IGxhbmc9IkVOLUdCIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6 ICZxdW90O2RvdHMtc2lnbmFsJnF1b3Q7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IGxhbmc9IkVOLUdCIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6 ICZxdW90O2NvbmZpZ3VyYXRpb24mcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCAwLjVpbjsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgdGV4dC1pbmRlbnQ6IC0w LjI1aW47IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj48c3BhbiBjbGFz cz0iIj4yKTxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdo dDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gZGlyPSJMVFIiIGNs YXNzPSIiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+QWRkDQogaW4gdGhlIGZv bGxvd2luZzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+ PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj49 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+NS43IFJlc291cmNlIERpc2Nv dmVyeTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+PG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj5BcyBw ZXIgW1JGQzcyNTIgNy4yIFJlc291cmNlIERpc2NvdmVyeV0gdGhlIERPVFMgc2VydmVyIFNIT1VM RCBzdXBwb3J0IHRoZSBDb1JlIExpbmsgRm9ybWF0IG9mIGRpc2NvdmVyYWJsZSByZXNvdXJjZSBh cyBkZXNjcmliZWQgaW4gW1JGQzY2OTBdLCBleGNlcHQgd2hlcmUgZnVsbHkgbWFudWFsIGNvbmZp Z3VyYXRpb24gaXMgZGVzaXJlZC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4t R0IiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1H QiIgY2xhc3M9IiI+VGhlIHR3byBkaXNjb3ZlcmFibGUgcmVzb3VyY2VzIHRoYXQgU0hPVUxEIGJl IGF2YWlsYWJsZSB0byBhIERPVFMgY2xpZW50IGFyZSDigJxtaXRpZ2F0aW9u4oCdIGFuZCDigJxj b25maWd1cmF0aW9u4oCdLiZuYnNwOyBJZiB0aGUgYXBwcm9wcmlhdGUgVVJJIHBhdGhzIGFyZSBy ZXR1cm5lZCwgdGhlIERPVFMgY2xpZW50IE1VU1QgdXNlIHRoZW0sIG92ZXJyaWRpbmcgYW55IGRl ZmF1bHQgY29uZmlndXJhdGlvbi4mbmJzcDsgQSBET1RTDQogY2xpZW50IFNIT1VMRCBkbyBhIHJl c291cmNlIGRpc2NvdmVyeSwgd2hpY2ggaXMgZG9uZSBieSBhIEdFVCByZXF1ZXN0IHRvIOKAnC8u d2VsbGtub3duL2NvcmXigJ08bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0Ii IGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIg Y2xhc3M9IiI+SGVhZGVyOiBHRVQgKENvZGU9MC4wMSk8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktSG9z dDogJnF1b3Q7aG9zdCZxdW90OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1H QiIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDsud2Vs bGtub3duJnF1b3Q7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFz cz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O2NvcmUmcXVvdDs8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+RmlndXJlIHh4 eDogR0VUIHRvIHJldHJpZXZlIGRvdHMtc2lnbmFsIHJlc291cmNlczxvOnAgY2xhc3M9IiI+PC9v OnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286 cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj5Db250ZW50LUZvcm1hdDphcHBsaWNhdGlv bi9saW5rLWZvcm1hdDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xh c3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFz cz0iIj4mbHQ7djEvZG90cy1zaWduYWwvbWl0aWdhdGlvbiZndDs7cnQ9JnF1b3Q7bWl0aWdhdGlv biZxdW90Ozt0aXRsZT0mcXVvdDtET1RTIFNpZ25hbCBNaXRpZ2F0aW9uJnF1b3Q7O2N0PTYwLDxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+Jmx0Oy92MS9k b3RzLXNpZ25hbC9jb25maWd1cmF0aW9uJmd0OztydD0mcXVvdDtjb25maWd1cmF0aW9uJnF1b3Q7 O3RpdGxlPSZxdW90O0RPVFMgU2lnbmFsIENvbmZpZ3VyYXRpb24mcXVvdDs7Y3Q9NjA8bzpwIGNs YXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+RmlndXJlIHl5eTogRXhh bXBsZSByZXNwb25zZSB0byBHRVQgdG8gcmV0cmlldmUgZG90cy1zaWduYWwgcmVzb3VyY2VzPG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6 IG5vbmUgbm9uZSBkb3VibGU7IGJvcmRlci1ib3R0b20td2lkdGg6IDIuMjVwdDsgYm9yZGVyLWJv dHRvbS1jb2xvcjogd2luZG93dGV4dDsgcGFkZGluZzogMGluIDBpbiAxcHQ7IiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0i RU4tR0IiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IGxhbmc9IkVOLUdCIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g bGFuZz0iRU4tR0IiIGNsYXNzPSIiPkFzIHRvIENvQVAgYmVpbmcgb24gZGlmZmVyZW50IHBvcnRz IG9uIHRoZSBzZXJ2ZXIgaG9zdGluZyBET1RTIHNlcnZlciAob3IgRE9UUyBnYXRld2F5KSwgdGhp cyBtYXkgaGF2ZSB0byBiZSBjb25maWd1cmFibGUgaW4gdGhlIERPVFMgY2xpZW50cywgb3IgY29u ZmlndXJhYmxlIG9uIHRoZSBEYXRhIENoYW5uZWwgYXMgYW4gZXh0ZW5zaW9uIHRvPG86cCBjbGFz cz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPuKAnFRoZSBET1RTIGNsaWVu dCB3aWxsIHBlcmZvcm0gdGhlIHJvb3QgcmVzb3VyY2UgZGlzY292ZXJ5IHByb2NlZHVyZTxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7 IGRpc2N1c3NlZCBpbiBTZWN0aW9uIDMuMSBvZiBbUkZDODA0MF0gdG8gZGV0ZXJtaW5lIHRoZSBy b290IG9mIHRoZTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9 IiI+Jm5ic3A7Jm5ic3A7IFJFU1RDT05GIEFQSS4mbmJzcDsgQWZ0ZXIgZGlzY292ZXJpbmcgdGhl IFJFU1RDT05GIEFQSSByb290LCB0aGUgRE9UUzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBs YW5nPSJFTi1HQiIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IGNsaWVudCB1c2VzIHRoaXMgdmFsdWUg YXMgdGhlIGluaXRpYWwgcGFydCBvZiB0aGUgcGF0aCBpbiB0aGUgcmVxdWVzdDxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IFVSSSwg aW4gYW55IHN1YnNlcXVlbnQgcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuJm5ic3A7IFRoZSBE T1RTIHNlcnZlcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9 IiI+Jm5ic3A7Jm5ic3A7IG1heSBzdXBwb3J0IHJldHJpZXZhbCBvZiB0aGUgWUFORyBtb2R1bGVz IGl0IHN1cHBvcnRzIChTZWN0aW9uIDMuNyBpbjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBs YW5nPSJFTi1HQiIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IFtSRkM4MDQwXSksIGZvciBleGFtcGxl LCBhIERPVFMgY2xpZW50IG1heSB1c2UgUkVTVENPTkYgdG8gcmV0cmlldmU8bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyB0aGUgY29t cGFueSBwcm9wcmlldGFyeSBZQU5HIG1vZHVsZXMgc3VwcG9ydGVkIGJ5IHRoZSBET1RTIHNlcnZl ci7igJ08bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPjxv OnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+UmVn YXJkczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgY2xhc3M9IiI+PG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBjbGFzcz0iIj5Kb248 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlz cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj5Eb3RzDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpEb3RzQGll dGYub3JnIiBjbGFzcz0iIj5Eb3RzQGlldGYub3JnPC9hPjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTog aW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG90czwvYT48L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0CEBEED4F958467A98D554F7C4CB0883arbornet_-- From nobody Thu Oct 26 09:58:41 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D466513F3EE for ; Thu, 26 Oct 2017 09:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 Ar08PbhBeG-O for ; Thu, 26 Oct 2017 09:58:36 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0134.outbound.protection.outlook.com [104.47.33.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C64139059 for ; Thu, 26 Oct 2017 09:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ifap5CtY0bZkDGgiyzUlNcSSNVo79ptepiKygOLPhuQ=; b=NSbje0Lxnt059lYXNG22oCcXa6+dpGv/tBWxgr6YTgnVvPalm+N2MNgKgzkxFYxK8tRJS22v1sevvlK3dE15FxL8OWcPsUF54i8nCpfc079TKynrfGIxCi0ORKF86OhDOcTBJTxslUj/6bCsgg+581jW+dIfNvXxBSxHKHVrmGI= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1986.prod.exchangelabs.com (10.166.71.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Thu, 26 Oct 2017 16:58:33 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0178.007; Thu, 26 Oct 2017 16:58:33 +0000 From: "Mortensen, Andrew" To: Flemming Andreasen CC: Dave Dolson , "mohamed.boucadair@orange.com" , "Konda, Tirumaleswar Reddy" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AQHTTmDYYVl2kLz7RkacOc3XVqREO6L2Wo0A Date: Thu, 26 Oct 2017 16:58:33 +0000 Message-ID: <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> In-Reply-To: <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.130.192.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1986; 6:A2ecHcPps1Rqla6YkEtnsHVwiNWVxb1MJfKwveVAHXwecX8Ciicaq0sKGZEXRSdDabDCnaeQG/WUmIumoT/5gv1Ok1LrhbHG1C+F574Td1Vg6QmRlsHdoDPGEtvqFwK/cpKlDs7qAWl6YEEUSBUkO62mBu0wfs7y1ozpMn7qDVUSP66yc+1fsgQ7WXYIufFYdGkkTg+mGJt3GRvrhOg0zJe70jmKkdGJu395T/A4DOuEBvuHwxHC84k7KTfn0jNfd8j+8dShy/44tSlX4+3IRg8XlGSLuyUM70zwsrRk34t+MXiMjhYMxfwpIzivWe6faDM8g05HgojGH3al/v2+r/o2aZCguLDqKqNDNtb9GEw=; 5:AYnCcedowJ8IY4Tr8sWD1INU5JWscixi0DsJXmLQTxonWa0tlZU4j1o5XigcEHTsNkCT38S3Gr7YQmdWxZoIygJtZ+JUE1bH0FAqrciqY4ADHgDOj0ZvbycJum+vc19gBpODwfnlb4Q2CaP6Zce76Z2mdvVotQMbraFSB85ZH2U=; 24:pDIkja+sU1q2ROsbt+pdrFxH9TGjxWE/2LCll/yz6uK3S/Kc3PVRb8my8uEnlm1TFjWyBexFK4dtznpj0pMMzOTM7IpnMKblWbILL/igSc0=; 7:AF64c8B/DQ8/G2f9V2yCyE9jCWZleAvr6Ti9mQ77owClnwoKQBwitplVZry2ZQvJjTtwczYTR96I1j0nkTtPwgXtdSUQ/g5ikhHnGyhm9+NEPwjOzDxtXRTpbdrHaCBOeG1J5F56zfLxN9MBG6+eS6oxsFiHlIFVEqp77P6XqCV6AVktZOUmtuxAIGCm8cR2GMoWNiwBayZfaMwoziUQfOI4ZDEwnNIqbYEp29HvAkcJgtJHrmp95vZxYsN23ppv x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3e8b8a70-202b-4204-081d-08d51c92cafb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603238); SRVR:BN3PR01MB1986; x-ms-traffictypediagnostic: BN3PR01MB1986: authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(166708455590820)(788757137089)(95692535739014)(18271650672692)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231020)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR01MB1986; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR01MB1986; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(13464003)(199003)(55784002)(189002)(57704003)(24454002)(81166006)(33656002)(81156014)(93886005)(4326008)(316002)(5660300001)(6306002)(6506006)(561944003)(54896002)(229853002)(36756003)(86362001)(106356001)(6436002)(2906002)(105586002)(3660700001)(83716003)(77096006)(3280700002)(66066001)(97736004)(2900100001)(6486002)(53546010)(966005)(606006)(54906003)(7736002)(102836003)(6116002)(3846002)(53936002)(82746002)(53946003)(6246003)(50986999)(189998001)(236005)(14454004)(101416001)(8676002)(478600001)(2950100002)(6916009)(8936002)(99286003)(68736007)(76176999)(25786009)(6512007)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1986; H:BN3PR01MB1987.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_6EDF1F8DAA034275951ECD98047E7C03arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 3e8b8a70-202b-4204-081d-08d51c92cafb X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 16:58:33.8264 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1986 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 16:58:40 -0000 --_000_6EDF1F8DAA034275951ECD98047E7C03arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBPY3QgMjYsIDIwMTcsIGF0IDk6NDYgQU0sIEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJl YXNAY2lzY28uY29tPG1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20+PiB3cm90ZToNCg0KQXMgSSBo YXZlIHN0YXRlZCBzZXZlcmFsIHRpbWVzIGJlZm9yZSwgSSdtIG5vdCBhbGwgdGhhdCBjb21mb3J0 YWJsZSB3aXRoIHRoZSBjdXJyZW50IHJlcXVpcmVtZW50IGFyb3VuZCBhbHdheXMgc2VuZGluZyBr ZWVwLWFsaXZlcywgd2hldGhlciBhdHRhY2tzIGFyZSBpbiBwcm9ncmVzcyBvciBub3cuIE15IGNv bmNlcm5zIGFyZSBhcm91bmQgc2NhbGFiaWxpdHkvY29zdCBvZiB0aGUgb3ZlcmFsbCBzb2x1dGlv biwgc28gSSB0aGluayBpdCdzIHdvcnRoIGNvbnNpZGVyaW5nIGR1cmluZyBwZWFjZS10aW1lIGF0 IGxlYXN0Lg0KDQpIaSBGbGVtbWluZy4gSSBzdXNwZWN0IHlvdXIgY29uY2VybnMgYXJlbuKAmXQg ZnVsbHkgYWRkcmVzc2VkIGJ5IHJlZHVjaW5nIHRoZSBoZWFydGJlYXQgTVVTVCB0byBhIFNIT1VM RCwgYXMgY2FwdHVyZWQgaW4gdGhpcyBpc3N1ZToNCg0KPGh0dHBzOi8vZ2l0aHViLmNvbS9kb3Rz d2cvZG90cy1yZXF1aXJlbWVudHMvaXNzdWVzLzU3Pg0KDQpEbyB3ZSBuZWVkIHRvIHJlY2FzdCB0 aGUgcmVxdWlyZW1lbnQgdG8gY2FwdHVyZSB0aGUgcGVhY2UtdGltZSBhc3BlY3Q/IEZvciBleGFt cGxlLCBzaG91bGQgYSBET1RTIHNlcnZlciBiZSBhYmxlIHRvIHRlbGwgYSBjbGllbnQgdG8gc3Rv cCBoZWFydGJlYXRzLCBvciBzbG93IHRoZSBoZWFydGJlYXQgcmF0ZT8NCg0KYW5kcmV3DQoNCg0K DQpPbiAxMC8yNi8xNyA5OjEzIEFNLCBEYXZlIERvbHNvbiB3cm90ZToNCkknbSBub3QgcHVzaGlu ZyBmb3IgdGhpcy4gSSBzYXcgdGhlIHdvcmtpbmcgZ3JvdXAgc3RydWdnbGluZyB3aXRoIHRoZSBm aXJld2FsbC9OQVQgcHJvYmxlbSwgYW5kIG9mZmVyZWQgYSBkaWZmZXJlbnQgd2F5IG9mIHRoaW5r aW5nIGFib3V0IGl0Lg0KVG8gYmUgY2xlYXIsIG15IHN1Z2dlc3Rpb24gaXMgdG8gcmVtb3ZlIHVu c29saWNpdGVkIG1lc3NhZ2VzIGZyb20gdGhlIHNlcnZlciB0byBjbGllbnQuDQoNCi1EYXZlDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IFttYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAy MDE3IDM6MDYgUE0NClRvOiBEYXZlIERvbHNvbjsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsg RmxlbW1pbmcgQW5kcmVhc2VuOyBKb24gU2hhbGxvdzsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90 c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RT IFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQoNClJlLSwNCg0KTm90IHN1cmUgaG93IHRvIGdl dCByaWQgb2YgdGhlIGNvbnN0cmFpbnQgaW1wb3NlZCBieSB0aGUgTkFUL0ZXIHRpbWVyLCBEYXZl Lg0KDQpUaGUgY3VycmVudCB0ZXh0IHNheXMgdGhlIGZvbGxvd2luZzoNCg0KICAgVG8gcHJvdmlk ZSBhIG1ldHJpYyBvZiBzaWduYWwgaGVhbHRoIGFuZCBkaXN0aW5ndWlzaCBhbiAnaWRsZScgc2ln bmFsDQogICBjaGFubmVsIGZyb20gYSAnZGlzY29ubmVjdGVkJyBvciAnZGVmdW5jdCcgc2Vzc2lv biwgdGhlIERPVFMgYWdlbnQNCiAgIHNlbmRzIGEgaGVhcnRiZWF0IG92ZXIgdGhlIHNpZ25hbCBj aGFubmVsIHRvIG1haW50YWluIGl0cyBoYWxmIG9mIHRoZQ0KICAgY2hhbm5lbC4gIFRoZSBET1RT IGFnZW50IHNpbWlsYXJseSBleHBlY3RzIGEgaGVhcnRiZWF0IGZyb20gaXRzIHBlZXINCiAgIERP VFMgYWdlbnQsIGFuZCBtYXkgY29uc2lkZXIgYSBzZXNzaW9uIHRlcm1pbmF0ZWQgaW4gdGhlIGV4 dGVuZGVkDQogICBhYnNlbmNlIG9mIGEgcGVlciBhZ2VudCBoZWFydGJlYXQuDQoNCldoaWNoIGNv dmVycyB5b3VyIHByb3Bvc2FsLiBObz8NCg0KU29saWNpdGVkIG1lc3NhZ2VzIGZyb20gdGhlIHNl cnZlciBkbyBub3QgcHJldmVudCBmcm9tIGZhaWx1cmVzLiBDb25zaWRlciB0aGUgY2FzZSB3aGVy ZSBhIERPVFMgc2VydmVyIGhhcyB0byBzZW5kIGEgbWl0aWdhdGlvbiBzdGF0dXMgdXBkYXRlIGJh Y2sgdG8gdGhlIGNsaWVudCwgYnV0IHRoZSBjbGllbnQgZGlkbid0IHJlZnJlc2hlZCB0aGUgc3Rh dGUuIE9yIHdoZW4gdGhlIE5BVCBmaXJlZCBvdXQgYSBtYXBwaW5nIGFuZCBhc3NpZ25zIHRoZSBl eHRlcm5hbCBwb3J0IHRvIGFub3RoZXIgaG9zdCB0aGFuIHRoZSBET1RTIGNsaWVudC4NCg0KRGlk IEkgbWlzc2VkIHNvbWV0aGluZz8NCg0KVGhhbmsgeW91Lg0KDQpDaGVlcnMsDQpNZWQNCg0KLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZSA6IERhdmUgRG9sc29uIFttYWlsdG86ZGRvbHNv bkBzYW5kdmluZS5jb21dIEVudm95w6kgOiBqZXVkaSAyNg0Kb2N0b2JyZSAyMDE3IDE0OjUwIMOA IDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgS29uZGEsIFRpcnVtYWxlc3dhcg0KUmVkZHk7 IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRv dHNAaWV0Zi5vcmc+IE9iamV0IDogUmU6DQpbRG90c10gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RT IFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQoNCk15IHBvaW50IHdhcyB0aGF0IGlmIHNlcnZl ciBzdGF0dXMgd2FzIHNvbGljaXRlZCwga2VlcC1hbGl2ZSBpbnRlcnZhbA0Kd291bGQgYmUgaW5k ZXBlbmRlbnQgb2YgZmlyZXdhbGwvTkFUIHRpbWVvdXQuIEtlZXAtYWxpdmVzIHdvdWxkIGJlDQpv cHRpb25hbC4NCg0KU29saWNpdGVkIG1lYW5zIHRoYXQgY2xpZW50IHNheXMgImdldCBzdGF0dXMi IHZzLiB0aGUgc2VydmVyIGp1c3QNCnNlbmRpbmcgdXBkYXRlcy4NCg0KDQoNCkRhdmlkIERvbHNv bg0KU2FuZHZpbmUNCiAgT3JpZ2luYWwgTWVzc2FnZQ0KRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NClNlbnQ6IFRo dXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDI6MTEgUE0NClRvOiBEYXZlIERvbHNvbjsgS29uZGEs IFRpcnVtYWxlc3dhciBSZWRkeTsgRmxlbW1pbmcgQW5kcmVhc2VuOyBKb24NClNoYWxsb3c7IGRv dHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERP VFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3DQooLTA2KSkNCg0KDQpI aSBEYXZlLA0KDQpUaGUgcHJvdG9jb2wgZG9lcyBhbHJlYWR5IHN1cHBvcnQgYSBtZWNoYW5pc20g dG8gc2VuZCBrZWVwYWxpdmUNCm1lc3NhZ2VzIGV2ZXJ5IDMwcyAocmVjb21tZW5kZWQgdmFsdWUp Lg0KDQpDaGVlcnMsDQpNZWQNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZSA6IERh dmUgRG9sc29uIFttYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb21dIEVudm95w6kgOiBqZXVkaSAy Ng0Kb2N0b2JyZSAyMDE3IDEzOjE1IMOAIDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsgQk9V Q0FEQUlSIE1vaGFtZWQNCklNVC9PTE47IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7 IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+IE9iamV0IDogUkU6DQpbRG90c10g RE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQoNCkkg dGhpbmsgdGhlcmUgaXMgYW5vdGhlciBvcHRpb24gdG8gaGFuZGxlIHRoZSBOQVQvZmlyZXdhbGwg cHJvYmxlbXMNCmJ5IGNoYW5naW5nIHRoZSBwcm90b2NvbC4NCg0KSWYgSSB1bmRlcnN0YW5kIGNv cnJlY3RseSwgY3VycmVudGx5IHRoZSBOQVQgYW5kIGZpcmV3YWxsIG5lZWQgdG8gYmUNCmtlcHQN Cm9wZW4gdG8gcGVybWl0IHVuc29saWNpdGVkIHNlcnZlciBwYWNrZXRzLg0KDQpJZiB0aGUgcHJv dG9jb2wgaXMgY2hhbmdlZCB0byByZXF1aXJlIGNsaWVudCBwb2xsaW5nIG9mIHRoZSBzZXJ2ZXIN CnVwZGF0ZXMsIHRoZSBOQVQgYW5kIGZpcmV3YWxsIHByb2JsZW1zIGdvIGF3YXkuDQoNCi1EYXZl DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERvdHMgW21haWx0bzpkb3Rz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLb25kYSwNClRpcnVtYWxlc3dhcg0KUmVk ZHkNClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDEyOjU4IFBNDQpUbzogbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT47IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7DQpkb3RzQGlldGYub3JnPG1haWx0 bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTICYgTkFUICh3YXMgUkU6 IERPVFMgUmVxdWlyZW1lbnRzIHJldmlldw0KKC0wNikpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQpbbWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21dDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNiwgMjAx NyAyOjIxIFBNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPFRpcnVtYWxlc3dhclJl ZGR5X0tvbmRhQE1jQWZlZS5jb20+Ow0KRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0BjaXNj by5jb20+OyBKb24gU2hhbGxvdyA8c3VwanBzLQ0KaWV0ZkBqcHNoYWxsb3cuY29tPjsgZG90c0Bp ZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTICYgTkFUICh3YXMgUkU6IERPVFMgUmVx dWlyZW1lbnRzIHJldmlldw0KKC0wNikpDQoNClJlLSwNCg0KSSBoZWFyIHlvdS4gTXkgdGFrZSBp cyB0aGF0IHdlIGRvbid0IG5lZWQgdG8gcmVjb21tZW5kIHdoaWNoDQpjb21wYW5pb24gInByb3Rv Y29scy9tZWNoYW5pc21zIiBuZWVkIHRvIGJlIHN1cHBvcnRlZCBmb3IgTkFUL0ZXDQp0cmF2ZXJz YWwgcHVycG9zZXMuIEhhdmluZyBhIGRpc2N1c3Npb24gYXQgdGhlIHNhbWUgbGV2ZWwgaW4gODA4 NQ0Kd291bGQgYmUgc3VmZmljaWVudCwgSU1ITy4NCg0KTGV0J3MgZm9jdXMgb24gdGhlIHNpbXBs ZSBidWlsdC1pbiBmZWF0dXJlIGZvciBOQVQgZGV0ZWN0Lg0KSSBkb24ndCB0aGluayB0aGUgc2lt cGxlIGJ1aWx0LWluIGZlYXR1cmUgaXMgc3VmZmljaWVudCwgRE9UUyBjbGllbnQNCndpbGwNCmhh dmUgdG8gcmVseSBvbiBtZWNoYW5pc21zIGRpc2N1c3NlZCBpbiA4MDg1IGZvciBib3RoIGZpcmV3 YWxsIGFuZA0KTkFUIHRyYXZlcnNhbC4NCg0KLVRpcnUNCg0KQ2hlZXJzLA0KTWVkDQoNCi0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGUgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQpb bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb21dDQpFbnZvecOpIDogamV1 ZGkgMjYgb2N0b2JyZSAyMDE3IDEwOjM2IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQNCklNVC9PTE47 IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRv dHNAaWV0Zi5vcmc+IE9iamV0IDoNClJFOiBbRG90c10gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RT IFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQoNCkJ1dCBOQVRzIGFyZSBub3QgdGhlIG9ubHkg cHJvYmxlbSwgZmlyZXdhbGxzIHdpbGwgYWxzbyBiZSBtb3N0DQpsaWtlbHkgcHJlc2VudCwgYW5k IFNUVU4gaGVscHMgZGlzY292ZXIgYm90aCBOQVRzIGFuZCBmaXJld2FsbHMNCmFuZCB1c2VmdWwg ZXZlbiBpbiBJUHY2IG5ldHdvcmtzIHRvIGRldGVybWluZSB0aGUga2VlcGFsaXZlDQppbnRlcnZh bCBvZg0KZmlyZXdhbGwuDQotVGlydQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT4NClttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NClNlbnQ6 IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDE6NTIgUE0NClRvOiBLb25kYSwgVGlydW1hbGVz d2FyIFJlZGR5DQo8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGly dW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4+Ow0KRmxlbW1pbmcgQW5kcmVhc2VuIDxm YW5kcmVhc0BjaXNjby5jb208bWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbT4+OyBKb24gU2hhbGxv dyA8c3VwanBzLQ0KaWV0ZkBqcHNoYWxsb3cuY29tPG1haWx0bzppZXRmQGpwc2hhbGxvdy5jb20+ PjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbRG90 c10gRE9UUyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cw0KcmV2aWV3DQooLTA2KSkN Cg0KVGlydSwNCg0KWWVzLCBTVFVOIGNhbiBiZSBsaXN0ZWQgYXMgcGFydCBvZiB0aGUgZXhpc3Rp bmcgdG9vbHMgYm94DQooYW1vbmcgdGhlDQpsaW5lcyBvZg0Kd2hhdCBpcyBhbHJlYWR5IGRpc2N1 c3NlZCBpbiA4MDg1KS4NCg0KSSBkb24ndCB0aGluayB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIHJl cXVpcmUgU1RVTiBzdXBwb3J0IGJ5DQpET1RTDQpjbGllbnRzLg0KVGhlIHByb3Bvc2FsIGlzIHRv IGluY2x1ZGUgYSBzaW1wbGUgYnVpbHQtaW4gZmVhdHVyZSBpbiB0aGUNCkRPVFMNCnByb3RvY29s IGl0c2VsZg0KdGhhdCBjYW4gaGVscCB0byBkZXRlY3QgTkFUcy4gVGhlIHN1cHBvcnQgb2Ygc3Vj aCBmZWF0dXJlDQp3aWxsLCBlLmcuLA0KZWFzZQ0KdHJvdWJsZXNob290aW5nIHdoZW4gY29ubmVj dGl2aXR5IHByb2JsZW1zIGFyZSBleHBlcmllbmNlZCBvbg0KdGhlIHBhdGggYmV0d2VlbiBhIGNs aWVudCBhbmQgYSBzZXJ2ZXIuDQoNCkNoZWVycywNCk1lZA0KDQotLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCkRlIDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KW21haWx0bzpUaXJ1bWFs ZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KRW52b3nDqSA6IGpldWRpIDI2IG9jdG9icmUg MjAxNyAwOTo0NCDDgCA6IEJPVUNBREFJUiBNb2hhbWVkDQpJTVQvT0xOOyBGbGVtbWluZyBBbmRy ZWFzZW47IEpvbiBTaGFsbG93OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPiBP YmpldCA6DQpSRTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMg cmV2aWV3DQooLTA2KSkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERvdHMg W21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NClNl bnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjQsIDIwMTcgMjoyMCBQTQ0KVG86IEZsZW1taW5nIEFuZHJl YXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPjsgSm9uIFNoYWxsb3cNCjxzdXBqcHMtIGlldGZAanBz aGFsbG93LmNvbT47IGRvdHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyAmIE5B VCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cw0KcmV2aWV3DQooLTA2KSkNCg0KSGkgRmxlbW1p bmcsIGFsbCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQotLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0gRGUgOiBGbGVtbWluZyBBbmRyZWFzZW4NClttYWlsdG86ZmFu ZHJlYXNAY2lzY28uY29tXSBFbnZvecOpIDoNCmx1bmRpDQoyMyBvY3RvYnJlIDIwMTcgMTc6MzYg w4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBKb24NClNoYWxsb3c7IGRvdHNAaWV0Zi5v cmcgT2JqZXQgOiBSZTogRE9UUyAmIE5BVCAod2FzIFJFOg0KW0RvdHNdIERPVFMgUmVxdWlyZW1l bnRzIHJldmlldyAoLTA2KSkNCg0KDQoNCk9uIDEwLzIzLzE3IDg6MjggQU0sIG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQpIaSBKb24sIGFsbCwNCg0KSSBhZ3JlZSB3aXRoIEZs ZW1taW5nIHRoYXQgInNvbWUgbW9yZSB3b3JrIiBpcyBuZWVkZWQuDQpJTUhPLCB0aGlzIGlzIGEN CnR5cGljYWwgZGlzY3Vzc2lvbiB0byBpbmNsdWRlIGluIGEgZGVkaWNhdGVkIHNlY3Rpb24gaW4N CnRoZSBET1RTIGFyY2hpdGVjdHVyZSBJLUQuDQpBZ3JlZWQuDQo+RnJvbSBhIHJlcXVpcmVtZW50 IHN0YW5kcG9pbnQsIHdlIGRvbid0IG5lZWQgdG8NCmVsYWJvcmF0ZSBob3cgdGhlDQpwcm90b2Nv bHMgd2lsbCBmdWxmaWwgaXQuIFNJRy0xMCBkb2VzIGV2ZW4gYSBuaWNlIGpvYiBieQ0KY2l0aW5n DQpSRkM4MDg1IHdoaWNoIHBvaW50cyB0byBOQVQgdHJhdmVyc2FsIG1lY2hhbmlzbXMuIE9uZQ0K Y291bGQgcGljayBoaXMvaGVyIGZhdm9yaXRlIHByb3RvY29sIGZyb20gdGhlIGxpc3QgaW4NCjgw ODUgdG8gZGlzY292ZXIgdGhlIGV4dGVybmFsIElQIGFkZHJlc3MvcHJlZml4LCBpZg0KbmVlZGVk LiBFeHRlcm5hbCBJUCBhZGRyZXNzZXMvcHJlZml4ZXMgY2FuIGJlIElQdjQgZm9yIGENCk5BVDQ0 IG9yIE5BVDY0LCBidXQgY2FuIGJlDQpJUHY2IHByZWZpeGVzIGZvciBlbnRlcnByaXNlcyBkZXBs b3lpbmcgTlBUdjYsIGFuZCBzbyBvbi4NClBhcnQgb2YgdGhlIGNoYWxsZW5nZSBoZXJlIGlzIHRo YXQgdGhlIGF0dGFjayB0YXJnZXQgYW5kDQp0aGUgRE9UUyBjbGllbnQgYXJlIG5vdCBuZWNlc3Nh cmlseSBvbmUgYW5kIHRoZSBzYW1lLA0Kd2hpY2ggbWFrZXMgaXQgbW9yZSBkaWZmaWN1bHQgdG8g ZGV0ZXJtaW5lIHRoZQ0KcHVibGljLWZhY2luZyBJUC1hZGRyZXNzL3BvcnQgdW5kZXIgYXR0YWNr IChhdCBsZWFzdCBpZg0KdGhlIERPVFMgY2xpZW50IGlzIGdvaW5nIHRvDQpkbyBpdCkuDQpbTWVk XSBUaGlzIGlzIGV4YWN0bHkgdGhlIGtpbmQgb2YgdGhlIGRpc2N1c3Npb24gdG8gaGF2ZS4NClRo YW5rcy4NCldpdGggb3Igd2l0aG91dCBOQVQsIERPVFMgY2xpZW50cyBhcmUgYXNzdW1lZCB0byBi ZSBmZWQNCndpdGggdGhlDQppbnRlcm5hbA0KdGFyZ2V0KHMpLiBUaGlzIGNhbiBiZSBhY2hpZXZl ZCBieSBwcm92aXNpb25pbmcgKGxpa2VseSkNCm9yIGJ5IGRpc2NvdmVyeQ0KbWVhbnMNCihlLmcu LCByZXNpZGVudGlhbCBvciBzbWFsbCBlbnRlcnByaXNlIG5ldHdvcmtzKS4NCg0KQ2FuIHdlIGFz c3VtZSB0aGF0IHRoZSBkaXNjb3Zlcnkgb2YgdGhlIGV4dGVybmFsIElQDQphZGRyZXNzL3ByZWZp eC8uLiBpcw0KZG9uZQ0KYnkgYSBET1RTIGNsaWVudCBvbmx5IGlmIGl0IGlzIGV4cGxpY2l0bHkg aW5zdHJ1Y3RlZCB0byBkbyBzbz8NCg0KDQpJbiBzb21lIGRlcGxveW1lbnRzLCBET1RTIGNsaWVu dHMgbWF5IGJlIHByb3Zpc2lvbmVkDQp3aXRoIHRoZSBzZXQgb2YNCmludGVybmFsIHJlc291cmNl cywgc28gdGhlcmUgaXMgbm8gbmVlZCBmb3IgZGlzY292ZXJ5Lg0KQWxzbywgYXMgSm9uIG1lbnRp b25lZCwgRE9UUyBnYXRld2F5cyBjYW4gYmUgb2YgaGVscA0KdG8gc2V0IHRoZQ0KYXBwcm9wcmlh dGUgSVAgYWRkcmVzc2VzL3ByZWZpeGVzL3BvcnQgbnVtYmVycyBpbiB0aGUNCnByZXNlbmNlIG9m IHRyYW5zbGF0b3JzLg0KQWdyZWVkIC0gYnV0IHRoZXkgc3RpbGwgbmVlZCBhIHdheSB0byBmaWd1 cmUgb3V0IHRoZQ0KcHJpdmF0ZS9wdWJsaWMgbWFwcGluZyBmb3IgYSBnaXZlbiBhdHRhY2sgdGFy Z2V0Lg0KW01lZF0gQmVjYXVzZSBhIEREb1MgYXR0YWNrIGlzIG9ic2VydmVkIGZyb20gdGhlIGlu dGVybmFsDQpuZXR3b3JrLA0KbWFwcGluZyhzKSBhcmUgbmVjZXNzYXJpbHkgbWFpbnRhaW5lZCBi eSB0aGUgb24tcGF0aA0KdHJhbnNsYXRvcihzKS4NCk90aGVyd2lzZSwgdGhlIGluY29taW5nIGF0 dGFjayB0cmFmZmljIGNvdWxkbid0IGJlDQpmb3J3YXJkZWQgdG8gaW50ZXJuYWwNCmhvc3RzLg0K VGhpcyBtb2RlbCBhc3N1bWVzIHRoYXQgdGhlIGdhdGV3YXkgaXMgY29sbG9jYXRlZCB3aXRoIHRo ZQ0KTkFULg0KU28sIHRoZSBnYXRld2F5IGNhbiByZXBsYWNlIHRoZSBpbnRlcm5hbCBJUCBhZGRy ZXNzL3ByZWZpeA0Kd2l0aCB0aGUgb25lDQpyZXRyaWV2ZXMNCmZyb20gdGhlIE5BVCBtYXBwaW5n IHRhYmxlLg0KDQpEbyB5b3Ugc2VlIGFueSBpc3N1ZSB3aXRoIHRoaXMgc2NoZW1lPw0KDQpBbiBv cGVuIHF1ZXN0aW9uIHRob3VnaCB3b3VsZCBiZSB0byBkaXNjdXNzIGlmIHRoZXJlDQppcyBhIHZh bHVlIGluDQpoYXZpbmcgYSBmZWF0dXJlIGluIHRoZSBET1RTIHByb3RvY29sIHRvIGluZm9ybSBh IERPVFMNCmNsaWVudCB0aGF0IGEgTkFUIGlzIGRldGVjdGVkIG9uLXBhdGguIFRoaXMgY2FuIGJl DQpwcmVzZW50ZWQgYXMgYW4gaW5mb3JtYXRpb24gZWxlbWVudCByZXR1cm5lZCBieSB0aGUNCnNl cnZlciB0byB0aGUgY2xpZW50LiBUaGlzIGluZm9ybWF0aW9uIGNhbiBiZSwgZm9yDQpleGFtcGxl LCB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gYWRqdXN0IGl0cyBIVCBpbnRlcnZhbCwNCmFkanVzdCB0 aGUgaW50ZXJuYWwgSVAgYWRkcmVzc2VzL3ByZWZpeGVzIHRvIGJlDQpwcm90ZWN0ZWQsIGV0Yy4N Ck9waW5pb25zPw0KSXQgc291bmRzIGFwcGVhbGluZywgYnV0IGl0J3MgdmVyeSBkaWZmaWN1bHQg dG8gZG8gdGhpcw0KcmVsaWFibHksIGFuZCBpdCdzIG5vdCBqdXN0IE5BVHMgdGhhdCBhcmUgYW4g aXNzdWUgaGVyZTsNCkZpcmV3YWxscyBwcmVzZW50IHNpbWlsYXIgY2hhbGxlbmdlcyAoYW5kIHRo ZXkgbWF5IG9yDQptYXkgbm90IGJlIE5BVCdpbmcgaW5kaXZpZHVhbA0KZmxvd3MpLg0KW01lZF0g SSBmdWxseSBhZ3JlZSB0aGF0IGZpcmV3YWxscyBkZXRlY3QgaXMgbW9yZSBjb21wbGV4Lg0KTGV0 J3MgcHV0IGl0DQphc2lkZQ0KYW5kIGZvY3VzIG9uIHRoZSBOQVQgY2FzZS4NClRoZSBwcmVzZW5j ZSBhbmQgYmVoYXZpb3Igb2YgTkFUIGFuZCBGaXJld2FsbCwgYW5kIGtlZXBhbGl2ZQ0KaW50ZXJ2 YWwgY2FuIGJlIGRldGVybWluZWQgdXNpbmcgU1RVTiAoZGlzY3Vzc2VkIGluDQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTc4MCkuDQoNCi1UaXJ1DQoNCldlIGNhbiBjb25zaWRlciBt YW55IGFwcHJvYWNoZXMgdG8gZGV0ZWN0IGEgTkFULCBlLmcuLA0KDQooMSkgVGhlIERPVFMgY2xp ZW50IGluc2VydHMgaW4gdGhlIGNvcmUgbWVzc2FnZSB0aGUgSVANCmFkZHJlc3MvcG9ydCBpdA0K dXNlcyB0bw0Kc2VuZCB0aGUgcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuIFVwb24gcmVjZWlw dCBvZiB0aGUNCnJlcXVlc3QgYnkgdGhlIERPVFMgc2VydmVyLCBpdCBjaGVja3MgaWYgdGhlIGVu Y2xvc2VkIElQDQphZGRyZXNzL3BvcnQgbWF0Y2ggdGhlIHNvdXJjZQ0KSVANCmFkZHJlc3MvcG9y dCBvZiB0aGUgcmVjZWl2ZWQgcGFja2V0LiBJZiB5ZXMsIHRoZSBzZXJ2ZXINCnNldHMgaW4gdGhl DQpyZXNwb25zZSBhDQpkZWRpY2F0ZWQgcGFyYW1ldGVyIHRvIGluZGljYXRlIHRoYXQgYSB0cmFu c2xhdG9yIGlzDQpkZXRlY3RlZA0Kb24tDQpwYXRoLg0KKDIpIFRoZSBET1RTIHNlcnZlciBpbnNl cnRzIHN5c3RlbWF0aWNhbGx5IHRoZSBzb3VyY2UgSVANCmFkZHJlc3MvcG9ydCBpbg0KYQ0KcmVz cG9uc2UgdG8gYSBtZXNzYWdlIGZyb20gYSBET1RTIGNsaWVudC4gVXBvbiByZWNlaXB0IG9mDQp0 aGF0IHJlc3BvbnNlLCB0aGUgRE9UUyBjbGllbnQgY29tcGFyZXMgdGhlIGVuY2xvc2VkDQphZGRy ZXNzL3BvcnQgd2l0aCB0aGUgb25lcyBpdCB1c2VkDQp0bw0Kc2VuZCB0aGUgcmVxdWVzdCB0byBk ZXRlY3QgYW55IG1pc21hdGNoLg0KDQoNCi0tIEZsZW1taW5nDQoNCg0KQ2hlZXJzLA0KTWVkDQoN Ci0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLSBEZSA6IERvdHMNClttYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvbg0KU2hhbGxvdyBFbnZvecOpIDogbHVuZGkg MjMgb2N0b2JyZSAyMDE3IDEzOjE4IMOAIDoNCidGbGVtbWluZyBBbmRyZWFzZW4nOyBkb3RzQGll dGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPiBPYmpldCA6IFJlOg0KW0RvdHNdIERPVFMgUmVx dWlyZW1lbnRzIHJldmlldyAoLTA2KQ0KDQpIaSBGbGVtbWluZywNCg0KVGhlIHdheSBteSBtaW5k IHdvcmtzIGlzIHRvIHRoaW5rIG9mIGEgcHJhY3RpY2FsDQpzaXR1YXRpb24gYW5kIHNlZSBpZiB0 aGluZ3MgZml0Lg0KDQpBcyBJIHJlYWQgU0lHLTAxMCwgdGhlcmUgY291bGQgYmUgYSBET1RTIGNs aWVudCB3aXRoDQphIG1hbmFnZW1lbnQgSVAgYWRkcmVzcyB0aGF0IGlzIFJGQzE5MTggLSB0aGlz IGNsaWVudA0KY291bGQgYmUgbW9uaXRvcmluZyBOZXRmbG93IGluZm9ybWF0aW9uIGFuZCBjYW4N CnJlcXVlc3QgbWl0aWdhdGlvbiBmb3IgdGhlIGFwcHJvcHJpYXRlIHB1YmxpYyBJUHMNCnRoYXQN CmFyZSBiZWluZyBtb25pdG9yZWQuICBTbyBTSUctMDEwIGlzIG5lZWRlZCBmb3IgdGhpcw0KdXNl DQpjYXNlLg0KSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBET1RTIHNlcnZlciBhcyB0 bw0Kd2hldGhlciBpdCBhY2NlcHRzIGEgbWl0aWdhdGlvbiByZXF1ZXN0IGZvciBhDQpwYXJ0aWN1 bGFyIHRhcmdldCBpcCAob3IgZG9tYWluDQpldGMuKSBvcg0Kbm90Lg0KSWYgdGhlcmUgaXMgZ29p bmcgdG8gYmUgYSBOQVQgYm9yZGVyIHdoZXJlIHB1YmxpYyBJUHMNCmFyZSBtYXBwZWQgaW50byBw cml2YXRlIElQcyAoYW5kIHZpY2UgdmVyc2EpLCBJIHdvdWxkDQp0aGVuIGV4cGVjdCB0aGVyZSB0 byBiZSBhIERPVFMgZ2F0ZXdheSBiZXR3ZWVuIHRoZXNlDQoyIHpvbmVzLCBhbmQgaXQgaXMgdGhl IHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBET1RTDQpnYXRld2F5IHRvIGRvIGFueSB0YXJnZXQtaXAN Cm1hcHBpbmdzLg0KUmVnYXJkcw0KDQpKb24NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IERvdHMgW21haWx0bzppZXRmLXN1cGpwcy1kb3RzLWJvdW5jZXNAaWV0Zi5vcmddDQpP biBCZWhhbGYgT2YgRmxlbW1pbmcgQW5kcmVhc2VuDQpTZW50OiAyMiBPY3RvYmVyIDIwMTcgMjA6 MTcNClRvOiBkb3RzOyBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnPg0KU3ViamVjdDogW0RvdHNd IERPVFMgUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KQ0KDQpHcmVldGluZ3MNCg0KSSBoYXZlIHJl dmlld2VkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgRE9UUw0KcmVxdWlyZW1lbnRzIGRyYWZ0 DQooaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cw0K LQ0KMDYudHh0KS4NCkluDQpnZW5lcmFsLA0KSSB0aGluayB0aGUgZHJhZnQgaXMgaW4gZ29vZCBz aGFwZSB3aXRoIG9ubHkgYSBmZXcNCmVkaXRzIHJlcXVpcmVkLCBzbyBJIGhvcGUgd2UgY2FuIG1v dmUgdG8gV0dMQyBzb29uLiBJDQpoYXZlIGEgZmV3IGNvbW1lbnRzIGJlbG93IChvZiB3aGljaA0K dGhlDQpOQVQgb25lIGlzIHRoZSBvbmx5IHJlYWwgc3Vic3RhbnRpYWwgb25lKS4gSSBoYXZlDQph bHNvIHN1Ym1pdHRlZCBhIHB1bGwgcmVxdWVzdCB3aXRoIGEgZmV3IG5pdCBmaXhlcyBvbiBHaXRI dWI6DQoNCg0KU2VjdGlvbiAxLjINCi0gVGhlIGRlZmluaXRpb24gb2YgIkRPVFMgU2lnbmFsIiBp cyBzbGlnaHRseQ0KaW5jb25zaXN0ZW50IHdpdGggdGhlIHJlc3BlY3RpdmUgIkNsaWVudCBTaWdu YWwiIGFuZA0KIlNlcnZlciBTaWduYWwiIGRlZmluaXRpb25zLg0KU0lHLTAwNToNCi0gTm90IGNs ZWFyIHRoYXQgYWx3YXlzIHJlcXVpcmluZyAibnVtYmVyIG9mIHBhY2tldHMiDQptZXRyaWNzIGlz IG1lYW5pbmdmdWwuIENvbnNpZGVyIFRDUC1iYXNlZCBhdHRhY2tzIGZvcg0KZXhhbXBsZS4gTnVt YmVyIG9mIGJ5dGVzIG1heSBhbHdheXMgYmUgb2sgLSBhYm92ZSBhbmQNCmJleW9uZCB0aGF0IGl0 IHNob3VsZCBwcm9iYWJseSBiZSBleHRlbnNpYmxlIGFuZC9vcg0KYXR0YWNrDQpkZXBlbmRlbnQu DQotIEkgZG9uJ3QgdGhpbmsgdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudCBzaG91bGQgZ2V0DQpp bnRvIHNwZWNpZnlpbmcNCnRpbWVyDQp2YWx1ZXMgLSBleHBvbnRpYWwgYmFja29mZiB3aXRoIHNv bWUgbWF4aW11bSB2YWx1ZQ0Kc2VlbXMgYWJvdXQgdGhlDQpyaWdodA0KbGV2ZWwgb2YgZGV0YWls IGhlcmUuDQoNClNJRy0wMDk6DQotIFRvIGJlIGNsZWFyLCB0aGUgY29uZmxpY3RzIG9ubHkgYXBw bHkgd2l0aGluIGENCnNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIHJpZ2h0ID8gRm9yIGV4 YW1wbGUsIGlmDQphIGNsaWVudCB0ZWxscyB0aGUgc2FtZSBkb21haW4gdG8gYWx0ZXJuYXRlbHkg dHVybg0Kb24vb2ZmIG1pdGlnYXRpb24gZm9yIGEgZ2l2ZW4gcHJlZml4LCByb3V0ZSBmbGFwcGlu Zw0KbWF5DQpvY2N1ci4gVGhlIHNhbWUgY29uY2VybiBkb2VzIG5vdCBhcHBseSBpZiBhIGNsaWVu dA0KdGVsbHMgdHdvIGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIHRvDQpyZXNwZWN0 aXZlIHR1cm4gbWl0aWdhdGlvbiBvbiAoZG9tYWluIDEpIGFuZA0Kb2ZmDQooZG9tYWluIDIpLiBJ ZiBzbywgY2FuIHdlIGNsYXJpZnkgdGhhdCAoYWxzbyBpbiBsaWV1DQpvZiBzb21lIG9mIHRoZQ0K bXVsdGktDQpob21pbmcgY29tbWVudHMgcmFpc2VkIHByZXZpb3VzbHkpID8NCg0KU0lHLTAxMDoN Ci0gRE9UUyBDbGllbnQgYmVoaW5kIE5BVC4gT24gb25lIGhhbmQsIGl0IHNlZW1zDQpyZWFzb25h YmxlIHRvIGhhdmUgdGhpcyByZXF1aXJlbWVudCBzaW5jZSBjbGllbnRzIGZvcg0Kc3VyZSBjYW4g YmUgYmVoaW5kIE5BVHMsIGFuZA0Kd2l0aA0KdGhpbmdzDQpsaWtlIGR5bmFtaWMgRE5TLCB0aGV5 IGNhbiAgICAgY2VydGFpbmx5IGJlIHJlYWNoYWJsZS4NCkhvd2V2ZXIsDQppZg0Kd2UNCmRvDQp3 YW50IHRvIGFsbG93IGZvciB0aGlzIHNjZW5hcmlvLCBhbmQgaW4gcGFydGljdWxhcg0KZm9yIHRo ZSBET1RTIGNsaWVudA0KdG8NCmhhdmUgYSBwcml2YXRlIElQLWFkZHJlc3MgKHBvdGVudGlhbGx5 IGJlaGluZA0KbXVsdGlwbGUgTkFUcyksIHRoZW4gd2UNCmhhdmUNCm1vcmUgd29yayB0byBkbyBi ZWNhdXNlIGl0IHdvbid0IGRvIHRoZSBET1RTIHNlcnZlcg0KYW55IGdvb2QgdG8gZ2V0IGEgbWl0 aWdhdGlvbiByZXF1ZXN0IHJlZmVycmluZyB0bw0KdGhhdCBwcml2YXRlIElQLWFkZHJlc3MgKG9y DQpwcmVmaXgpLg0KDQpUaGFua3MNCg0KLS0gRmxlbW1pbmcNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRvdHMgbWFpbGluZyBsaXN0DQpEb3RzQGll dGYub3JnPG1haWx0bzpEb3RzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kb3RzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0KRG90c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQouDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0KRG90c0BpZXRm Lm9yZzxtYWlsdG86RG90c0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZG90cw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkRvdHMgbWFpbGluZyBsaXN0DQpEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQouDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRvdHMgbWFp bGluZyBsaXN0DQpEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoNCg== --_000_6EDF1F8DAA034275951ECD98047E7C03arbornet_ Content-Type: text/html; charset="utf-8" Content-ID: <2A704161CF4F024FBAAF395760FF2734@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBPY3Qg MjYsIDIwMTcsIGF0IDk6NDYgQU0sIEZsZW1taW5nIEFuZHJlYXNlbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmZhbmRyZWFzQGNpc2NvLmNvbSIgY2xhc3M9IiI+ZmFuZHJlYXNAY2lzY28uY29tPC9hPiZn dDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+QXMgSSBoYXZlIHN0YXRlZCBzZXZlcmFsIHRp bWVzIGJlZm9yZSwgSSdtIG5vdCBhbGwgdGhhdCBjb21mb3J0YWJsZSB3aXRoIHRoZSBjdXJyZW50 IHJlcXVpcmVtZW50IGFyb3VuZCBhbHdheXMgc2VuZGluZyBrZWVwLWFsaXZlcywgd2hldGhlciBh dHRhY2tzIGFyZSBpbiBwcm9ncmVzcyBvciBub3cuIE15IGNvbmNlcm5zIGFyZSBhcm91bmQgc2Nh bGFiaWxpdHkvY29zdCBvZiB0aGUgb3ZlcmFsbCBzb2x1dGlvbiwgc28gSSB0aGluaw0KIGl0J3Mg d29ydGggY29uc2lkZXJpbmcgZHVyaW5nIHBlYWNlLXRpbWUgYXQgbGVhc3QuPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2PkhpIEZsZW1taW5nLiBJIHN1c3BlY3QgeW91ciBjb25jZXJucyBhcmVu4oCZdCBm dWxseSBhZGRyZXNzZWQgYnkgcmVkdWNpbmcgdGhlIGhlYXJ0YmVhdCBNVVNUIHRvIGEgU0hPVUxE LCBhcyBjYXB0dXJlZCBpbiB0aGlzIGlzc3VlOjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3Bh Y2U6cHJlIj48L3NwYW4+Jmx0OzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9kb3Rzd2cvZG90 cy1yZXF1aXJlbWVudHMvaXNzdWVzLzU3IiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vZG90 c3dnL2RvdHMtcmVxdWlyZW1lbnRzL2lzc3Vlcy81NzwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5EbyB3ZSBuZWVkIHRvIHJlY2FzdCB0aGUgcmVxdWlyZW1l bnQgdG8gY2FwdHVyZSB0aGUgcGVhY2UtdGltZSBhc3BlY3Q/IEZvciBleGFtcGxlLCBzaG91bGQg YSBET1RTIHNlcnZlciBiZSBhYmxlIHRvIHRlbGwgYSBjbGllbnQgdG8gc3RvcCBoZWFydGJlYXRz LCBvciBzbG93IHRoZSBoZWFydGJlYXQgcmF0ZT88L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2PmFuZHJldzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCk9uIDEwLzI2 LzE3IDk6MTMgQU0sIERhdmUgRG9sc29uIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPkknbSBub3QgcHVzaGluZyBmb3IgdGhpcy4gSSBzYXcgdGhl IHdvcmtpbmcgZ3JvdXAgc3RydWdnbGluZyB3aXRoIHRoZSBmaXJld2FsbC9OQVQgcHJvYmxlbSwg YW5kIG9mZmVyZWQgYSBkaWZmZXJlbnQgd2F5IG9mIHRoaW5raW5nIGFib3V0IGl0LjxiciBjbGFz cz0iIj4NClRvIGJlIGNsZWFyLCBteSBzdWdnZXN0aW9uIGlzIHRvIHJlbW92ZSB1bnNvbGljaXRl ZCBtZXNzYWdlcyBmcm9tIHRoZSBzZXJ2ZXIgdG8gY2xpZW50LjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCi1EYXZlPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnIgY2xhc3M9IiI+DQpGcm9tOiA8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgY2xhc3M9IiI+bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4gWzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIiBjbGFzcz0iIj5tYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTwvYT5dPGJyIGNsYXNzPSIiPg0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjYsIDIwMTcgMzow NiBQTTxiciBjbGFzcz0iIj4NClRvOiBEYXZlIERvbHNvbjsgS29uZGEsIFRpcnVtYWxlc3dhciBS ZWRkeTsgRmxlbW1pbmcgQW5kcmVhc2VuOyBKb24gU2hhbGxvdzsgPGEgaHJlZj0ibWFpbHRvOmRv dHNAaWV0Zi5vcmciIGNsYXNzPSIiPg0KZG90c0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpT dWJqZWN0OiBSRTogW0RvdHNdIERPVFMgJmFtcDsgTkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1l bnRzIHJldmlldyAoLTA2KSk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSZS0sPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTm90IHN1cmUgaG93IHRvIGdldCByaWQgb2YgdGhlIGNv bnN0cmFpbnQgaW1wb3NlZCBieSB0aGUgTkFUL0ZXIHRpbWVyLCBEYXZlLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NClRoZSBjdXJyZW50IHRleHQgc2F5cyB0aGUgZm9sbG93aW5nOjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO1RvIHByb3ZpZGUgYSBt ZXRyaWMgb2Ygc2lnbmFsIGhlYWx0aCBhbmQgZGlzdGluZ3Vpc2ggYW4gJ2lkbGUnIHNpZ25hbDxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2NoYW5uZWwgZnJvbSBhICdkaXNjb25uZWN0 ZWQnIG9yICdkZWZ1bmN0JyBzZXNzaW9uLCB0aGUgRE9UUyBhZ2VudDxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyZuYnNwO3NlbmRzIGEgaGVhcnRiZWF0IG92ZXIgdGhlIHNpZ25hbCBjaGFubmVs IHRvIG1haW50YWluIGl0cyBoYWxmIG9mIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwO2NoYW5uZWwuICZuYnNwO1RoZSBET1RTIGFnZW50IHNpbWlsYXJseSBleHBlY3RzIGEgaGVh cnRiZWF0IGZyb20gaXRzIHBlZXI8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtET1RT IGFnZW50LCBhbmQgbWF5IGNvbnNpZGVyIGEgc2Vzc2lvbiB0ZXJtaW5hdGVkIGluIHRoZSBleHRl bmRlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2Fic2VuY2Ugb2YgYSBwZWVyIGFn ZW50IGhlYXJ0YmVhdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpXaGljaCBjb3ZlcnMg eW91ciBwcm9wb3NhbC4gTm8/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU29saWNpdGVk IG1lc3NhZ2VzIGZyb20gdGhlIHNlcnZlciBkbyBub3QgcHJldmVudCBmcm9tIGZhaWx1cmVzLiBD b25zaWRlciB0aGUgY2FzZSB3aGVyZSBhIERPVFMgc2VydmVyIGhhcyB0byBzZW5kIGEgbWl0aWdh dGlvbiBzdGF0dXMgdXBkYXRlIGJhY2sgdG8gdGhlIGNsaWVudCwgYnV0IHRoZSBjbGllbnQgZGlk bid0IHJlZnJlc2hlZCB0aGUgc3RhdGUuIE9yIHdoZW4gdGhlIE5BVCBmaXJlZCBvdXQgYSBtYXBw aW5nIGFuZCBhc3NpZ25zIHRoZQ0KIGV4dGVybmFsIHBvcnQgdG8gYW5vdGhlciBob3N0IHRoYW4g dGhlIERPVFMgY2xpZW50LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkRpZCBJIG1pc3Nl ZCBzb21ldGhpbmc/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmsgeW91LjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNoZWVycyw8YnIgY2xhc3M9IiI+DQpNZWQ8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4t LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnIgY2xhc3M9IiI+DQpEZSZuYnNwOzogRGF2ZSBE b2xzb24gWzxhIGhyZWY9Im1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSIgY2xhc3M9IiI+bWFp bHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPC9hPl0gRW52b3nDqSZuYnNwOzogamV1ZGkgMjY8YnIg Y2xhc3M9IiI+DQpvY3RvYnJlIDIwMTcgMTQ6NTAgw4AmbmJzcDs6IEJPVUNBREFJUiBNb2hhbWVk IElNVC9PTE47IEtvbmRhLCBUaXJ1bWFsZXN3YXI8YnIgY2xhc3M9IiI+DQpSZWRkeTsgRmxlbW1p bmcgQW5kcmVhc2VuOyBKb24gU2hhbGxvdzsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmci IGNsYXNzPSIiPmRvdHNAaWV0Zi5vcmc8L2E+IE9iamV0Jm5ic3A7OiBSZTo8YnIgY2xhc3M9IiI+ DQpbRG90c10gRE9UUyAmYW1wOyBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3 ICgtMDYpKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk15IHBvaW50IHdhcyB0aGF0IGlm IHNlcnZlciBzdGF0dXMgd2FzIHNvbGljaXRlZCwga2VlcC1hbGl2ZSBpbnRlcnZhbDxiciBjbGFz cz0iIj4NCndvdWxkIGJlIGluZGVwZW5kZW50IG9mIGZpcmV3YWxsL05BVCB0aW1lb3V0LiBLZWVw LWFsaXZlcyB3b3VsZCBiZTxiciBjbGFzcz0iIj4NCm9wdGlvbmFsLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NClNvbGljaXRlZCBtZWFucyB0aGF0IGNsaWVudCBzYXlzICZxdW90O2dldCBz dGF0dXMmcXVvdDsgdnMuIHRoZSBzZXJ2ZXIganVzdDxiciBjbGFzcz0iIj4NCnNlbmRpbmcgdXBk YXRlcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpEYXZpZCBEb2xzb248YnIgY2xhc3M9IiI+DQpTYW5kdmluZTxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwO09yaWdpbmFsIE1lc3NhZ2U8YnIgY2xhc3M9IiI+DQpGcm9tOiA8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgY2xhc3M9IiI+bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnIgY2xhc3M9IiI+DQpTZW50OiBUaHVyc2RheSwgT2N0 b2JlciAyNiwgMjAxNyAyOjExIFBNPGJyIGNsYXNzPSIiPg0KVG86IERhdmUgRG9sc29uOyBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5OyBGbGVtbWluZyBBbmRyZWFzZW47IEpvbjxiciBjbGFzcz0i Ij4NClNoYWxsb3c7IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIiBjbGFzcz0iIj5kb3Rz QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyAmYW1w OyBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3PGJyIGNsYXNzPSIiPg0KKC0w NikpPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSGkgRGF2ZSw8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgcHJvdG9jb2wgZG9lcyBhbHJlYWR5IHN1 cHBvcnQgYSBtZWNoYW5pc20gdG8gc2VuZCBrZWVwYWxpdmU8YnIgY2xhc3M9IiI+DQptZXNzYWdl cyBldmVyeSAzMHMgKHJlY29tbWVuZGVkIHZhbHVlKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpDaGVlcnMsPGJyIGNsYXNzPSIiPg0KTWVkPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+LS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tPGJyIGNsYXNzPSIiPg0KRGUgOiBEYXZlIERvbHNvbiBbPGEgaHJlZj0ibWFpbHRvOmRk b2xzb25Ac2FuZHZpbmUuY29tIiBjbGFzcz0iIj5tYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb208 L2E+XSBFbnZvecOpIDogamV1ZGkgMjY8YnIgY2xhc3M9IiI+DQpvY3RvYnJlIDIwMTcgMTM6MTUg w4AgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5OyBCT1VDQURBSVIgTW9oYW1lZDxiciBjbGFz cz0iIj4NCklNVC9PTE47IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7IDxhIGhyZWY9 Im1haWx0bzpkb3RzQGlldGYub3JnIiBjbGFzcz0iIj4NCmRvdHNAaWV0Zi5vcmc8L2E+IE9iamV0 IDogUkU6PGJyIGNsYXNzPSIiPg0KW0RvdHNdIERPVFMgJmFtcDsgTkFUICh3YXMgUkU6IERPVFMg UmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KSk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJ IHRoaW5rIHRoZXJlIGlzIGFub3RoZXIgb3B0aW9uIHRvIGhhbmRsZSB0aGUgTkFUL2ZpcmV3YWxs IHByb2JsZW1zPGJyIGNsYXNzPSIiPg0KYnkgY2hhbmdpbmcgdGhlIHByb3RvY29sLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIGN1cnJlbnRs eSB0aGUgTkFUIGFuZCBmaXJld2FsbCBuZWVkIHRvIGJlPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0Ka2VwdDxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pm9wZW4gdG8gcGVybWl0IHVuc29saWNpdGVkIHNlcnZlciBwYWNrZXRzLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCklmIHRoZSBwcm90b2NvbCBpcyBjaGFuZ2VkIHRvIHJlcXVpcmUgY2xp ZW50IHBvbGxpbmcgb2YgdGhlIHNlcnZlcjxiciBjbGFzcz0iIj4NCnVwZGF0ZXMsIHRoZSBOQVQg YW5kIGZpcmV3YWxsIHByb2JsZW1zIGdvIGF3YXkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KLURhdmU8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iIj4NCkZyb206IERvdHMgWzxhIGhyZWY9 Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgS29uZGEsPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KVGlydW1hbGVzd2FyPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+UmVkZHk8YnIgY2xhc3M9IiI+DQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAy NiwgMjAxNyAxMjo1OCBQTTxiciBjbGFzcz0iIj4NClRvOiA8YSBocmVmPSJtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgY2xhc3M9IiI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTwvYT47IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7PGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciIGNsYXNzPSIiPmRvdHNAaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTICZhbXA7IE5BVCAod2FzIFJF OiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXc8YnIgY2xhc3M9IiI+DQooLTA2KSk8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iIj4NCkZyb206IG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208YnIgY2xhc3M9IiI+DQpbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb21dPGJyIGNsYXNzPSIiPg0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjYsIDIwMTcg MjoyMSBQTTxiciBjbGFzcz0iIj4NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5PGJyIGNs YXNzPSIiPg0KJmx0O1RpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7OzxiciBj bGFzcz0iIj4NCkZsZW1taW5nIEFuZHJlYXNlbiAmbHQ7ZmFuZHJlYXNAY2lzY28uY29tJmd0Ozsg Sm9uIFNoYWxsb3cgJmx0O3N1cGpwcy08YnIgY2xhc3M9IiI+DQppZXRmQGpwc2hhbGxvdy5jb20m Z3Q7OyBkb3RzQGlldGYub3JnPGJyIGNsYXNzPSIiPg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RT ICZhbXA7IE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXc8YnIgY2xhc3M9IiI+ DQooLTA2KSk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSZS0sPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KSSBoZWFyIHlvdS4gTXkgdGFrZSBpcyB0aGF0IHdlIGRvbid0IG5lZWQg dG8gcmVjb21tZW5kIHdoaWNoPGJyIGNsYXNzPSIiPg0KY29tcGFuaW9uICZxdW90O3Byb3RvY29s cy9tZWNoYW5pc21zJnF1b3Q7IG5lZWQgdG8gYmUgc3VwcG9ydGVkIGZvciBOQVQvRlc8YnIgY2xh c3M9IiI+DQp0cmF2ZXJzYWwgcHVycG9zZXMuIEhhdmluZyBhIGRpc2N1c3Npb24gYXQgdGhlIHNh bWUgbGV2ZWwgaW4gODA4NTxiciBjbGFzcz0iIj4NCndvdWxkIGJlIHN1ZmZpY2llbnQsIElNSE8u PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTGV0J3MgZm9jdXMgb24gdGhlIHNpbXBsZSBi dWlsdC1pbiBmZWF0dXJlIGZvciBOQVQgZGV0ZWN0LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCkkgZG9uJ3QgdGhpbmsgdGhlIHNpbXBsZSBidWlsdC1pbiBmZWF0dXJlIGlzIHN1ZmZpY2ll bnQsIERPVFMgY2xpZW50PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0Kd2lsbDxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPmhhdmUgdG8gcmVseSBvbiBt ZWNoYW5pc21zIGRpc2N1c3NlZCBpbiA4MDg1IGZvciBib3RoIGZpcmV3YWxsIGFuZDxiciBjbGFz cz0iIj4NCk5BVCB0cmF2ZXJzYWwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLVRpcnU8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj5DaGVlcnMsPGJyIGNsYXNzPSIiPg0KTWVkPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+LS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tPGJyIGNsYXNzPSIiPg0KRGUgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5PGJyIGNs YXNzPSIiPg0KWzxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUu Y29tIiBjbGFzcz0iIj5tYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTwv YT5dPGJyIGNsYXNzPSIiPg0KRW52b3nDqSA6IGpldWRpIDI2IG9jdG9icmUgMjAxNyAxMDozNiDD gCA6IEJPVUNBREFJUiBNb2hhbWVkPGJyIGNsYXNzPSIiPg0KSU1UL09MTjsgRmxlbW1pbmcgQW5k cmVhc2VuOyBKb24gU2hhbGxvdzsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciIGNsYXNz PSIiPg0KZG90c0BpZXRmLm9yZzwvYT4gT2JqZXQgOjxiciBjbGFzcz0iIj4NClJFOiBbRG90c10g RE9UUyAmYW1wOyBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKTxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJ1dCBOQVRzIGFyZSBub3QgdGhlIG9ubHkgcHJv YmxlbSwgZmlyZXdhbGxzIHdpbGwgYWxzbyBiZSBtb3N0PGJyIGNsYXNzPSIiPg0KbGlrZWx5IHBy ZXNlbnQsIGFuZCBTVFVOIGhlbHBzIGRpc2NvdmVyIGJvdGggTkFUcyBhbmQgZmlyZXdhbGxzPGJy IGNsYXNzPSIiPg0KYW5kIHVzZWZ1bCBldmVuIGluIElQdjYgbmV0d29ya3MgdG8gZGV0ZXJtaW5l IHRoZSBrZWVwYWxpdmU8YnIgY2xhc3M9IiI+DQppbnRlcnZhbCBvZjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCmZpcmV3YWxsLjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+LVRpcnU8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iIj4N CkZyb206IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiBjbGFz cz0iIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxiciBjbGFzcz0iIj4NCls8YSBo cmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgY2xhc3M9IiI+bWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+XTxiciBjbGFzcz0iIj4NClNlbnQ6IFRo dXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDE6NTIgUE08YnIgY2xhc3M9IiI+DQpUbzogS29uZGEs IFRpcnVtYWxlc3dhciBSZWRkeTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCiZsdDs8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVl LmNvbSIgY2xhc3M9IiI+VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTwvYT4mZ3Q7 OzxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+RmxlbW1pbmcgQW5kcmVhc2VuICZsdDs8YSBocmVm PSJtYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tIiBjbGFzcz0iIj5mYW5kcmVhc0BjaXNjby5jb208 L2E+Jmd0OzsgSm9uIFNoYWxsb3cgJmx0O3N1cGpwcy08YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJt YWlsdG86aWV0ZkBqcHNoYWxsb3cuY29tIiBjbGFzcz0iIj5pZXRmQGpwc2hhbGxvdy5jb208L2E+ Jmd0OzsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciIGNsYXNzPSIiPg0KZG90c0BpZXRm Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgJmFtcDsgTkFU ICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzPGJyIGNsYXNzPSIiPg0KcmV2aWV3PGJyIGNsYXNz PSIiPg0KKC0wNikpPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGlydSw8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpZZXMsIFNUVU4gY2FuIGJlIGxpc3RlZCBhcyBwYXJ0IG9mIHRo ZSBleGlzdGluZyB0b29scyBib3g8YnIgY2xhc3M9IiI+DQooYW1vbmcgdGhlPGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KbGluZXMgb2Y8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj53aGF0IGlzIGFscmVhZHkgZGlzY3Vzc2VkIGluIDgwODUpLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBtYWtlcyBzZW5z ZSB0byByZXF1aXJlIFNUVU4gc3VwcG9ydCBieTxiciBjbGFzcz0iIj4NCkRPVFM8YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQpjbGllbnRzLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPlRoZSBwcm9wb3NhbCBpcyB0byBpbmNsdWRlIGEgc2ltcGxlIGJ1 aWx0LWluIGZlYXR1cmUgaW4gdGhlPGJyIGNsYXNzPSIiPg0KRE9UUzxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCnByb3RvY29sIGl0c2VsZjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPnRoYXQgY2FuIGhlbHAgdG8gZGV0ZWN0IE5BVHMuIFRoZSBzdXBw b3J0IG9mIHN1Y2ggZmVhdHVyZTxiciBjbGFzcz0iIj4NCndpbGwsIGUuZy4sPGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KZWFzZTxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPnRyb3VibGVzaG9vdGluZyB3aGVuIGNvbm5lY3Rpdml0eSBwcm9ibGVtcyBh cmUgZXhwZXJpZW5jZWQgb248YnIgY2xhc3M9IiI+DQp0aGUgcGF0aCBiZXR3ZWVuIGEgY2xpZW50 IGFuZCBhIHNlcnZlci48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpDaGVlcnMsPGJyIGNs YXNzPSIiPg0KTWVkPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJyIGNsYXNzPSIi Pg0KRGUgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5PGJyIGNsYXNzPSIiPg0KWzxhIGhyZWY9 Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIiBjbGFzcz0iIj5tYWls dG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTwvYT5dPGJyIGNsYXNzPSIiPg0K RW52b3nDqSA6IGpldWRpIDI2IG9jdG9icmUgMjAxNyAwOTo0NCDDgCA6IEJPVUNBREFJUiBNb2hh bWVkPGJyIGNsYXNzPSIiPg0KSU1UL09MTjsgRmxlbW1pbmcgQW5kcmVhc2VuOyBKb24gU2hhbGxv dzsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciIGNsYXNzPSIiPg0KZG90c0BpZXRmLm9y ZzwvYT4gT2JqZXQgOjxiciBjbGFzcz0iIj4NClJFOiBbRG90c10gRE9UUyAmYW1wOyBOQVQgKHdh cyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3PGJyIGNsYXNzPSIiPg0KKC0wNikpPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnIgY2xhc3M9IiI+DQpGcm9tOiBEb3RzIFs8YSBo cmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIGNsYXNzPSIiPm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyIGNsYXNzPSIiPg0KU2VudDogVHVlc2RheSwgT2N0b2Jl ciAyNCwgMjAxNyAyOjIwIFBNPGJyIGNsYXNzPSIiPg0KVG86IEZsZW1taW5nIEFuZHJlYXNlbiAm bHQ7ZmFuZHJlYXNAY2lzY28uY29tJmd0OzsgSm9uIFNoYWxsb3c8YnIgY2xhc3M9IiI+DQombHQ7 c3VwanBzLSBpZXRmQGpwc2hhbGxvdy5jb20mZ3Q7OyBkb3RzQGlldGYub3JnPGJyIGNsYXNzPSIi Pg0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTICZhbXA7IE5BVCAod2FzIFJFOiBET1RTIFJlcXVp cmVtZW50czxiciBjbGFzcz0iIj4NCnJldmlldzxiciBjbGFzcz0iIj4NCigtMDYpKTxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkhpIEZsZW1taW5nLCBhbGwsPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KUGxlYXNlIHNlZSBpbmxpbmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KQ2hlZXJzLDxiciBjbGFzcz0iIj4NCk1lZDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLSBEZSA6IEZsZW1taW5nIEFuZHJlYXNlbjxiciBjbGFzcz0iIj4NClttYWlsdG86ZmFuZHJl YXNAY2lzY28uY29tXSBFbnZvecOpIDo8YnIgY2xhc3M9IiI+DQpsdW5kaTxiciBjbGFzcz0iIj4N CjIzIG9jdG9icmUgMjAxNyAxNzozNiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEpv bjxiciBjbGFzcz0iIj4NClNoYWxsb3c7IGRvdHNAaWV0Zi5vcmcgT2JqZXQgOiBSZTogRE9UUyAm YW1wOyBOQVQgKHdhcyBSRTo8YnIgY2xhc3M9IiI+DQpbRG90c10gRE9UUyBSZXF1aXJlbWVudHMg cmV2aWV3ICgtMDYpKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCk9uIDEwLzIzLzE3IDg6MjggQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+SGkgSm9uLCBhbGwsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhZ3JlZSB3 aXRoIEZsZW1taW5nIHRoYXQgJnF1b3Q7c29tZSBtb3JlIHdvcmsmcXVvdDsgaXMgbmVlZGVkLjxi ciBjbGFzcz0iIj4NCklNSE8sIHRoaXMgaXMgYTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N CnR5cGljYWwgZGlzY3Vzc2lvbiB0byBpbmNsdWRlIGluIGEgZGVkaWNhdGVkIHNlY3Rpb24gaW48 YnIgY2xhc3M9IiI+DQp0aGUgRE9UUyBhcmNoaXRlY3R1cmUgSS1ELjxiciBjbGFzcz0iIj4NCkFn cmVlZC48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4mZ3Q7 RnJvbSBhIHJlcXVpcmVtZW50IHN0YW5kcG9pbnQsIHdlIGRvbid0IG5lZWQgdG8NCjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPmVsYWJvcmF0ZSBob3cgdGhl PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KcHJvdG9jb2xzIHdp bGwgZnVsZmlsIGl0LiBTSUctMTAgZG9lcyBldmVuIGEgbmljZSBqb2IgYnk8YnIgY2xhc3M9IiI+ DQpjaXRpbmc8YnIgY2xhc3M9IiI+DQpSRkM4MDg1IHdoaWNoIHBvaW50cyB0byBOQVQgdHJhdmVy c2FsIG1lY2hhbmlzbXMuIE9uZTxiciBjbGFzcz0iIj4NCmNvdWxkIHBpY2sgaGlzL2hlciBmYXZv cml0ZSBwcm90b2NvbCBmcm9tIHRoZSBsaXN0IGluPGJyIGNsYXNzPSIiPg0KODA4NSB0byBkaXNj b3ZlciB0aGUgZXh0ZXJuYWwgSVAgYWRkcmVzcy9wcmVmaXgsIGlmPGJyIGNsYXNzPSIiPg0KbmVl ZGVkLiBFeHRlcm5hbCBJUCBhZGRyZXNzZXMvcHJlZml4ZXMgY2FuIGJlIElQdjQgZm9yIGE8YnIg Y2xhc3M9IiI+DQpOQVQ0NCBvciBOQVQ2NCwgYnV0IGNhbiBiZTxiciBjbGFzcz0iIj4NCklQdjYg cHJlZml4ZXMgZm9yIGVudGVycHJpc2VzIGRlcGxveWluZyBOUFR2NiwgYW5kIHNvIG9uLjxiciBj bGFzcz0iIj4NClBhcnQgb2YgdGhlIGNoYWxsZW5nZSBoZXJlIGlzIHRoYXQgdGhlIGF0dGFjayB0 YXJnZXQgYW5kPGJyIGNsYXNzPSIiPg0KdGhlIERPVFMgY2xpZW50IGFyZSBub3QgbmVjZXNzYXJp bHkgb25lIGFuZCB0aGUgc2FtZSw8YnIgY2xhc3M9IiI+DQp3aGljaCBtYWtlcyBpdCBtb3JlIGRp ZmZpY3VsdCB0byBkZXRlcm1pbmUgdGhlPGJyIGNsYXNzPSIiPg0KcHVibGljLWZhY2luZyBJUC1h ZGRyZXNzL3BvcnQgdW5kZXIgYXR0YWNrIChhdCBsZWFzdCBpZjxiciBjbGFzcz0iIj4NCnRoZSBE T1RTIGNsaWVudCBpcyBnb2luZyB0bzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCmRv IGl0KS48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5bTWVkXSBUaGlzIGlz IGV4YWN0bHkgdGhlIGtpbmQgb2YgdGhlIGRpc2N1c3Npb24gdG8gaGF2ZS48YnIgY2xhc3M9IiI+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQpUaGFua3MuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5XaXRoIG9yIHdpdGhv dXQgTkFULCBET1RTIGNsaWVudHMgYXJlIGFzc3VtZWQgdG8gYmUgZmVkPGJyIGNsYXNzPSIiPg0K d2l0aCB0aGU8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQppbnRlcm5hbDxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPnRhcmdldChzKS4gVGhpcyBjYW4g YmUgYWNoaWV2ZWQgYnkgcHJvdmlzaW9uaW5nIChsaWtlbHkpPGJyIGNsYXNzPSIiPg0Kb3IgYnkg ZGlzY292ZXJ5PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KbWVhbnM8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4oZS5nLiwgcmVzaWRlbnRpYWwgb3Ig c21hbGwgZW50ZXJwcmlzZSBuZXR3b3JrcykuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K Q2FuIHdlIGFzc3VtZSB0aGF0IHRoZSBkaXNjb3Zlcnkgb2YgdGhlIGV4dGVybmFsIElQPGJyIGNs YXNzPSIiPg0KYWRkcmVzcy9wcmVmaXgvLi4gaXM8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQpkb25lPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Ynkg YSBET1RTIGNsaWVudCBvbmx5IGlmIGl0IGlzIGV4cGxpY2l0bHkgaW5zdHJ1Y3RlZCB0byBkbyBz bz88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi PkluIHNvbWUgZGVwbG95bWVudHMsIERPVFMgY2xpZW50cyBtYXkgYmUgcHJvdmlzaW9uZWQ8YnIg Y2xhc3M9IiI+DQp3aXRoIHRoZSBzZXQgb2Y8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpp bnRlcm5hbCByZXNvdXJjZXMsIHNvIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGRpc2NvdmVyeS48YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5BbHNvLCBhcyBKb24g bWVudGlvbmVkLCBET1RTIGdhdGV3YXlzIGNhbiBiZSBvZiBoZWxwPGJyIGNsYXNzPSIiPg0KdG8g c2V0IHRoZTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCmFwcHJvcHJpYXRlIElQIGFkZHJl c3Nlcy9wcmVmaXhlcy9wb3J0IG51bWJlcnMgaW4gdGhlPGJyIGNsYXNzPSIiPg0KcHJlc2VuY2Ug b2YgdHJhbnNsYXRvcnMuPGJyIGNsYXNzPSIiPg0KQWdyZWVkIC0gYnV0IHRoZXkgc3RpbGwgbmVl ZCBhIHdheSB0byBmaWd1cmUgb3V0IHRoZTxiciBjbGFzcz0iIj4NCnByaXZhdGUvcHVibGljIG1h cHBpbmcgZm9yIGEgZ2l2ZW4gYXR0YWNrIHRhcmdldC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQpbTWVkXSBCZWNhdXNlIGEgRERvUyBhdHRhY2sgaXMgb2JzZXJ2ZWQgZnJvbSB0aGUgaW50 ZXJuYWw8YnIgY2xhc3M9IiI+DQpuZXR3b3JrLDxiciBjbGFzcz0iIj4NCm1hcHBpbmcocykgYXJl IG5lY2Vzc2FyaWx5IG1haW50YWluZWQgYnkgdGhlIG9uLXBhdGg8YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQp0cmFuc2xhdG9yKHMpLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T3RoZXJ3aXNlLCB0 aGUgaW5jb21pbmcgYXR0YWNrIHRyYWZmaWMgY291bGRuJ3QgYmU8YnIgY2xhc3M9IiI+DQpmb3J3 YXJkZWQgdG8gaW50ZXJuYWw8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpob3N0cy48YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5UaGlzIG1vZGVsIGFz c3VtZXMgdGhhdCB0aGUgZ2F0ZXdheSBpcyBjb2xsb2NhdGVkIHdpdGggdGhlPGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KTkFULjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5TbywgdGhlIGdhdGV3YXkgY2FuIHJl cGxhY2UgdGhlIGludGVybmFsIElQIGFkZHJlc3MvcHJlZml4PGJyIGNsYXNzPSIiPg0Kd2l0aCB0 aGUgb25lPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KcmV0cmlldmVzPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ZnJvbSB0aGUgTkFUIG1hcHBpbmcg dGFibGUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRG8geW91IHNlZSBhbnkgaXNzdWUg d2l0aCB0aGlzIHNjaGVtZT88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi PkFuIG9wZW4gcXVlc3Rpb24gdGhvdWdoIHdvdWxkIGJlIHRvIGRpc2N1c3MgaWYgdGhlcmU8YnIg Y2xhc3M9IiI+DQppcyBhIHZhbHVlIGluPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KaGF2 aW5nIGEgZmVhdHVyZSBpbiB0aGUgRE9UUyBwcm90b2NvbCB0byBpbmZvcm0gYSBET1RTPGJyIGNs YXNzPSIiPg0KY2xpZW50IHRoYXQgYSBOQVQgaXMgZGV0ZWN0ZWQgb24tcGF0aC4gVGhpcyBjYW4g YmU8YnIgY2xhc3M9IiI+DQpwcmVzZW50ZWQgYXMgYW4gaW5mb3JtYXRpb24gZWxlbWVudCByZXR1 cm5lZCBieSB0aGU8YnIgY2xhc3M9IiI+DQpzZXJ2ZXIgdG8gdGhlIGNsaWVudC4gVGhpcyBpbmZv cm1hdGlvbiBjYW4gYmUsIGZvcjxiciBjbGFzcz0iIj4NCmV4YW1wbGUsIHVzZWQgYnkgdGhlIGNs aWVudCB0byBhZGp1c3QgaXRzIEhUIGludGVydmFsLDxiciBjbGFzcz0iIj4NCmFkanVzdCB0aGUg aW50ZXJuYWwgSVAgYWRkcmVzc2VzL3ByZWZpeGVzIHRvIGJlPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KcHJvdGVjdGVkLCBldGMuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+T3BpbmlvbnM/PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+SXQgc291bmRzIGFwcGVhbGluZywgYnV0IGl0J3MgdmVyeSBkaWZmaWN1bHQgdG8g ZG8gdGhpczxiciBjbGFzcz0iIj4NCnJlbGlhYmx5LCBhbmQgaXQncyBub3QganVzdCBOQVRzIHRo YXQgYXJlIGFuIGlzc3VlIGhlcmU7PGJyIGNsYXNzPSIiPg0KRmlyZXdhbGxzIHByZXNlbnQgc2lt aWxhciBjaGFsbGVuZ2VzIChhbmQgdGhleSBtYXkgb3I8YnIgY2xhc3M9IiI+DQptYXkgbm90IGJl IE5BVCdpbmcgaW5kaXZpZHVhbDxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCmZsb3dzKS48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPltN ZWRdIEkgZnVsbHkgYWdyZWUgdGhhdCBmaXJld2FsbHMgZGV0ZWN0IGlzIG1vcmUgY29tcGxleC48 YnIgY2xhc3M9IiI+DQpMZXQncyBwdXQgaXQ8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQph c2lkZTxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPmFuZCBm b2N1cyBvbiB0aGUgTkFUIGNhc2UuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KVGhlIHBy ZXNlbmNlIGFuZCBiZWhhdmlvciBvZiBOQVQgYW5kIEZpcmV3YWxsLCBhbmQga2VlcGFsaXZlPGJy IGNsYXNzPSIiPg0KaW50ZXJ2YWwgY2FuIGJlIGRldGVybWluZWQgdXNpbmcgU1RVTiAoZGlzY3Vz c2VkIGluPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzU3ODAiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzgwPC9h PikuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLVRpcnU8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5XZSBjYW4gY29uc2lk ZXIgbWFueSBhcHByb2FjaGVzIHRvIGRldGVjdCBhIE5BVCwgZS5nLiw8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQooMSkgVGhlIERPVFMgY2xpZW50IGluc2VydHMgaW4gdGhlIGNvcmUgbWVz c2FnZSB0aGUgSVA8YnIgY2xhc3M9IiI+DQphZGRyZXNzL3BvcnQgaXQ8YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQp1c2VzIHRvPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+c2VuZCB0aGUgcmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuIFVwb24gcmVj ZWlwdCBvZiB0aGU8YnIgY2xhc3M9IiI+DQpyZXF1ZXN0IGJ5IHRoZSBET1RTIHNlcnZlciwgaXQg Y2hlY2tzIGlmIHRoZSBlbmNsb3NlZCBJUDxiciBjbGFzcz0iIj4NCmFkZHJlc3MvcG9ydCBtYXRj aCB0aGUgc291cmNlPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KSVA8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5hZGRyZXNzL3BvcnQgb2YgdGhlIHJl Y2VpdmVkIHBhY2tldC4gSWYgeWVzLCB0aGUgc2VydmVyPGJyIGNsYXNzPSIiPg0Kc2V0cyBpbiB0 aGU8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpyZXNwb25zZSBhPGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ZGVkaWNhdGVkIHBhcmFtZXRlciB0byBp bmRpY2F0ZSB0aGF0IGEgdHJhbnNsYXRvciBpczxiciBjbGFzcz0iIj4NCmRldGVjdGVkPGJyIGNs YXNzPSIiPg0Kb24tPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KcGF0aC48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+KDIpIFRoZSBET1RTIHNlcnZlciBpbnNlcnRzIHN5c3Rl bWF0aWNhbGx5IHRoZSBzb3VyY2UgSVA8YnIgY2xhc3M9IiI+DQphZGRyZXNzL3BvcnQgaW48YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQphPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+cmVzcG9uc2UgdG8gYSBtZXNzYWdlIGZyb20gYSBET1RTIGNsaWVu dC4gVXBvbiByZWNlaXB0IG9mPGJyIGNsYXNzPSIiPg0KdGhhdCByZXNwb25zZSwgdGhlIERPVFMg Y2xpZW50IGNvbXBhcmVzIHRoZSBlbmNsb3NlZDxiciBjbGFzcz0iIj4NCmFkZHJlc3MvcG9ydCB3 aXRoIHRoZSBvbmVzIGl0IHVzZWQ8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQp0bzxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPnNlbmQgdGhlIHJlcXVl c3QgdG8gZGV0ZWN0IGFueSBtaXNtYXRjaC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4tLSBGbGVtbWlu ZzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPkNoZWVycyw8YnIgY2xhc3M9IiI+DQpNZWQ8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4tLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0gRGUgOiBEb3RzPGJyIGNsYXNzPSIiPg0KWzxhIGhyZWY9 Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBEZSBsYSBwYXJ0IGRlIEpvbjxiciBjbGFzcz0iIj4NClNoYWxsb3cg RW52b3nDqSA6IGx1bmRpIDIzIG9jdG9icmUgMjAxNyAxMzoxOCDDgCA6PGJyIGNsYXNzPSIiPg0K J0ZsZW1taW5nIEFuZHJlYXNlbic7IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIiBjbGFz cz0iIj5kb3RzQGlldGYub3JnPC9hPiBPYmpldCA6IFJlOjxiciBjbGFzcz0iIj4NCltEb3RzXSBE T1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNik8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpIaSBGbGVtbWluZyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgd2F5IG15IG1p bmQgd29ya3MgaXMgdG8gdGhpbmsgb2YgYSBwcmFjdGljYWw8YnIgY2xhc3M9IiI+DQpzaXR1YXRp b24gYW5kIHNlZSBpZiB0aGluZ3MgZml0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFz IEkgcmVhZCBTSUctMDEwLCB0aGVyZSBjb3VsZCBiZSBhIERPVFMgY2xpZW50IHdpdGg8YnIgY2xh c3M9IiI+DQphIG1hbmFnZW1lbnQgSVAgYWRkcmVzcyB0aGF0IGlzIFJGQzE5MTggLSB0aGlzIGNs aWVudDxiciBjbGFzcz0iIj4NCmNvdWxkIGJlIG1vbml0b3JpbmcgTmV0ZmxvdyBpbmZvcm1hdGlv biBhbmQgY2FuPGJyIGNsYXNzPSIiPg0KcmVxdWVzdCBtaXRpZ2F0aW9uIGZvciB0aGUgYXBwcm9w cmlhdGUgcHVibGljIElQczxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCnRoYXQ8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPmFyZSBiZWluZyBtb25pdG9yZWQuICZu YnNwO1NvIFNJRy0wMTAgaXMgbmVlZGVkIGZvciB0aGlzPGJyIGNsYXNzPSIiPg0KdXNlPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KY2FzZS48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkl0IGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0 aGUgRE9UUyBzZXJ2ZXIgYXMgdG88YnIgY2xhc3M9IiI+DQp3aGV0aGVyIGl0IGFjY2VwdHMgYSBt aXRpZ2F0aW9uIHJlcXVlc3QgZm9yIGE8YnIgY2xhc3M9IiI+DQpwYXJ0aWN1bGFyIHRhcmdldCBp cCAob3IgZG9tYWluPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KZXRjLikgb3I8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5ub3QuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPklmIHRoZXJlIGlzIGdvaW5nIHRv IGJlIGEgTkFUIGJvcmRlciB3aGVyZSBwdWJsaWMgSVBzPGJyIGNsYXNzPSIiPg0KYXJlIG1hcHBl ZCBpbnRvIHByaXZhdGUgSVBzIChhbmQgdmljZSB2ZXJzYSksIEkgd291bGQ8YnIgY2xhc3M9IiI+ DQp0aGVuIGV4cGVjdCB0aGVyZSB0byBiZSBhIERPVFMgZ2F0ZXdheSBiZXR3ZWVuIHRoZXNlPGJy IGNsYXNzPSIiPg0KMiB6b25lcywgYW5kIGl0IGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUg RE9UUzxiciBjbGFzcz0iIj4NCmdhdGV3YXkgdG8gZG8gYW55IHRhcmdldC1pcDxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCm1hcHBpbmdzLjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5SZWdhcmRzPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KSm9uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnIgY2xhc3M9IiI+DQpGcm9tOiBEb3RzIFs8YSBocmVm PSJtYWlsdG86aWV0Zi1zdXBqcHMtZG90cy1ib3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5tYWls dG86aWV0Zi1zdXBqcHMtZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl08YnIgY2xhc3M9IiI+DQpP biBCZWhhbGYgT2YgRmxlbW1pbmcgQW5kcmVhc2VuPGJyIGNsYXNzPSIiPg0KU2VudDogMjIgT2N0 b2JlciAyMDE3IDIwOjE3PGJyIGNsYXNzPSIiPg0KVG86IGRvdHM7IDxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnIiBjbGFzcz0iIj5kcmFmdC1pZXRm LWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NClN1YmplY3Q6IFtE b3RzXSBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNik8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpHcmVldGluZ3M8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGhhdmUgcmV2 aWV3ZWQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBET1RTPGJyIGNsYXNzPSIiPg0KcmVxdWly ZW1lbnRzIGRyYWZ0PGJyIGNsYXNzPSIiPg0KKDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMiIGNsYXNzPSIiPmh0dHBzOi8vd3d3Lmll dGYub3JnL2lkL2RyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHM8L2E+PGJyIGNsYXNzPSIiPg0K LTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjA2LnR4dCkuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5JbjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCmdlbmVyYWwsPGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj5JIHRoaW5rIHRoZSBkcmFmdCBpcyBpbiBnb29kIHNoYXBlIHdpdGggb25seSBhIGZldzxi ciBjbGFzcz0iIj4NCmVkaXRzIHJlcXVpcmVkLCBzbyBJIGhvcGUgd2UgY2FuIG1vdmUgdG8gV0dM QyBzb29uLiBJPGJyIGNsYXNzPSIiPg0KaGF2ZSBhIGZldyBjb21tZW50cyBiZWxvdyAob2Ygd2hp Y2g8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQp0aGU8YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPk5BVCBvbmUgaXMgdGhlIG9ubHkgcmVhbCBzdWJzdGFudGlhbCBv bmUpLiBJIGhhdmU8YnIgY2xhc3M9IiI+DQphbHNvIHN1Ym1pdHRlZCBhIHB1bGwgcmVxdWVzdCB3 aXRoIGEgZmV3IG5pdCBmaXhlcyBvbiBHaXRIdWI6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KU2VjdGlvbiAxLjI8YnIgY2xhc3M9IiI+DQotIFRoZSBkZWZpbml0 aW9uIG9mICZxdW90O0RPVFMgU2lnbmFsJnF1b3Q7IGlzIHNsaWdodGx5PGJyIGNsYXNzPSIiPg0K aW5jb25zaXN0ZW50IHdpdGggdGhlIHJlc3BlY3RpdmUgJnF1b3Q7Q2xpZW50IFNpZ25hbCZxdW90 OyBhbmQ8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQomcXVvdDtTZXJ2ZXIgU2lnbmFsJnF1b3Q7IGRlZmlu aXRpb25zLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+U0lHLTAwNTo8YnIgY2xhc3M9IiI+DQotIE5vdCBjbGVhciB0aGF0IGFs d2F5cyByZXF1aXJpbmcgJnF1b3Q7bnVtYmVyIG9mIHBhY2tldHMmcXVvdDs8YnIgY2xhc3M9IiI+ DQptZXRyaWNzIGlzIG1lYW5pbmdmdWwuIENvbnNpZGVyIFRDUC1iYXNlZCBhdHRhY2tzIGZvcjxi ciBjbGFzcz0iIj4NCmV4YW1wbGUuIE51bWJlciBvZiBieXRlcyBtYXkgYWx3YXlzIGJlIG9rIC0g YWJvdmUgYW5kPGJyIGNsYXNzPSIiPg0KYmV5b25kIHRoYXQgaXQgc2hvdWxkIHByb2JhYmx5IGJl IGV4dGVuc2libGUgYW5kL29yPGJyIGNsYXNzPSIiPg0KYXR0YWNrPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KZGVwZW5kZW50Ljxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPi0gSSBkb24ndCB0aGluayB0aGUgcmVxdWlyZW1l bnRzIGRvY3VtZW50IHNob3VsZCBnZXQ8YnIgY2xhc3M9IiI+DQppbnRvIHNwZWNpZnlpbmc8YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQp0aW1lcjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+dmFsdWVzIC0gZXhwb250aWFsIGJhY2tvZmYgd2l0aCBzb21lIG1heGlt dW0gdmFsdWU8YnIgY2xhc3M9IiI+DQpzZWVtcyBhYm91dCB0aGU8YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQpyaWdodDxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ bGV2ZWwgb2YgZGV0YWlsIGhlcmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU0lHLTAw OTo8YnIgY2xhc3M9IiI+DQotIFRvIGJlIGNsZWFyLCB0aGUgY29uZmxpY3RzIG9ubHkgYXBwbHkg d2l0aGluIGE8YnIgY2xhc3M9IiI+DQpzaW5nbGUgYWRtaW5pc3RyYXRpdmUgZG9tYWluLCByaWdo dCA/IEZvciBleGFtcGxlLCBpZjxiciBjbGFzcz0iIj4NCmEgY2xpZW50IHRlbGxzIHRoZSBzYW1l IGRvbWFpbiB0byBhbHRlcm5hdGVseSB0dXJuPGJyIGNsYXNzPSIiPg0Kb24vb2ZmIG1pdGlnYXRp b24gZm9yIGEgZ2l2ZW4gcHJlZml4LCByb3V0ZSBmbGFwcGluZzxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCm1heTxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+b2Nj dXIuIFRoZSBzYW1lIGNvbmNlcm4gZG9lcyBub3QgYXBwbHkgaWYgYSBjbGllbnQ8YnIgY2xhc3M9 IiI+DQp0ZWxscyB0d28gZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlIGRvbWFpbnMgdG88YnIgY2xh c3M9IiI+DQpyZXNwZWN0aXZlIHR1cm4gbWl0aWdhdGlvbiBvbiAoZG9tYWluIDEpIGFuZDxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCm9mZjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+KGRvbWFpbiAyKS4gSWYgc28sIGNhbiB3ZSBjbGFyaWZ5IHRoYXQgKGFsc28g aW4gbGlldTxiciBjbGFzcz0iIj4NCm9mIHNvbWUgb2YgdGhlPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KbXVsdGktPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5o b21pbmcgY29tbWVudHMgcmFpc2VkIHByZXZpb3VzbHkpID88YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpTSUctMDEwOjxiciBjbGFzcz0iIj4NCi0gRE9UUyBDbGllbnQgYmVoaW5kIE5BVC4g T24gb25lIGhhbmQsIGl0IHNlZW1zPGJyIGNsYXNzPSIiPg0KcmVhc29uYWJsZSB0byBoYXZlIHRo aXMgcmVxdWlyZW1lbnQgc2luY2UgY2xpZW50cyBmb3I8YnIgY2xhc3M9IiI+DQpzdXJlIGNhbiBi ZSBiZWhpbmQgTkFUcywgYW5kPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0Kd2l0aDxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPnRoaW5nczxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5saWtlIGR5bmFtaWMgRE5T LCB0aGV5IGNhbiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjZXJ0YWlubHkgYmUgcmVhY2hhYmxl LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCkhvd2V2ZXIsPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5p ZjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+d2U8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPmRv PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj53YW50IHRvIGFsbG93IGZvciB0aGlzIHNjZW5hcmlv LCBhbmQgaW4gcGFydGljdWxhcjxiciBjbGFzcz0iIj4NCmZvciB0aGUgRE9UUyBjbGllbnQ8YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQp0bzxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+aGF2ZSBhIHByaXZhdGUgSVAtYWRkcmVzcyAocG90ZW50aWFsbHkgYmVoaW5k PGJyIGNsYXNzPSIiPg0KbXVsdGlwbGUgTkFUcyksIHRoZW4gd2U8YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQpoYXZlPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5t b3JlIHdvcmsgdG8gZG8gYmVjYXVzZSBpdCB3b24ndCBkbyB0aGUgRE9UUyBzZXJ2ZXI8YnIgY2xh c3M9IiI+DQphbnkgZ29vZCB0byBnZXQgYSBtaXRpZ2F0aW9uIHJlcXVlc3QgcmVmZXJyaW5nIHRv PGJyIGNsYXNzPSIiPg0KdGhhdCBwcml2YXRlIElQLWFkZHJlc3MgKG9yPGJyIGNsYXNzPSIiPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KcHJlZml4KS48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQpUaGFua3M8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLSBGbGVtbWluZzxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KRG90cyBtYWlsaW5nIGxpc3Q8YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyIgY2xhc3M9IiI+RG90c0BpZXRm Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RvdHM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCkRvdHMgbWFpbGluZyBs aXN0PGJyIGNsYXNzPSIiPg0KRG90c0BpZXRmLm9yZzxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90czxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi ciBjbGFzcz0iIj4NCkRvdHMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFp bHRvOkRvdHNAaWV0Zi5vcmciIGNsYXNzPSIiPkRvdHNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzPGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnIgY2xhc3M9IiI+DQpEb3RzIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4N CjxhIGhyZWY9Im1haWx0bzpEb3RzQGlldGYub3JnIiBjbGFzcz0iIj5Eb3RzQGlldGYub3JnPC9h PjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90 czxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCi48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCkRv dHMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5v cmciIGNsYXNzPSIiPkRvdHNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_6EDF1F8DAA034275951ECD98047E7C03arbornet_-- From nobody Thu Oct 26 10:13:24 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8AA139059 for ; Thu, 26 Oct 2017 10:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=verisign.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 f_I2od-JUYcF for ; Thu, 26 Oct 2017 10:13:17 -0700 (PDT) Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B6613F5CF for ; Thu, 26 Oct 2017 10:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=78834; q=dns/txt; s=VRSN; t=1509037998; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=O3BqmtkC5+x3YzfsIMwR/EhuwlEVpZ3qfBXFTK/sVqc=; b=gNgIglU1bQJGBcv0Dx4N3qP6W0NsRbpobDuA88YLkxrPQrFWR6V4PRA7 d97TFmAoN9JKdHIsELUzL6Af4NKdUVIMZIhVtAo8zkvGT29tBw7JPz7IQ /1a5pWNwOnXj9yQU/pZe6awLxGyn+2NAgQkW5rE9cO8rtm7Wupzece8lL GQqDwDkaRD+leBXWpHw4B+CW8KXTF3vL70Nq7ohva8Rm6aa4E8q39fMNk jmQwotyb78MDjf4YV+h9jvSuGLwvpkP/0+PvjwLTPeHyaFdQL490LrcfE 5GlHKcb3NXauxVb68z/fJ0NDAIlDc9f3/Fa4cHs4zk+GyImD3Bmtuqfqg g==; X-IronPort-AV: E=Sophos;i="5.44,301,1505779200"; d="scan'208,217";a="2977441" IronPort-PHdr: =?us-ascii?q?9a23=3AB/4yzRCrStlXHc4M/8ZDUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP35oMWwAkXT6L1XgUPTWs2DsrQf2rqQ6/iocFdDyK7JiGoFfp1IWk1Nou?= =?us-ascii?q?QttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZr?= =?us-ascii?q?KeTpAI7SiNm82/yv95HJbQhFgDmwbaluIBmqsA7cqtQYjYx+J6gr1xDHuGFIe+?= =?us-ascii?q?NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S6dYDCk9PGAu+MLrrxjD?= =?us-ascii?q?QhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VC+85Kl3VhDnlC?= =?us-ascii?q?YHNyY48G7JjMxwkLlbqw+lqxBm3oLYfJ2ZOP94c6jAf90VWHBBU95RWSJfH428?= =?us-ascii?q?c4UBAekPPelaronyu1QBoACkCgWwAO7i0CNEimP00KA8zu8vERvG3AslH98Wvn?= =?us-ascii?q?jassv6O70dUeCo0qbE1SjIYetX2Tf+5oTDbxcsofeQXb1ua8XRxlQvGB3eg1WO?= =?us-ascii?q?t4PlJTKV1v8Ms2iU6epsT/6gi2kiqwxopDWk28kiio7Mho0Py1DE8z10wIk0Jd?= =?us-ascii?q?2kSE57fMWrHIFMuCGdMot7RN4pTWJwuCsi17EKpYS3cDUIxZkp3RLTdvyKfoaS?= =?us-ascii?q?7h79W+ucLi90iG95dL6lmhq/81SsxvfhWsS701tGtDdJn9rKu3sQzRLc8NKHRe?= =?us-ascii?q?F4/kq53DaP0B3c5f9cLEAvkKrbN4YhwrktlpoPqUjDHjH5mEHxjKKObUok4O6o?= =?us-ascii?q?5/njYrTpo5+TLY50igX5MqQzhsyzHfk0PhIQX2eF4+S81abj/Uz2QLVMlPE5jq?= =?us-ascii?q?7ZsJXCKcQaoK62HRNV354+5xqjFTuqzdYVkHcdIF5YeB+KgZLlN0/BLf33Ffu/?= =?us-ascii?q?hk6jkDZvx/DIJL3hBZDNI2DFkLf9Y7ly8UFcyBctwt1E+ZJbFKsBIPPoWk/wu9?= =?us-ascii?q?zYCAU1PBCzw+biENl9zJ8RWXqTAq+FN6PfqUKH6f8oI+mIf48VvzD9JuM+5/H0?= =?us-ascii?q?i382hEEdfaiv3ZQJcny3AvNmI0CBa3r2ntgBCXsKvhY5TOHylVKCViJTZ22pUq?= =?us-ascii?q?I9+D47FIymAZ3ERoC3j7yLxD27EYFOZmBaFlCMFm/ld4CDW/cMci2SJ9FunSEe?= =?us-ascii?q?Wbe6TI8hyA2huxXnxLV9L+rU4DYVtZX51Ndv4e3Tmg89+SZoAMSa1mGHV3t0kX?= =?us-ascii?q?8QRz8qwKB/plRwxEmC0ahinvxYEMZc5/dXXQchO5/T1fZ6BczsVQ3cY9iISE6p?= =?us-ascii?q?TNChATE3U90+2cQDY0NhFNq4gBDMwTSlD6UJmLyMAZw+6rjc0GTpJ8Zh13bG07?= =?us-ascii?q?Esj0I7QstXN22mnrV/+xHSB4HXj0WZmb2ndaYE3C7W9GeM126OvEVfUA9+S6nK?= =?us-ascii?q?QXcfZk7Op9Tj+kzCV6OuCaggMgZZx86NMK1KZcDzjVpYXvjjI8/TbH6wm2erGR?= =?us-ascii?q?mIwamAY5bte2UYxC/dElQLkxgP/XaaMggzHj2uo2fZDDx0CVLgfUXs8fJgp3O9?= =?us-ascii?q?VUI71RuKYFZm17qv4BIVg+KTS+9Alo4D7W0ErC9oEVCm0tSSQ/OGqxBsY+8UNd?= =?us-ascii?q?o4501b2GTCugpVN4aqKLokgFMCJUA/kUfj0hB2DIoIuM4mtn4j1wd0YfaW2VVN?= =?us-ascii?q?bT6Rxrj7O6bcLS/5+xX5OIDM3VSLmuqb86gS5bBwjVTg9kn9EFYv+np63vFL3m?= =?us-ascii?q?Gd/ZTFCkwZVpenARV/zARzu7yPOnp13IjTz3A5dPDs6jI=3D?= X-IPAS-Result: =?us-ascii?q?A2FwAAAiF/JZ//SZrQpcGQEBAQEBAQEBAQEBBwEBAQEBFAE?= =?us-ascii?q?BAQEBAQEBAQEBBwEBAQEBgkRCgRKBFQeDc4ofkQt8jSsQhSSCZYFOQAMKGAEKh?= =?us-ascii?q?RgCGoRmGAEBAQEBAQEBAQEBAoEQgjgkAQkERikDAQEBAQEBJgEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBARoCDTEsAQEBAQMBARgBCApBCwwEAgEIDQQBAwEBCxYBBgMCAgIlCxQDB?= =?us-ascii?q?ggCBAENBQgTiSF0qTaCJ4pyAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDKgSBKoI?= =?us-ascii?q?ugWiCdTWEbxgFBwkfAoJcL4IyBYshjVyIfgKHY4EXhSWIbYV/hAKHFYopizQCB?= =?us-ascii?q?AsCGQGBOR+CIXoVSYJkCYJQAxyBZ3eLNYERAQEB?= Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v9QHDDdc030998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Oct 2017 13:13:13 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Thu, 26 Oct 2017 13:13:13 -0400 From: "Teague, Nik" To: "Mortensen, Andrew" , Flemming Andreasen CC: Jon Shallow , "Konda, Tirumaleswar Reddy" , "mohamed.boucadair@orange.com" , "dots@ietf.org" , Dave Dolson Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AQHTTnuxIf2u4Wrep0ya+UMj3YKKJqL2Xdnw Date: Thu, 26 Oct 2017 17:13:12 +0000 Message-ID: <065D9BA7C7AAA94BA6F5BDB1A41269DD721DD2EE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> In-Reply-To: <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: multipart/alternative; boundary="_000_065D9BA7C7AAA94BA6F5BDB1A41269DD721DD2EEBRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 17:13:22 -0000 --_000_065D9BA7C7AAA94BA6F5BDB1A41269DD721DD2EEBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXAgdG8gbm93IHdl4oCZdmUgdHJlYXRlZCBoZWFydGJlYXRzIGFzIGVzc2VudGlhbGx5IDJ4IHVu aWRpcmVjdGlvbmFsIHNpZ25hbHMg4oCTIEkgdGhpbmsgdGhlcmXigJlzIHZhbHVlIGluIHRoZSB6 ZXJvIGhlYXJ0YmVhdCBtb2Rl4oCmIG1heWJlIGFub3RoZXIgd2F5IHRvIGxvb2sgYXQgYSB3YXkg YXJvdW5kIHRoZSBuYXQgd291bGQgYmUgYSDigJhwYXNzaXZl4oCZIG1vZGUgd2hlcmUgYSBjbGll bnQgY2FuIHNvbGljaXQgYSBoZWFydGJlYXQNCg0KRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1vcnRlbnNlbiwgQW5kcmV3DQpTZW50OiBUaHVy c2RheSwgT2N0b2JlciAyNiwgMjAxNyA1OjU5IFBNDQpUbzogRmxlbW1pbmcgQW5kcmVhc2VuIDxm YW5kcmVhc0BjaXNjby5jb20+DQpDYzogSm9uIFNoYWxsb3cgPHN1cGpwcy1pZXRmQGpwc2hhbGxv dy5jb20+OyBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBNY0FmZWUuY29tPjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgZG90c0BpZXRmLm9y ZzsgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPg0KU3ViamVjdDogW0VYVEVSTkFM XSBSZTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3 ICgtMDYpKQ0KDQoNCk9uIE9jdCAyNiwgMjAxNywgYXQgOTo0NiBBTSwgRmxlbW1pbmcgQW5kcmVh c2VuIDxmYW5kcmVhc0BjaXNjby5jb208bWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbT4+IHdyb3Rl Og0KDQpBcyBJIGhhdmUgc3RhdGVkIHNldmVyYWwgdGltZXMgYmVmb3JlLCBJJ20gbm90IGFsbCB0 aGF0IGNvbWZvcnRhYmxlIHdpdGggdGhlIGN1cnJlbnQgcmVxdWlyZW1lbnQgYXJvdW5kIGFsd2F5 cyBzZW5kaW5nIGtlZXAtYWxpdmVzLCB3aGV0aGVyIGF0dGFja3MgYXJlIGluIHByb2dyZXNzIG9y IG5vdy4gTXkgY29uY2VybnMgYXJlIGFyb3VuZCBzY2FsYWJpbGl0eS9jb3N0IG9mIHRoZSBvdmVy YWxsIHNvbHV0aW9uLCBzbyBJIHRoaW5rIGl0J3Mgd29ydGggY29uc2lkZXJpbmcgZHVyaW5nIHBl YWNlLXRpbWUgYXQgbGVhc3QuDQoNCkhpIEZsZW1taW5nLiBJIHN1c3BlY3QgeW91ciBjb25jZXJu cyBhcmVu4oCZdCBmdWxseSBhZGRyZXNzZWQgYnkgcmVkdWNpbmcgdGhlIGhlYXJ0YmVhdCBNVVNU IHRvIGEgU0hPVUxELCBhcyBjYXB0dXJlZCBpbiB0aGlzIGlzc3VlOg0KDQo8aHR0cHM6Ly9naXRo dWIuY29tL2RvdHN3Zy9kb3RzLXJlcXVpcmVtZW50cy9pc3N1ZXMvNTc+DQoNCkRvIHdlIG5lZWQg dG8gcmVjYXN0IHRoZSByZXF1aXJlbWVudCB0byBjYXB0dXJlIHRoZSBwZWFjZS10aW1lIGFzcGVj dD8gRm9yIGV4YW1wbGUsIHNob3VsZCBhIERPVFMgc2VydmVyIGJlIGFibGUgdG8gdGVsbCBhIGNs aWVudCB0byBzdG9wIGhlYXJ0YmVhdHMsIG9yIHNsb3cgdGhlIGhlYXJ0YmVhdCByYXRlPw0KDQph bmRyZXcNCg0KDQoNCk9uIDEwLzI2LzE3IDk6MTMgQU0sIERhdmUgRG9sc29uIHdyb3RlOg0KDQpJ J20gbm90IHB1c2hpbmcgZm9yIHRoaXMuIEkgc2F3IHRoZSB3b3JraW5nIGdyb3VwIHN0cnVnZ2xp bmcgd2l0aCB0aGUgZmlyZXdhbGwvTkFUIHByb2JsZW0sIGFuZCBvZmZlcmVkIGEgZGlmZmVyZW50 IHdheSBvZiB0aGlua2luZyBhYm91dCBpdC4NClRvIGJlIGNsZWFyLCBteSBzdWdnZXN0aW9uIGlz IHRvIHJlbW92ZSB1bnNvbGljaXRlZCBtZXNzYWdlcyBmcm9tIHRoZSBzZXJ2ZXIgdG8gY2xpZW50 Lg0KDQotRGF2ZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21dDQpTZW50OiBUaHVyc2RheSwg T2N0b2JlciAyNiwgMjAxNyAzOjA2IFBNDQpUbzogRGF2ZSBEb2xzb247IEtvbmRhLCBUaXJ1bWFs ZXN3YXIgUmVkZHk7IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7IGRvdHNAaWV0Zi5v cmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgJiBOQVQg KHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKQ0KDQpSZS0sDQoNCk5vdCBz dXJlIGhvdyB0byBnZXQgcmlkIG9mIHRoZSBjb25zdHJhaW50IGltcG9zZWQgYnkgdGhlIE5BVC9G VyB0aW1lciwgRGF2ZS4NCg0KVGhlIGN1cnJlbnQgdGV4dCBzYXlzIHRoZSBmb2xsb3dpbmc6DQoN CiAgIFRvIHByb3ZpZGUgYSBtZXRyaWMgb2Ygc2lnbmFsIGhlYWx0aCBhbmQgZGlzdGluZ3Vpc2gg YW4gJ2lkbGUnIHNpZ25hbA0KICAgY2hhbm5lbCBmcm9tIGEgJ2Rpc2Nvbm5lY3RlZCcgb3IgJ2Rl ZnVuY3QnIHNlc3Npb24sIHRoZSBET1RTIGFnZW50DQogICBzZW5kcyBhIGhlYXJ0YmVhdCBvdmVy IHRoZSBzaWduYWwgY2hhbm5lbCB0byBtYWludGFpbiBpdHMgaGFsZiBvZiB0aGUNCiAgIGNoYW5u ZWwuICBUaGUgRE9UUyBhZ2VudCBzaW1pbGFybHkgZXhwZWN0cyBhIGhlYXJ0YmVhdCBmcm9tIGl0 cyBwZWVyDQogICBET1RTIGFnZW50LCBhbmQgbWF5IGNvbnNpZGVyIGEgc2Vzc2lvbiB0ZXJtaW5h dGVkIGluIHRoZSBleHRlbmRlZA0KICAgYWJzZW5jZSBvZiBhIHBlZXIgYWdlbnQgaGVhcnRiZWF0 Lg0KDQpXaGljaCBjb3ZlcnMgeW91ciBwcm9wb3NhbC4gTm8/DQoNClNvbGljaXRlZCBtZXNzYWdl cyBmcm9tIHRoZSBzZXJ2ZXIgZG8gbm90IHByZXZlbnQgZnJvbSBmYWlsdXJlcy4gQ29uc2lkZXIg dGhlIGNhc2Ugd2hlcmUgYSBET1RTIHNlcnZlciBoYXMgdG8gc2VuZCBhIG1pdGlnYXRpb24gc3Rh dHVzIHVwZGF0ZSBiYWNrIHRvIHRoZSBjbGllbnQsIGJ1dCB0aGUgY2xpZW50IGRpZG4ndCByZWZy ZXNoZWQgdGhlIHN0YXRlLiBPciB3aGVuIHRoZSBOQVQgZmlyZWQgb3V0IGEgbWFwcGluZyBhbmQg YXNzaWducyB0aGUgZXh0ZXJuYWwgcG9ydCB0byBhbm90aGVyIGhvc3QgdGhhbiB0aGUgRE9UUyBj bGllbnQuDQoNCkRpZCBJIG1pc3NlZCBzb21ldGhpbmc/DQoNClRoYW5rIHlvdS4NCg0KQ2hlZXJz LA0KTWVkDQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZSA6IERhdmUgRG9sc29u IFttYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb21dIEVudm95w6kgOiBqZXVkaSAyNg0Kb2N0b2Jy ZSAyMDE3IDE0OjUwIMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgS29uZGEsIFRpcnVt YWxlc3dhcg0KUmVkZHk7IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7IGRvdHNAaWV0 Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+IE9iamV0IDogUmU6DQpbRG90c10gRE9UUyAmIE5B VCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQoNCk15IHBvaW50IHdh cyB0aGF0IGlmIHNlcnZlciBzdGF0dXMgd2FzIHNvbGljaXRlZCwga2VlcC1hbGl2ZSBpbnRlcnZh bA0Kd291bGQgYmUgaW5kZXBlbmRlbnQgb2YgZmlyZXdhbGwvTkFUIHRpbWVvdXQuIEtlZXAtYWxp dmVzIHdvdWxkIGJlDQpvcHRpb25hbC4NCg0KU29saWNpdGVkIG1lYW5zIHRoYXQgY2xpZW50IHNh eXMgImdldCBzdGF0dXMiIHZzLiB0aGUgc2VydmVyIGp1c3QNCnNlbmRpbmcgdXBkYXRlcy4NCg0K DQoNCkRhdmlkIERvbHNvbg0KU2FuZHZpbmUNCiAgT3JpZ2luYWwgTWVzc2FnZQ0KRnJvbTogbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT4NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDI6MTEgUE0NClRvOiBEYXZl IERvbHNvbjsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsgRmxlbW1pbmcgQW5kcmVhc2VuOyBK b24NClNoYWxsb3c7IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSRTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3 DQooLTA2KSkNCg0KDQpIaSBEYXZlLA0KDQpUaGUgcHJvdG9jb2wgZG9lcyBhbHJlYWR5IHN1cHBv cnQgYSBtZWNoYW5pc20gdG8gc2VuZCBrZWVwYWxpdmUNCm1lc3NhZ2VzIGV2ZXJ5IDMwcyAocmVj b21tZW5kZWQgdmFsdWUpLg0KDQpDaGVlcnMsDQpNZWQNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCkRlIDogRGF2ZSBEb2xzb24gW21haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbV0g RW52b3nDqSA6IGpldWRpIDI2DQpvY3RvYnJlIDIwMTcgMTM6MTUgw4AgOiBLb25kYSwgVGlydW1h bGVzd2FyIFJlZGR5OyBCT1VDQURBSVIgTW9oYW1lZA0KSU1UL09MTjsgRmxlbW1pbmcgQW5kcmVh c2VuOyBKb24gU2hhbGxvdzsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4gT2Jq ZXQgOiBSRToNCltEb3RzXSBET1RTICYgTkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJl dmlldyAoLTA2KSkNCg0KSSB0aGluayB0aGVyZSBpcyBhbm90aGVyIG9wdGlvbiB0byBoYW5kbGUg dGhlIE5BVC9maXJld2FsbCBwcm9ibGVtcw0KYnkgY2hhbmdpbmcgdGhlIHByb3RvY29sLg0KDQpJ ZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCBjdXJyZW50bHkgdGhlIE5BVCBhbmQgZmlyZXdhbGwg bmVlZCB0byBiZQ0Ka2VwdA0KDQpvcGVuIHRvIHBlcm1pdCB1bnNvbGljaXRlZCBzZXJ2ZXIgcGFj a2V0cy4NCg0KSWYgdGhlIHByb3RvY29sIGlzIGNoYW5nZWQgdG8gcmVxdWlyZSBjbGllbnQgcG9s bGluZyBvZiB0aGUgc2VydmVyDQp1cGRhdGVzLCB0aGUgTkFUIGFuZCBmaXJld2FsbCBwcm9ibGVt cyBnbyBhd2F5Lg0KDQotRGF2ZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS29uZGEs DQpUaXJ1bWFsZXN3YXINCg0KUmVkZHkNClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3 IDEyOjU4IFBNDQpUbzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNoYWxsb3c7 DQpkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEb3Rz XSBET1RTICYgTkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJldmlldw0KKC0wNikpDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpbbWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21dDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNiwg MjAxNyAyOjIxIFBNDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPFRpcnVtYWxlc3dh clJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1j QWZlZS5jb20+PjsNCkZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPG1haWx0 bzpmYW5kcmVhc0BjaXNjby5jb20+PjsgSm9uIFNoYWxsb3cgPHN1cGpwcy0NCmlldGZAanBzaGFs bG93LmNvbTxtYWlsdG86aWV0ZkBqcHNoYWxsb3cuY29tPj47IGRvdHNAaWV0Zi5vcmc8bWFpbHRv OmRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgJiBOQVQgKHdhcyBSRTog RE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3DQooLTA2KSkNCg0KUmUtLA0KDQpJIGhlYXIgeW91LiBN eSB0YWtlIGlzIHRoYXQgd2UgZG9uJ3QgbmVlZCB0byByZWNvbW1lbmQgd2hpY2gNCmNvbXBhbmlv biAicHJvdG9jb2xzL21lY2hhbmlzbXMiIG5lZWQgdG8gYmUgc3VwcG9ydGVkIGZvciBOQVQvRlcN CnRyYXZlcnNhbCBwdXJwb3Nlcy4gSGF2aW5nIGEgZGlzY3Vzc2lvbiBhdCB0aGUgc2FtZSBsZXZl bCBpbiA4MDg1DQp3b3VsZCBiZSBzdWZmaWNpZW50LCBJTUhPLg0KDQpMZXQncyBmb2N1cyBvbiB0 aGUgc2ltcGxlIGJ1aWx0LWluIGZlYXR1cmUgZm9yIE5BVCBkZXRlY3QuDQpJIGRvbid0IHRoaW5r IHRoZSBzaW1wbGUgYnVpbHQtaW4gZmVhdHVyZSBpcyBzdWZmaWNpZW50LCBET1RTIGNsaWVudA0K d2lsbA0KDQpoYXZlIHRvIHJlbHkgb24gbWVjaGFuaXNtcyBkaXNjdXNzZWQgaW4gODA4NSBmb3Ig Ym90aCBmaXJld2FsbCBhbmQNCk5BVCB0cmF2ZXJzYWwuDQoNCi1UaXJ1DQoNCg0KQ2hlZXJzLA0K TWVkDQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZSA6IEtvbmRhLCBUaXJ1bWFs ZXN3YXIgUmVkZHkNClttYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0N CkVudm95w6kgOiBqZXVkaSAyNiBvY3RvYnJlIDIwMTcgMTA6MzYgw4AgOiBCT1VDQURBSVIgTW9o YW1lZA0KSU1UL09MTjsgRmxlbW1pbmcgQW5kcmVhc2VuOyBKb24gU2hhbGxvdzsgZG90c0BpZXRm Lm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4gT2JqZXQgOg0KUkU6IFtEb3RzXSBET1RTICYgTkFU ICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KSkNCg0KQnV0IE5BVHMgYXJl IG5vdCB0aGUgb25seSBwcm9ibGVtLCBmaXJld2FsbHMgd2lsbCBhbHNvIGJlIG1vc3QNCmxpa2Vs eSBwcmVzZW50LCBhbmQgU1RVTiBoZWxwcyBkaXNjb3ZlciBib3RoIE5BVHMgYW5kIGZpcmV3YWxs cw0KYW5kIHVzZWZ1bCBldmVuIGluIElQdjYgbmV0d29ya3MgdG8gZGV0ZXJtaW5lIHRoZSBrZWVw YWxpdmUNCmludGVydmFsIG9mDQpmaXJld2FsbC4NCg0KLVRpcnUNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NClttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDE6NTIgUE0NClRv OiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNB ZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4+Ow0KDQpG bGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2NvLmNvbTxtYWlsdG86ZmFuZHJlYXNAY2lz Y28uY29tPj47IEpvbiBTaGFsbG93IDxzdXBqcHMtDQppZXRmQGpwc2hhbGxvdy5jb208bWFpbHRv OmlldGZAanBzaGFsbG93LmNvbT4+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3Jn Pg0KU3ViamVjdDogUkU6IFtEb3RzXSBET1RTICYgTkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1l bnRzDQpyZXZpZXcNCigtMDYpKQ0KDQpUaXJ1LA0KDQpZZXMsIFNUVU4gY2FuIGJlIGxpc3RlZCBh cyBwYXJ0IG9mIHRoZSBleGlzdGluZyB0b29scyBib3gNCihhbW9uZyB0aGUNCmxpbmVzIG9mDQoN CndoYXQgaXMgYWxyZWFkeSBkaXNjdXNzZWQgaW4gODA4NSkuDQoNCkkgZG9uJ3QgdGhpbmsgdGhh dCBpdCBtYWtlcyBzZW5zZSB0byByZXF1aXJlIFNUVU4gc3VwcG9ydCBieQ0KRE9UUw0KY2xpZW50 cy4NCg0KVGhlIHByb3Bvc2FsIGlzIHRvIGluY2x1ZGUgYSBzaW1wbGUgYnVpbHQtaW4gZmVhdHVy ZSBpbiB0aGUNCkRPVFMNCnByb3RvY29sIGl0c2VsZg0KDQp0aGF0IGNhbiBoZWxwIHRvIGRldGVj dCBOQVRzLiBUaGUgc3VwcG9ydCBvZiBzdWNoIGZlYXR1cmUNCndpbGwsIGUuZy4sDQplYXNlDQoN CnRyb3VibGVzaG9vdGluZyB3aGVuIGNvbm5lY3Rpdml0eSBwcm9ibGVtcyBhcmUgZXhwZXJpZW5j ZWQgb24NCnRoZSBwYXRoIGJldHdlZW4gYSBjbGllbnQgYW5kIGEgc2VydmVyLg0KDQpDaGVlcnMs DQpNZWQNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlIDogS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeQ0KW21haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29t XQ0KRW52b3nDqSA6IGpldWRpIDI2IG9jdG9icmUgMjAxNyAwOTo0NCDDgCA6IEJPVUNBREFJUiBN b2hhbWVkDQpJTVQvT0xOOyBGbGVtbWluZyBBbmRyZWFzZW47IEpvbiBTaGFsbG93OyBkb3RzQGll dGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPiBPYmpldCA6DQpSRTogW0RvdHNdIERPVFMgJiBO QVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3DQooLTA2KSkNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mDQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzpt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyNCwg MjAxNyAyOjIwIFBNDQpUbzogRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0BjaXNjby5jb208 bWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbT4+OyBKb24gU2hhbGxvdw0KPHN1cGpwcy0gaWV0ZkBq cHNoYWxsb3cuY29tPG1haWx0bzppZXRmQGpwc2hhbGxvdy5jb20+PjsgZG90c0BpZXRmLm9yZzxt YWlsdG86ZG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRG90c10gRE9UUyAmIE5BVCAod2Fz IFJFOiBET1RTIFJlcXVpcmVtZW50cw0KcmV2aWV3DQooLTA2KSkNCg0KSGkgRmxlbW1pbmcsIGFs bCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQoNCi0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLSBEZSA6IEZsZW1taW5nIEFuZHJlYXNlbg0KW21haWx0bzpmYW5kcmVh c0BjaXNjby5jb21dIEVudm95w6kgOg0KbHVuZGkNCjIzIG9jdG9icmUgMjAxNyAxNzozNiDDgCA6 IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEpvbg0KU2hhbGxvdzsgZG90c0BpZXRmLm9yZzxt YWlsdG86ZG90c0BpZXRmLm9yZz4gT2JqZXQgOiBSZTogRE9UUyAmIE5BVCAod2FzIFJFOg0KW0Rv dHNdIERPVFMgUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KSkNCg0KDQoNCk9uIDEwLzIzLzE3IDg6 MjggQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KDQpIaSBKb24sIGFsbCwNCg0KSSBhZ3JlZSB3aXRoIEZs ZW1taW5nIHRoYXQgInNvbWUgbW9yZSB3b3JrIiBpcyBuZWVkZWQuDQpJTUhPLCB0aGlzIGlzIGEN CnR5cGljYWwgZGlzY3Vzc2lvbiB0byBpbmNsdWRlIGluIGEgZGVkaWNhdGVkIHNlY3Rpb24gaW4N CnRoZSBET1RTIGFyY2hpdGVjdHVyZSBJLUQuDQpBZ3JlZWQuDQoNCj5Gcm9tIGEgcmVxdWlyZW1l bnQgc3RhbmRwb2ludCwgd2UgZG9uJ3QgbmVlZCB0bw0KDQplbGFib3JhdGUgaG93IHRoZQ0KcHJv dG9jb2xzIHdpbGwgZnVsZmlsIGl0LiBTSUctMTAgZG9lcyBldmVuIGEgbmljZSBqb2IgYnkNCmNp dGluZw0KUkZDODA4NSB3aGljaCBwb2ludHMgdG8gTkFUIHRyYXZlcnNhbCBtZWNoYW5pc21zLiBP bmUNCmNvdWxkIHBpY2sgaGlzL2hlciBmYXZvcml0ZSBwcm90b2NvbCBmcm9tIHRoZSBsaXN0IGlu DQo4MDg1IHRvIGRpc2NvdmVyIHRoZSBleHRlcm5hbCBJUCBhZGRyZXNzL3ByZWZpeCwgaWYNCm5l ZWRlZC4gRXh0ZXJuYWwgSVAgYWRkcmVzc2VzL3ByZWZpeGVzIGNhbiBiZSBJUHY0IGZvciBhDQpO QVQ0NCBvciBOQVQ2NCwgYnV0IGNhbiBiZQ0KSVB2NiBwcmVmaXhlcyBmb3IgZW50ZXJwcmlzZXMg ZGVwbG95aW5nIE5QVHY2LCBhbmQgc28gb24uDQpQYXJ0IG9mIHRoZSBjaGFsbGVuZ2UgaGVyZSBp cyB0aGF0IHRoZSBhdHRhY2sgdGFyZ2V0IGFuZA0KdGhlIERPVFMgY2xpZW50IGFyZSBub3QgbmVj ZXNzYXJpbHkgb25lIGFuZCB0aGUgc2FtZSwNCndoaWNoIG1ha2VzIGl0IG1vcmUgZGlmZmljdWx0 IHRvIGRldGVybWluZSB0aGUNCnB1YmxpYy1mYWNpbmcgSVAtYWRkcmVzcy9wb3J0IHVuZGVyIGF0 dGFjayAoYXQgbGVhc3QgaWYNCnRoZSBET1RTIGNsaWVudCBpcyBnb2luZyB0bw0KZG8gaXQpLg0K DQpbTWVkXSBUaGlzIGlzIGV4YWN0bHkgdGhlIGtpbmQgb2YgdGhlIGRpc2N1c3Npb24gdG8gaGF2 ZS4NClRoYW5rcy4NCg0KV2l0aCBvciB3aXRob3V0IE5BVCwgRE9UUyBjbGllbnRzIGFyZSBhc3N1 bWVkIHRvIGJlIGZlZA0Kd2l0aCB0aGUNCmludGVybmFsDQoNCnRhcmdldChzKS4gVGhpcyBjYW4g YmUgYWNoaWV2ZWQgYnkgcHJvdmlzaW9uaW5nIChsaWtlbHkpDQpvciBieSBkaXNjb3ZlcnkNCm1l YW5zDQoNCihlLmcuLCByZXNpZGVudGlhbCBvciBzbWFsbCBlbnRlcnByaXNlIG5ldHdvcmtzKS4N Cg0KQ2FuIHdlIGFzc3VtZSB0aGF0IHRoZSBkaXNjb3Zlcnkgb2YgdGhlIGV4dGVybmFsIElQDQph ZGRyZXNzL3ByZWZpeC8uLiBpcw0KZG9uZQ0KDQpieSBhIERPVFMgY2xpZW50IG9ubHkgaWYgaXQg aXMgZXhwbGljaXRseSBpbnN0cnVjdGVkIHRvIGRvIHNvPw0KDQoNCg0KSW4gc29tZSBkZXBsb3lt ZW50cywgRE9UUyBjbGllbnRzIG1heSBiZSBwcm92aXNpb25lZA0Kd2l0aCB0aGUgc2V0IG9mDQpp bnRlcm5hbCByZXNvdXJjZXMsIHNvIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGRpc2NvdmVyeS4NCg0K QWxzbywgYXMgSm9uIG1lbnRpb25lZCwgRE9UUyBnYXRld2F5cyBjYW4gYmUgb2YgaGVscA0KdG8g c2V0IHRoZQ0KYXBwcm9wcmlhdGUgSVAgYWRkcmVzc2VzL3ByZWZpeGVzL3BvcnQgbnVtYmVycyBp biB0aGUNCnByZXNlbmNlIG9mIHRyYW5zbGF0b3JzLg0KQWdyZWVkIC0gYnV0IHRoZXkgc3RpbGwg bmVlZCBhIHdheSB0byBmaWd1cmUgb3V0IHRoZQ0KcHJpdmF0ZS9wdWJsaWMgbWFwcGluZyBmb3Ig YSBnaXZlbiBhdHRhY2sgdGFyZ2V0Lg0KW01lZF0gQmVjYXVzZSBhIEREb1MgYXR0YWNrIGlzIG9i c2VydmVkIGZyb20gdGhlIGludGVybmFsDQpuZXR3b3JrLA0KbWFwcGluZyhzKSBhcmUgbmVjZXNz YXJpbHkgbWFpbnRhaW5lZCBieSB0aGUgb24tcGF0aA0KdHJhbnNsYXRvcihzKS4NCg0KT3RoZXJ3 aXNlLCB0aGUgaW5jb21pbmcgYXR0YWNrIHRyYWZmaWMgY291bGRuJ3QgYmUNCmZvcndhcmRlZCB0 byBpbnRlcm5hbA0KaG9zdHMuDQoNClRoaXMgbW9kZWwgYXNzdW1lcyB0aGF0IHRoZSBnYXRld2F5 IGlzIGNvbGxvY2F0ZWQgd2l0aCB0aGUNCk5BVC4NCg0KU28sIHRoZSBnYXRld2F5IGNhbiByZXBs YWNlIHRoZSBpbnRlcm5hbCBJUCBhZGRyZXNzL3ByZWZpeA0Kd2l0aCB0aGUgb25lDQpyZXRyaWV2 ZXMNCg0KZnJvbSB0aGUgTkFUIG1hcHBpbmcgdGFibGUuDQoNCkRvIHlvdSBzZWUgYW55IGlzc3Vl IHdpdGggdGhpcyBzY2hlbWU/DQoNCg0KQW4gb3BlbiBxdWVzdGlvbiB0aG91Z2ggd291bGQgYmUg dG8gZGlzY3VzcyBpZiB0aGVyZQ0KaXMgYSB2YWx1ZSBpbg0KaGF2aW5nIGEgZmVhdHVyZSBpbiB0 aGUgRE9UUyBwcm90b2NvbCB0byBpbmZvcm0gYSBET1RTDQpjbGllbnQgdGhhdCBhIE5BVCBpcyBk ZXRlY3RlZCBvbi1wYXRoLiBUaGlzIGNhbiBiZQ0KcHJlc2VudGVkIGFzIGFuIGluZm9ybWF0aW9u IGVsZW1lbnQgcmV0dXJuZWQgYnkgdGhlDQpzZXJ2ZXIgdG8gdGhlIGNsaWVudC4gVGhpcyBpbmZv cm1hdGlvbiBjYW4gYmUsIGZvcg0KZXhhbXBsZSwgdXNlZCBieSB0aGUgY2xpZW50IHRvIGFkanVz dCBpdHMgSFQgaW50ZXJ2YWwsDQphZGp1c3QgdGhlIGludGVybmFsIElQIGFkZHJlc3Nlcy9wcmVm aXhlcyB0byBiZQ0KcHJvdGVjdGVkLCBldGMuDQoNCk9waW5pb25zPw0KDQpJdCBzb3VuZHMgYXBw ZWFsaW5nLCBidXQgaXQncyB2ZXJ5IGRpZmZpY3VsdCB0byBkbyB0aGlzDQpyZWxpYWJseSwgYW5k IGl0J3Mgbm90IGp1c3QgTkFUcyB0aGF0IGFyZSBhbiBpc3N1ZSBoZXJlOw0KRmlyZXdhbGxzIHBy ZXNlbnQgc2ltaWxhciBjaGFsbGVuZ2VzIChhbmQgdGhleSBtYXkgb3INCm1heSBub3QgYmUgTkFU J2luZyBpbmRpdmlkdWFsDQpmbG93cykuDQoNCltNZWRdIEkgZnVsbHkgYWdyZWUgdGhhdCBmaXJl d2FsbHMgZGV0ZWN0IGlzIG1vcmUgY29tcGxleC4NCkxldCdzIHB1dCBpdA0KYXNpZGUNCg0KYW5k IGZvY3VzIG9uIHRoZSBOQVQgY2FzZS4NClRoZSBwcmVzZW5jZSBhbmQgYmVoYXZpb3Igb2YgTkFU IGFuZCBGaXJld2FsbCwgYW5kIGtlZXBhbGl2ZQ0KaW50ZXJ2YWwgY2FuIGJlIGRldGVybWluZWQg dXNpbmcgU1RVTiAoZGlzY3Vzc2VkIGluDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTc4MCkuDQoNCi1UaXJ1DQoNCg0KV2UgY2FuIGNvbnNpZGVyIG1hbnkgYXBwcm9hY2hlcyB0byBk ZXRlY3QgYSBOQVQsIGUuZy4sDQoNCigxKSBUaGUgRE9UUyBjbGllbnQgaW5zZXJ0cyBpbiB0aGUg Y29yZSBtZXNzYWdlIHRoZSBJUA0KYWRkcmVzcy9wb3J0IGl0DQp1c2VzIHRvDQoNCnNlbmQgdGhl IHJlcXVlc3QgdG8gdGhlIERPVFMgc2VydmVyLiBVcG9uIHJlY2VpcHQgb2YgdGhlDQpyZXF1ZXN0 IGJ5IHRoZSBET1RTIHNlcnZlciwgaXQgY2hlY2tzIGlmIHRoZSBlbmNsb3NlZCBJUA0KYWRkcmVz cy9wb3J0IG1hdGNoIHRoZSBzb3VyY2UNCklQDQoNCmFkZHJlc3MvcG9ydCBvZiB0aGUgcmVjZWl2 ZWQgcGFja2V0LiBJZiB5ZXMsIHRoZSBzZXJ2ZXINCnNldHMgaW4gdGhlDQpyZXNwb25zZSBhDQoN CmRlZGljYXRlZCBwYXJhbWV0ZXIgdG8gaW5kaWNhdGUgdGhhdCBhIHRyYW5zbGF0b3IgaXMNCmRl dGVjdGVkDQpvbi0NCnBhdGguDQoNCigyKSBUaGUgRE9UUyBzZXJ2ZXIgaW5zZXJ0cyBzeXN0ZW1h dGljYWxseSB0aGUgc291cmNlIElQDQphZGRyZXNzL3BvcnQgaW4NCmENCg0KcmVzcG9uc2UgdG8g YSBtZXNzYWdlIGZyb20gYSBET1RTIGNsaWVudC4gVXBvbiByZWNlaXB0IG9mDQp0aGF0IHJlc3Bv bnNlLCB0aGUgRE9UUyBjbGllbnQgY29tcGFyZXMgdGhlIGVuY2xvc2VkDQphZGRyZXNzL3BvcnQg d2l0aCB0aGUgb25lcyBpdCB1c2VkDQp0bw0KDQpzZW5kIHRoZSByZXF1ZXN0IHRvIGRldGVjdCBh bnkgbWlzbWF0Y2guDQoNCg0KDQotLSBGbGVtbWluZw0KDQoNCg0KQ2hlZXJzLA0KTWVkDQoNCg0K LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tIERlIDogRG90cw0KW21haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSm9uDQpTaGFsbG93IEVudm95w6kgOiBsdW5kaSAy MyBvY3RvYnJlIDIwMTcgMTM6MTggw4AgOg0KJ0ZsZW1taW5nIEFuZHJlYXNlbic7IGRvdHNAaWV0 Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+IE9iamV0IDogUmU6DQpbRG90c10gRE9UUyBSZXF1 aXJlbWVudHMgcmV2aWV3ICgtMDYpDQoNCkhpIEZsZW1taW5nLA0KDQpUaGUgd2F5IG15IG1pbmQg d29ya3MgaXMgdG8gdGhpbmsgb2YgYSBwcmFjdGljYWwNCnNpdHVhdGlvbiBhbmQgc2VlIGlmIHRo aW5ncyBmaXQuDQoNCkFzIEkgcmVhZCBTSUctMDEwLCB0aGVyZSBjb3VsZCBiZSBhIERPVFMgY2xp ZW50IHdpdGgNCmEgbWFuYWdlbWVudCBJUCBhZGRyZXNzIHRoYXQgaXMgUkZDMTkxOCAtIHRoaXMg Y2xpZW50DQpjb3VsZCBiZSBtb25pdG9yaW5nIE5ldGZsb3cgaW5mb3JtYXRpb24gYW5kIGNhbg0K cmVxdWVzdCBtaXRpZ2F0aW9uIGZvciB0aGUgYXBwcm9wcmlhdGUgcHVibGljIElQcw0KdGhhdA0K DQphcmUgYmVpbmcgbW9uaXRvcmVkLiAgU28gU0lHLTAxMCBpcyBuZWVkZWQgZm9yIHRoaXMNCnVz ZQ0KY2FzZS4NCg0KSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBET1RTIHNlcnZlciBh cyB0bw0Kd2hldGhlciBpdCBhY2NlcHRzIGEgbWl0aWdhdGlvbiByZXF1ZXN0IGZvciBhDQpwYXJ0 aWN1bGFyIHRhcmdldCBpcCAob3IgZG9tYWluDQpldGMuKSBvcg0KDQpub3QuDQoNCklmIHRoZXJl IGlzIGdvaW5nIHRvIGJlIGEgTkFUIGJvcmRlciB3aGVyZSBwdWJsaWMgSVBzDQphcmUgbWFwcGVk IGludG8gcHJpdmF0ZSBJUHMgKGFuZCB2aWNlIHZlcnNhKSwgSSB3b3VsZA0KdGhlbiBleHBlY3Qg dGhlcmUgdG8gYmUgYSBET1RTIGdhdGV3YXkgYmV0d2VlbiB0aGVzZQ0KMiB6b25lcywgYW5kIGl0 IGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgRE9UUw0KZ2F0ZXdheSB0byBkbyBhbnkgdGFy Z2V0LWlwDQptYXBwaW5ncy4NCg0KUmVnYXJkcw0KDQpKb24NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IERvdHMgW21haWx0bzppZXRmLXN1cGpwcy1kb3RzLWJvdW5jZXNAaWV0 Zi5vcmddDQpPbiBCZWhhbGYgT2YgRmxlbW1pbmcgQW5kcmVhc2VuDQpTZW50OiAyMiBPY3RvYmVy IDIwMTcgMjA6MTcNClRvOiBkb3RzOyBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzQGlldGYu b3JnPG1haWx0bzpkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnPg0KU3ViamVj dDogW0RvdHNdIERPVFMgUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KQ0KDQpHcmVldGluZ3MNCg0K SSBoYXZlIHJldmlld2VkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgRE9UUw0KcmVxdWlyZW1l bnRzIGRyYWZ0DQooaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1kb3RzLXJlcXVp cmVtZW50cw0KLQ0KMDYudHh0KS4NCg0KSW4NCmdlbmVyYWwsDQoNCkkgdGhpbmsgdGhlIGRyYWZ0 IGlzIGluIGdvb2Qgc2hhcGUgd2l0aCBvbmx5IGEgZmV3DQplZGl0cyByZXF1aXJlZCwgc28gSSBo b3BlIHdlIGNhbiBtb3ZlIHRvIFdHTEMgc29vbi4gSQ0KaGF2ZSBhIGZldyBjb21tZW50cyBiZWxv dyAob2Ygd2hpY2gNCnRoZQ0KDQpOQVQgb25lIGlzIHRoZSBvbmx5IHJlYWwgc3Vic3RhbnRpYWwg b25lKS4gSSBoYXZlDQphbHNvIHN1Ym1pdHRlZCBhIHB1bGwgcmVxdWVzdCB3aXRoIGEgZmV3IG5p dCBmaXhlcyBvbiBHaXRIdWI6DQoNCg0KU2VjdGlvbiAxLjINCi0gVGhlIGRlZmluaXRpb24gb2Yg IkRPVFMgU2lnbmFsIiBpcyBzbGlnaHRseQ0KaW5jb25zaXN0ZW50IHdpdGggdGhlIHJlc3BlY3Rp dmUgIkNsaWVudCBTaWduYWwiIGFuZA0KIlNlcnZlciBTaWduYWwiIGRlZmluaXRpb25zLg0KDQpT SUctMDA1Og0KLSBOb3QgY2xlYXIgdGhhdCBhbHdheXMgcmVxdWlyaW5nICJudW1iZXIgb2YgcGFj a2V0cyINCm1ldHJpY3MgaXMgbWVhbmluZ2Z1bC4gQ29uc2lkZXIgVENQLWJhc2VkIGF0dGFja3Mg Zm9yDQpleGFtcGxlLiBOdW1iZXIgb2YgYnl0ZXMgbWF5IGFsd2F5cyBiZSBvayAtIGFib3ZlIGFu ZA0KYmV5b25kIHRoYXQgaXQgc2hvdWxkIHByb2JhYmx5IGJlIGV4dGVuc2libGUgYW5kL29yDQph dHRhY2sNCmRlcGVuZGVudC4NCg0KLSBJIGRvbid0IHRoaW5rIHRoZSByZXF1aXJlbWVudHMgZG9j dW1lbnQgc2hvdWxkIGdldA0KaW50byBzcGVjaWZ5aW5nDQp0aW1lcg0KDQp2YWx1ZXMgLSBleHBv bnRpYWwgYmFja29mZiB3aXRoIHNvbWUgbWF4aW11bSB2YWx1ZQ0Kc2VlbXMgYWJvdXQgdGhlDQpy aWdodA0KDQpsZXZlbCBvZiBkZXRhaWwgaGVyZS4NCg0KU0lHLTAwOToNCi0gVG8gYmUgY2xlYXIs IHRoZSBjb25mbGljdHMgb25seSBhcHBseSB3aXRoaW4gYQ0Kc2luZ2xlIGFkbWluaXN0cmF0aXZl IGRvbWFpbiwgcmlnaHQgPyBGb3IgZXhhbXBsZSwgaWYNCmEgY2xpZW50IHRlbGxzIHRoZSBzYW1l IGRvbWFpbiB0byBhbHRlcm5hdGVseSB0dXJuDQpvbi9vZmYgbWl0aWdhdGlvbiBmb3IgYSBnaXZl biBwcmVmaXgsIHJvdXRlIGZsYXBwaW5nDQptYXkNCg0Kb2NjdXIuIFRoZSBzYW1lIGNvbmNlcm4g ZG9lcyBub3QgYXBwbHkgaWYgYSBjbGllbnQNCnRlbGxzIHR3byBkaWZmZXJlbnQgYWRtaW5pc3Ry YXRpdmUgZG9tYWlucyB0bw0KcmVzcGVjdGl2ZSB0dXJuIG1pdGlnYXRpb24gb24gKGRvbWFpbiAx KSBhbmQNCm9mZg0KDQooZG9tYWluIDIpLiBJZiBzbywgY2FuIHdlIGNsYXJpZnkgdGhhdCAoYWxz byBpbiBsaWV1DQpvZiBzb21lIG9mIHRoZQ0KbXVsdGktDQoNCmhvbWluZyBjb21tZW50cyByYWlz ZWQgcHJldmlvdXNseSkgPw0KDQpTSUctMDEwOg0KLSBET1RTIENsaWVudCBiZWhpbmQgTkFULiBP biBvbmUgaGFuZCwgaXQgc2VlbXMNCnJlYXNvbmFibGUgdG8gaGF2ZSB0aGlzIHJlcXVpcmVtZW50 IHNpbmNlIGNsaWVudHMgZm9yDQpzdXJlIGNhbiBiZSBiZWhpbmQgTkFUcywgYW5kDQp3aXRoDQoN CnRoaW5ncw0KDQpsaWtlIGR5bmFtaWMgRE5TLCB0aGV5IGNhbiAgICAgY2VydGFpbmx5IGJlIHJl YWNoYWJsZS4NCkhvd2V2ZXIsDQoNCmlmDQoNCndlDQoNCmRvDQoNCndhbnQgdG8gYWxsb3cgZm9y IHRoaXMgc2NlbmFyaW8sIGFuZCBpbiBwYXJ0aWN1bGFyDQpmb3IgdGhlIERPVFMgY2xpZW50DQp0 bw0KDQpoYXZlIGEgcHJpdmF0ZSBJUC1hZGRyZXNzIChwb3RlbnRpYWxseSBiZWhpbmQNCm11bHRp cGxlIE5BVHMpLCB0aGVuIHdlDQpoYXZlDQoNCm1vcmUgd29yayB0byBkbyBiZWNhdXNlIGl0IHdv bid0IGRvIHRoZSBET1RTIHNlcnZlcg0KYW55IGdvb2QgdG8gZ2V0IGEgbWl0aWdhdGlvbiByZXF1 ZXN0IHJlZmVycmluZyB0bw0KdGhhdCBwcml2YXRlIElQLWFkZHJlc3MgKG9yDQpwcmVmaXgpLg0K DQoNClRoYW5rcw0KDQotLSBGbGVtbWluZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmc8bWFp bHRvOkRvdHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkRvdHMgbWFpbGluZyBsaXN0DQpEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQouDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QN CkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0KRG90c0BpZXRmLm9yZzxtYWlsdG86 RG90c0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90 cw0KLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg0K --_000_065D9BA7C7AAA94BA6F5BDB1A41269DD721DD2EEBRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXAgdG8gbm93IHdl4oCZdmUg dHJlYXRlZCBoZWFydGJlYXRzIGFzIGVzc2VudGlhbGx5IDJ4IHVuaWRpcmVjdGlvbmFsIHNpZ25h bHMg4oCTIEkgdGhpbmsgdGhlcmXigJlzIHZhbHVlIGluIHRoZSB6ZXJvIGhlYXJ0YmVhdCBtb2Rl 4oCmIG1heWJlIGFub3RoZXIgd2F5IHRvIGxvb2sgYXQgYSB3YXkgYXJvdW5kIHRoZSBuYXQgd291 bGQgYmUgYSDigJhwYXNzaXZl4oCZIG1vZGUgd2hlcmUgYSBjbGllbnQgY2FuIHNvbGljaXQgYSBo ZWFydGJlYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9N YWlsRW5kQ29tcG9zZSI+PG86cD4mbmJzcDs8L286cD48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gRG90cyBbbWFp bHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+TW9ydGVuc2Vu LCBBbmRyZXc8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE9jdG9iZXIgMjYsIDIwMTcgNTo1 OSBQTTxicj4NCjxiPlRvOjwvYj4gRmxlbW1pbmcgQW5kcmVhc2VuICZsdDtmYW5kcmVhc0BjaXNj by5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKb24gU2hhbGxvdyAmbHQ7c3VwanBzLWlldGZAanBz aGFsbG93LmNvbSZndDs7IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0O1RpcnVtYWxlc3dh clJlZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t OyBkb3RzQGlldGYub3JnOyBEYXZlIERvbHNvbiAmbHQ7ZGRvbHNvbkBzYW5kdmluZS5jb20mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gUmU6IFtEb3RzXSBET1RTICZhbXA7IE5B VCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMjYsIDIwMTcsIGF0IDk6NDYgQU0s IEZsZW1taW5nIEFuZHJlYXNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNv bSI+ZmFuZHJlYXNAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBJIGhhdmUgc3RhdGVkIHNldmVyYWwgdGltZXMg YmVmb3JlLCBJJ20gbm90IGFsbCB0aGF0IGNvbWZvcnRhYmxlIHdpdGggdGhlIGN1cnJlbnQgcmVx dWlyZW1lbnQgYXJvdW5kIGFsd2F5cyBzZW5kaW5nIGtlZXAtYWxpdmVzLCB3aGV0aGVyIGF0dGFj a3MgYXJlIGluIHByb2dyZXNzIG9yIG5vdy4gTXkgY29uY2VybnMgYXJlIGFyb3VuZCBzY2FsYWJp bGl0eS9jb3N0IG9mIHRoZSBvdmVyYWxsIHNvbHV0aW9uLA0KIHNvIEkgdGhpbmsgaXQncyB3b3J0 aCBjb25zaWRlcmluZyBkdXJpbmcgcGVhY2UtdGltZSBhdCBsZWFzdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSBGbGVtbWluZy4gSSBzdXNwZWN0IHlvdXIgY29uY2VybnMgYXJlbuKAmXQgZnVsbHkg YWRkcmVzc2VkIGJ5IHJlZHVjaW5nIHRoZSBoZWFydGJlYXQgTVVTVCB0byBhIFNIT1VMRCwgYXMg Y2FwdHVyZWQgaW4gdGhpcyBpc3N1ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0OzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9kb3Rz d2cvZG90cy1yZXF1aXJlbWVudHMvaXNzdWVzLzU3Ij5odHRwczovL2dpdGh1Yi5jb20vZG90c3dn L2RvdHMtcmVxdWlyZW1lbnRzL2lzc3Vlcy81NzwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHdlIG5lZWQgdG8gcmVjYXN0IHRo ZSByZXF1aXJlbWVudCB0byBjYXB0dXJlIHRoZSBwZWFjZS10aW1lIGFzcGVjdD8gRm9yIGV4YW1w bGUsIHNob3VsZCBhIERPVFMgc2VydmVyIGJlIGFibGUgdG8gdGVsbCBhIGNsaWVudCB0byBzdG9w IGhlYXJ0YmVhdHMsIG9yIHNsb3cgdGhlIGhlYXJ0YmVhdCByYXRlPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmRyZXc8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpPbiAxMC8yNi8xNyA5 OjEzIEFNLCBEYXZlIERvbHNvbiB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBwdXNoaW5nIGZvciB0aGlzLiBJIHNhdyB0aGUg d29ya2luZyBncm91cCBzdHJ1Z2dsaW5nIHdpdGggdGhlIGZpcmV3YWxsL05BVCBwcm9ibGVtLCBh bmQgb2ZmZXJlZCBhIGRpZmZlcmVudCB3YXkgb2YgdGhpbmtpbmcgYWJvdXQgaXQuPGJyPg0KVG8g YmUgY2xlYXIsIG15IHN1Z2dlc3Rpb24gaXMgdG8gcmVtb3ZlIHVuc29saWNpdGVkIG1lc3NhZ2Vz IGZyb20gdGhlIHNlcnZlciB0byBjbGllbnQuPGJyPg0KPGJyPg0KLURhdmU8YnI+DQo8YnI+DQo8 YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPC9hPiBbPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPl08YnI+DQpTZW50OiBUaHVyc2Rh eSwgT2N0b2JlciAyNiwgMjAxNyAzOjA2IFBNPGJyPg0KVG86IERhdmUgRG9sc29uOyBLb25kYSwg VGlydW1hbGVzd2FyIFJlZGR5OyBGbGVtbWluZyBBbmRyZWFzZW47IEpvbiBTaGFsbG93OyA8YSBo cmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+DQpkb3RzQGlldGYub3JnPC9hPjxicj4NClN1Ympl Y3Q6IFJFOiBbRG90c10gRE9UUyAmYW1wOyBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMg cmV2aWV3ICgtMDYpKTxicj4NCjxicj4NClJlLSw8YnI+DQo8YnI+DQpOb3Qgc3VyZSBob3cgdG8g Z2V0IHJpZCBvZiB0aGUgY29uc3RyYWludCBpbXBvc2VkIGJ5IHRoZSBOQVQvRlcgdGltZXIsIERh dmUuPGJyPg0KPGJyPg0KVGhlIGN1cnJlbnQgdGV4dCBzYXlzIHRoZSBmb2xsb3dpbmc6PGJyPg0K PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VG8gcHJvdmlkZSBhIG1ldHJpYyBvZiBzaWduYWwgaGVh bHRoIGFuZCBkaXN0aW5ndWlzaCBhbiAnaWRsZScgc2lnbmFsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Y2hhbm5lbCBmcm9tIGEgJ2Rpc2Nvbm5lY3RlZCcgb3IgJ2RlZnVuY3QnIHNlc3Npb24sIHRo ZSBET1RTIGFnZW50PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7c2VuZHMgYSBoZWFydGJlYXQgb3Zl ciB0aGUgc2lnbmFsIGNoYW5uZWwgdG8gbWFpbnRhaW4gaXRzIGhhbGYgb2YgdGhlPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Y2hhbm5lbC4gJm5ic3A7VGhlIERPVFMgYWdlbnQgc2ltaWxhcmx5IGV4 cGVjdHMgYSBoZWFydGJlYXQgZnJvbSBpdHMgcGVlcjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0RP VFMgYWdlbnQsIGFuZCBtYXkgY29uc2lkZXIgYSBzZXNzaW9uIHRlcm1pbmF0ZWQgaW4gdGhlIGV4 dGVuZGVkPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7YWJzZW5jZSBvZiBhIHBlZXIgYWdlbnQgaGVh cnRiZWF0Ljxicj4NCjxicj4NCldoaWNoIGNvdmVycyB5b3VyIHByb3Bvc2FsLiBObz88YnI+DQo8 YnI+DQpTb2xpY2l0ZWQgbWVzc2FnZXMgZnJvbSB0aGUgc2VydmVyIGRvIG5vdCBwcmV2ZW50IGZy b20gZmFpbHVyZXMuIENvbnNpZGVyIHRoZSBjYXNlIHdoZXJlIGEgRE9UUyBzZXJ2ZXIgaGFzIHRv IHNlbmQgYSBtaXRpZ2F0aW9uIHN0YXR1cyB1cGRhdGUgYmFjayB0byB0aGUgY2xpZW50LCBidXQg dGhlIGNsaWVudCBkaWRuJ3QgcmVmcmVzaGVkIHRoZSBzdGF0ZS4gT3Igd2hlbiB0aGUgTkFUIGZp cmVkIG91dCBhIG1hcHBpbmcgYW5kIGFzc2lnbnMgdGhlDQogZXh0ZXJuYWwgcG9ydCB0byBhbm90 aGVyIGhvc3QgdGhhbiB0aGUgRE9UUyBjbGllbnQuPGJyPg0KPGJyPg0KRGlkIEkgbWlzc2VkIHNv bWV0aGluZz88YnI+DQo8YnI+DQpUaGFuayB5b3UuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCk1l ZDxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQpEZSZuYnNwOzogRGF2ZSBEb2xzb24g WzxhIGhyZWY9Im1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSI+bWFpbHRvOmRkb2xzb25Ac2Fu ZHZpbmUuY29tPC9hPl0gRW52b3nDqSZuYnNwOzogamV1ZGkgMjY8YnI+DQpvY3RvYnJlIDIwMTcg MTQ6NTAgw4AmbmJzcDs6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEtvbmRhLCBUaXJ1bWFs ZXN3YXI8YnI+DQpSZWRkeTsgRmxlbW1pbmcgQW5kcmVhc2VuOyBKb24gU2hhbGxvdzsgPGEgaHJl Zj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+IE9iamV0Jm5ic3A7OiBS ZTo8YnI+DQpbRG90c10gRE9UUyAmYW1wOyBOQVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMg cmV2aWV3ICgtMDYpKTxicj4NCjxicj4NCk15IHBvaW50IHdhcyB0aGF0IGlmIHNlcnZlciBzdGF0 dXMgd2FzIHNvbGljaXRlZCwga2VlcC1hbGl2ZSBpbnRlcnZhbDxicj4NCndvdWxkIGJlIGluZGVw ZW5kZW50IG9mIGZpcmV3YWxsL05BVCB0aW1lb3V0LiBLZWVwLWFsaXZlcyB3b3VsZCBiZTxicj4N Cm9wdGlvbmFsLjxicj4NCjxicj4NClNvbGljaXRlZCBtZWFucyB0aGF0IGNsaWVudCBzYXlzICZx dW90O2dldCBzdGF0dXMmcXVvdDsgdnMuIHRoZSBzZXJ2ZXIganVzdDxicj4NCnNlbmRpbmcgdXBk YXRlcy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpEYXZpZCBEb2xzb248YnI+DQpTYW5kdmluZTxi cj4NCiZuYnNwOyZuYnNwO09yaWdpbmFsIE1lc3NhZ2U8YnI+DQpGcm9tOiA8YSBocmVmPSJtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTwvYT48YnI+DQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNiwgMjAxNyAyOjExIFBNPGJy Pg0KVG86IERhdmUgRG9sc29uOyBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5OyBGbGVtbWluZyBB bmRyZWFzZW47IEpvbjxicj4NClNoYWxsb3c7IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3Jn Ij5kb3RzQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJFOiBbRG90c10gRE9UUyAmYW1wOyBO QVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3PGJyPg0KKC0wNikpPGJyPg0KPGJy Pg0KPGJyPg0KSGkgRGF2ZSw8YnI+DQo8YnI+DQpUaGUgcHJvdG9jb2wgZG9lcyBhbHJlYWR5IHN1 cHBvcnQgYSBtZWNoYW5pc20gdG8gc2VuZCBrZWVwYWxpdmU8YnI+DQptZXNzYWdlcyBldmVyeSAz MHMgKHJlY29tbWVuZGVkIHZhbHVlKS48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KTWVkPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4NCkRlIDogRGF2ZSBEb2xzb24gWzxhIGhyZWY9Im1h aWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSI+bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPC9h Pl0gRW52b3nDqSA6IGpldWRpIDI2PGJyPg0Kb2N0b2JyZSAyMDE3IDEzOjE1IMOAIDogS29uZGEs IFRpcnVtYWxlc3dhciBSZWRkeTsgQk9VQ0FEQUlSIE1vaGFtZWQ8YnI+DQpJTVQvT0xOOyBGbGVt bWluZyBBbmRyZWFzZW47IEpvbiBTaGFsbG93OyA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9y ZyI+ZG90c0BpZXRmLm9yZzwvYT4gT2JqZXQgOiBSRTo8YnI+DQpbRG90c10gRE9UUyAmYW1wOyBO QVQgKHdhcyBSRTogRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpKTxicj4NCjxicj4NCkkg dGhpbmsgdGhlcmUgaXMgYW5vdGhlciBvcHRpb24gdG8gaGFuZGxlIHRoZSBOQVQvZmlyZXdhbGwg cHJvYmxlbXM8YnI+DQpieSBjaGFuZ2luZyB0aGUgcHJvdG9jb2wuPGJyPg0KPGJyPg0KSWYgSSB1 bmRlcnN0YW5kIGNvcnJlY3RseSwgY3VycmVudGx5IHRoZSBOQVQgYW5kIGZpcmV3YWxsIG5lZWQg dG8gYmU8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmtlcHQ8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ b3BlbiB0byBwZXJtaXQgdW5zb2xpY2l0ZWQgc2VydmVyIHBhY2tldHMuPGJyPg0KPGJyPg0KSWYg dGhlIHByb3RvY29sIGlzIGNoYW5nZWQgdG8gcmVxdWlyZSBjbGllbnQgcG9sbGluZyBvZiB0aGUg c2VydmVyPGJyPg0KdXBkYXRlcywgdGhlIE5BVCBhbmQgZmlyZXdhbGwgcHJvYmxlbXMgZ28gYXdh eS48YnI+DQo8YnI+DQotRGF2ZTxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KRnJvbTogRG90cyBbPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRm Lm9yZyI+bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBLb25k YSw8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRp cnVtYWxlc3dhcjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWRkeTxicj4NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDEyOjU4IFBN PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5t b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgRmxlbW1pbmcgQW5kcmVhc2VuOyBKb24g U2hhbGxvdzs8YnI+DQo8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9y ZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW0RvdHNdIERPVFMgJmFtcDsgTkFUICh3YXMgUkU6IERP VFMgUmVxdWlyZW1lbnRzIHJldmlldzxicj4NCigtMDYpKTxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCls8YSBocmVmPSJtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208L2E+XTxicj4NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDI6 MjEgUE08YnI+DQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTxicj4NCiZsdDs8YSBocmVm PSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+VGlydW1hbGVzd2Fy UmVkZHlfS29uZGFATWNBZmVlLmNvbTwvYT4mZ3Q7Ozxicj4NCkZsZW1taW5nIEFuZHJlYXNlbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbSI+ZmFuZHJlYXNAY2lzY28uY29t PC9hPiZndDs7IEpvbiBTaGFsbG93ICZsdDtzdXBqcHMtPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmll dGZAanBzaGFsbG93LmNvbSI+aWV0ZkBqcHNoYWxsb3cuY29tPC9hPiZndDs7IDxhIGhyZWY9Im1h aWx0bzpkb3RzQGlldGYub3JnIj4NCmRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUkU6 IFtEb3RzXSBET1RTICZhbXA7IE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXc8 YnI+DQooLTA2KSk8YnI+DQo8YnI+DQpSZS0sPGJyPg0KPGJyPg0KSSBoZWFyIHlvdS4gTXkgdGFr ZSBpcyB0aGF0IHdlIGRvbid0IG5lZWQgdG8gcmVjb21tZW5kIHdoaWNoPGJyPg0KY29tcGFuaW9u ICZxdW90O3Byb3RvY29scy9tZWNoYW5pc21zJnF1b3Q7IG5lZWQgdG8gYmUgc3VwcG9ydGVkIGZv ciBOQVQvRlc8YnI+DQp0cmF2ZXJzYWwgcHVycG9zZXMuIEhhdmluZyBhIGRpc2N1c3Npb24gYXQg dGhlIHNhbWUgbGV2ZWwgaW4gODA4NTxicj4NCndvdWxkIGJlIHN1ZmZpY2llbnQsIElNSE8uPGJy Pg0KPGJyPg0KTGV0J3MgZm9jdXMgb24gdGhlIHNpbXBsZSBidWlsdC1pbiBmZWF0dXJlIGZvciBO QVQgZGV0ZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBkb24ndCB0aGluayB0aGUgc2ltcGxlIGJ1aWx0LWluIGZlYXR1cmUgaXMgc3VmZmlj aWVudCwgRE9UUyBjbGllbnQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPndpbGw8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+aGF2ZSB0byByZWx5IG9uIG1lY2hhbmlzbXMgZGlzY3Vzc2VkIGluIDgwODUg Zm9yIGJvdGggZmlyZXdhbGwgYW5kPGJyPg0KTkFUIHRyYXZlcnNhbC48YnI+DQo8YnI+DQotVGly dTxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5DaGVlcnMsPGJyPg0KTWVkPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4NCkRlIDog S29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTxicj4NCls8YSBocmVmPSJtYWlsdG86VGlydW1hbGVz d2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRh QE1jQWZlZS5jb208L2E+XTxicj4NCkVudm95w6kgOiBqZXVkaSAyNiBvY3RvYnJlIDIwMTcgMTA6 MzYgw4AgOiBCT1VDQURBSVIgTW9oYW1lZDxicj4NCklNVC9PTE47IEZsZW1taW5nIEFuZHJlYXNl bjsgSm9uIFNoYWxsb3c7IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYu b3JnPC9hPiBPYmpldCA6PGJyPg0KUkU6IFtEb3RzXSBET1RTICZhbXA7IE5BVCAod2FzIFJFOiBE T1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpPGJyPg0KPGJyPg0KQnV0IE5BVHMgYXJlIG5v dCB0aGUgb25seSBwcm9ibGVtLCBmaXJld2FsbHMgd2lsbCBhbHNvIGJlIG1vc3Q8YnI+DQpsaWtl bHkgcHJlc2VudCwgYW5kIFNUVU4gaGVscHMgZGlzY292ZXIgYm90aCBOQVRzIGFuZCBmaXJld2Fs bHM8YnI+DQphbmQgdXNlZnVsIGV2ZW4gaW4gSVB2NiBuZXR3b3JrcyB0byBkZXRlcm1pbmUgdGhl IGtlZXBhbGl2ZTxicj4NCmludGVydmFsIG9mPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5maXJld2FsbC48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tVGlydTxicj4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4N Cls8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+XTxicj4NClNlbnQ6IFRodXJzZGF5LCBPY3Rv YmVyIDI2LCAyMDE3IDE6NTIgUE08YnI+DQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmx0OzxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0Fm ZWUuY29tIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDs7PGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmxlbW1pbmcg QW5kcmVhc2VuICZsdDs8YSBocmVmPSJtYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tIj5mYW5kcmVh c0BjaXNjby5jb208L2E+Jmd0OzsgSm9uIFNoYWxsb3cgJmx0O3N1cGpwcy08YnI+DQo8YSBocmVm PSJtYWlsdG86aWV0ZkBqcHNoYWxsb3cuY29tIj5pZXRmQGpwc2hhbGxvdy5jb208L2E+Jmd0Ozsg PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPg0KZG90c0BpZXRmLm9yZzwvYT48YnI+DQpT dWJqZWN0OiBSRTogW0RvdHNdIERPVFMgJmFtcDsgTkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1l bnRzPGJyPg0KcmV2aWV3PGJyPg0KKC0wNikpPGJyPg0KPGJyPg0KVGlydSw8YnI+DQo8YnI+DQpZ ZXMsIFNUVU4gY2FuIGJlIGxpc3RlZCBhcyBwYXJ0IG9mIHRoZSBleGlzdGluZyB0b29scyBib3g8 YnI+DQooYW1vbmcgdGhlPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5saW5lcyBvZjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj53aGF0IGlzIGFscmVhZHkgZGlzY3Vzc2VkIGluIDgwODUpLjxicj4NCjxi cj4NCkkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBtYWtlcyBzZW5zZSB0byByZXF1aXJlIFNUVU4gc3Vw cG9ydCBieTxicj4NCkRPVFM8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmNsaWVudHMuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBwcm9wb3NhbCBpcyB0byBpbmNsdWRlIGEgc2ltcGxlIGJ1aWx0 LWluIGZlYXR1cmUgaW4gdGhlPGJyPg0KRE9UUzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cHJvdG9jb2wgaXRzZWxmPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYXQgY2FuIGhlbHAgdG8gZGV0ZWN0 IE5BVHMuIFRoZSBzdXBwb3J0IG9mIHN1Y2ggZmVhdHVyZTxicj4NCndpbGwsIGUuZy4sPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5lYXNlPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRyb3VibGVzaG9v dGluZyB3aGVuIGNvbm5lY3Rpdml0eSBwcm9ibGVtcyBhcmUgZXhwZXJpZW5jZWQgb248YnI+DQp0 aGUgcGF0aCBiZXR3ZWVuIGEgY2xpZW50IGFuZCBhIHNlcnZlci48YnI+DQo8YnI+DQpDaGVlcnMs PGJyPg0KTWVkPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4NCkRlIDogS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeTxicj4NCls8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlf S29uZGFATWNBZmVlLmNvbSI+bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5j b208L2E+XTxicj4NCkVudm95w6kgOiBqZXVkaSAyNiBvY3RvYnJlIDIwMTcgMDk6NDQgw4AgOiBC T1VDQURBSVIgTW9oYW1lZDxicj4NCklNVC9PTE47IEZsZW1taW5nIEFuZHJlYXNlbjsgSm9uIFNo YWxsb3c7IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPiBP YmpldCA6PGJyPg0KUkU6IFtEb3RzXSBET1RTICZhbXA7IE5BVCAod2FzIFJFOiBET1RTIFJlcXVp cmVtZW50cyByZXZpZXc8YnI+DQooLTA2KSk8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQpGcm9tOiBEb3RzIFs8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5tYWls dG86ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mPGJyPg0KPGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208L2E+PGJyPg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyNCwgMjAxNyAyOjIwIFBN PGJyPg0KVG86IEZsZW1taW5nIEFuZHJlYXNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhbmRyZWFz QGNpc2NvLmNvbSI+ZmFuZHJlYXNAY2lzY28uY29tPC9hPiZndDs7IEpvbiBTaGFsbG93PGJyPg0K Jmx0O3N1cGpwcy0gPGEgaHJlZj0ibWFpbHRvOmlldGZAanBzaGFsbG93LmNvbSI+aWV0ZkBqcHNo YWxsb3cuY29tPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj4NCmRvdHNA aWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RTICZhbXA7IE5BVCAod2Fz IFJFOiBET1RTIFJlcXVpcmVtZW50czxicj4NCnJldmlldzxicj4NCigtMDYpKTxicj4NCjxicj4N CkhpIEZsZW1taW5nLCBhbGwsPGJyPg0KPGJyPg0KUGxlYXNlIHNlZSBpbmxpbmUuPGJyPg0KPGJy Pg0KQ2hlZXJzLDxicj4NCk1lZDxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0gRGUgOiBGbGVt bWluZyBBbmRyZWFzZW48YnI+DQpbPGEgaHJlZj0ibWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbSI+ bWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbTwvYT5dIEVudm95w6kgOjxicj4NCmx1bmRpPGJyPg0K MjMgb2N0b2JyZSAyMDE3IDE3OjM2IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgSm9u PGJyPg0KU2hhbGxvdzsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5v cmc8L2E+IE9iamV0IDogUmU6IERPVFMgJmFtcDsgTkFUICh3YXMgUkU6PGJyPg0KW0RvdHNdIERP VFMgUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KSk8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiAx MC8yMy8xNyA4OjI4IEFNLCA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4gd3JvdGU6PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEpvbiwgYWxsLDxicj4N Cjxicj4NCkkgYWdyZWUgd2l0aCBGbGVtbWluZyB0aGF0ICZxdW90O3NvbWUgbW9yZSB3b3JrJnF1 b3Q7IGlzIG5lZWRlZC48YnI+DQpJTUhPLCB0aGlzIGlzIGE8bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnR5cGljYWwgZGlzY3Vzc2lvbiB0byBpbmNs dWRlIGluIGEgZGVkaWNhdGVkIHNlY3Rpb24gaW48YnI+DQp0aGUgRE9UUyBhcmNoaXRlY3R1cmUg SS1ELjxicj4NCkFncmVlZC48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0O0Zyb20gYSByZXF1aXJlbWVudCBzdGFuZHBvaW50LCB3ZSBkb24ndCBu ZWVkIHRvIDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5lbGFib3JhdGUgaG93IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cHJvdG9jb2xzIHdpbGwgZnVsZmlsIGl0LiBT SUctMTAgZG9lcyBldmVuIGEgbmljZSBqb2IgYnk8YnI+DQpjaXRpbmc8YnI+DQpSRkM4MDg1IHdo aWNoIHBvaW50cyB0byBOQVQgdHJhdmVyc2FsIG1lY2hhbmlzbXMuIE9uZTxicj4NCmNvdWxkIHBp Y2sgaGlzL2hlciBmYXZvcml0ZSBwcm90b2NvbCBmcm9tIHRoZSBsaXN0IGluPGJyPg0KODA4NSB0 byBkaXNjb3ZlciB0aGUgZXh0ZXJuYWwgSVAgYWRkcmVzcy9wcmVmaXgsIGlmPGJyPg0KbmVlZGVk LiBFeHRlcm5hbCBJUCBhZGRyZXNzZXMvcHJlZml4ZXMgY2FuIGJlIElQdjQgZm9yIGE8YnI+DQpO QVQ0NCBvciBOQVQ2NCwgYnV0IGNhbiBiZTxicj4NCklQdjYgcHJlZml4ZXMgZm9yIGVudGVycHJp c2VzIGRlcGxveWluZyBOUFR2NiwgYW5kIHNvIG9uLjxicj4NClBhcnQgb2YgdGhlIGNoYWxsZW5n ZSBoZXJlIGlzIHRoYXQgdGhlIGF0dGFjayB0YXJnZXQgYW5kPGJyPg0KdGhlIERPVFMgY2xpZW50 IGFyZSBub3QgbmVjZXNzYXJpbHkgb25lIGFuZCB0aGUgc2FtZSw8YnI+DQp3aGljaCBtYWtlcyBp dCBtb3JlIGRpZmZpY3VsdCB0byBkZXRlcm1pbmUgdGhlPGJyPg0KcHVibGljLWZhY2luZyBJUC1h ZGRyZXNzL3BvcnQgdW5kZXIgYXR0YWNrIChhdCBsZWFzdCBpZjxicj4NCnRoZSBET1RTIGNsaWVu dCBpcyBnb2luZyB0bzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+ZG8gaXQpLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5bTWVkXSBUaGlzIGlzIGV4YWN0bHkgdGhlIGtpbmQgb2YgdGhl IGRpc2N1c3Npb24gdG8gaGF2ZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIG9yIHdpdGhvdXQgTkFULCBET1RTIGNs aWVudHMgYXJlIGFzc3VtZWQgdG8gYmUgZmVkPGJyPg0Kd2l0aCB0aGU8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmludGVybmFsPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRhcmdldChzKS4gVGhpcyBj YW4gYmUgYWNoaWV2ZWQgYnkgcHJvdmlzaW9uaW5nIChsaWtlbHkpPGJyPg0Kb3IgYnkgZGlzY292 ZXJ5PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5t ZWFuczxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4o ZS5nLiwgcmVzaWRlbnRpYWwgb3Igc21hbGwgZW50ZXJwcmlzZSBuZXR3b3JrcykuPGJyPg0KPGJy Pg0KQ2FuIHdlIGFzc3VtZSB0aGF0IHRoZSBkaXNjb3Zlcnkgb2YgdGhlIGV4dGVybmFsIElQPGJy Pg0KYWRkcmVzcy9wcmVmaXgvLi4gaXM8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmRvbmU8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+YnkgYSBET1RTIGNsaWVudCBvbmx5IGlmIGl0IGlzIGV4cGxpY2l0 bHkgaW5zdHJ1Y3RlZCB0byBkbyBzbz88YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBzb21lIGRlcGxveW1lbnRzLCBET1RT IGNsaWVudHMgbWF5IGJlIHByb3Zpc2lvbmVkPGJyPg0Kd2l0aCB0aGUgc2V0IG9mPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbnRlcm5hbCByZXNv dXJjZXMsIHNvIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGRpc2NvdmVyeS48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgYXMgSm9uIG1lbnRpb25l ZCwgRE9UUyBnYXRld2F5cyBjYW4gYmUgb2YgaGVscDxicj4NCnRvIHNldCB0aGU8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFwcHJvcHJpYXRlIElQ IGFkZHJlc3Nlcy9wcmVmaXhlcy9wb3J0IG51bWJlcnMgaW4gdGhlPGJyPg0KcHJlc2VuY2Ugb2Yg dHJhbnNsYXRvcnMuPGJyPg0KQWdyZWVkIC0gYnV0IHRoZXkgc3RpbGwgbmVlZCBhIHdheSB0byBm aWd1cmUgb3V0IHRoZTxicj4NCnByaXZhdGUvcHVibGljIG1hcHBpbmcgZm9yIGEgZ2l2ZW4gYXR0 YWNrIHRhcmdldC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPltNZWRdIEJlY2F1c2UgYSBERG9TIGF0dGFjayBpcyBvYnNlcnZlZCBmcm9tIHRoZSBp bnRlcm5hbDxicj4NCm5ldHdvcmssPGJyPg0KbWFwcGluZyhzKSBhcmUgbmVjZXNzYXJpbHkgbWFp bnRhaW5lZCBieSB0aGUgb24tcGF0aDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+dHJhbnNsYXRvcihzKS48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdGhlcndpc2UsIHRoZSBpbmNv bWluZyBhdHRhY2sgdHJhZmZpYyBjb3VsZG4ndCBiZTxicj4NCmZvcndhcmRlZCB0byBpbnRlcm5h bDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aG9z dHMuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgbW9kZWwgYXNzdW1lcyB0aGF0IHRoZSBnYXRld2F5IGlzIGNvbGxvY2F0ZWQgd2l0aCB0aGU8 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk5BVC48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCB0aGUgZ2F0ZXdheSBjYW4gcmVwbGFjZSB0aGUgaW50 ZXJuYWwgSVAgYWRkcmVzcy9wcmVmaXg8YnI+DQp3aXRoIHRoZSBvbmU8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJldHJpZXZlczxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mcm9tIHRoZSBOQVQgbWFw cGluZyB0YWJsZS48YnI+DQo8YnI+DQpEbyB5b3Ugc2VlIGFueSBpc3N1ZSB3aXRoIHRoaXMgc2No ZW1lPzxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFuIG9wZW4gcXVlc3Rpb24gdGhvdWdoIHdvdWxkIGJlIHRvIGRpc2N1c3MgaWYgdGhl cmU8YnI+DQppcyBhIHZhbHVlIGluPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5oYXZpbmcgYSBmZWF0dXJlIGluIHRoZSBET1RTIHByb3RvY29sIHRv IGluZm9ybSBhIERPVFM8YnI+DQpjbGllbnQgdGhhdCBhIE5BVCBpcyBkZXRlY3RlZCBvbi1wYXRo LiBUaGlzIGNhbiBiZTxicj4NCnByZXNlbnRlZCBhcyBhbiBpbmZvcm1hdGlvbiBlbGVtZW50IHJl dHVybmVkIGJ5IHRoZTxicj4NCnNlcnZlciB0byB0aGUgY2xpZW50LiBUaGlzIGluZm9ybWF0aW9u IGNhbiBiZSwgZm9yPGJyPg0KZXhhbXBsZSwgdXNlZCBieSB0aGUgY2xpZW50IHRvIGFkanVzdCBp dHMgSFQgaW50ZXJ2YWwsPGJyPg0KYWRqdXN0IHRoZSBpbnRlcm5hbCBJUCBhZGRyZXNzZXMvcHJl Zml4ZXMgdG8gYmU8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnByb3RlY3RlZCwgZXRjLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PcGluaW9ucz88YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc291bmRzIGFwcGVhbGluZywgYnV0IGl0 J3MgdmVyeSBkaWZmaWN1bHQgdG8gZG8gdGhpczxicj4NCnJlbGlhYmx5LCBhbmQgaXQncyBub3Qg anVzdCBOQVRzIHRoYXQgYXJlIGFuIGlzc3VlIGhlcmU7PGJyPg0KRmlyZXdhbGxzIHByZXNlbnQg c2ltaWxhciBjaGFsbGVuZ2VzIChhbmQgdGhleSBtYXkgb3I8YnI+DQptYXkgbm90IGJlIE5BVCdp bmcgaW5kaXZpZHVhbDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Zmxvd3MpLjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltNZWRdIEkgZnVsbHkg YWdyZWUgdGhhdCBmaXJld2FsbHMgZGV0ZWN0IGlzIG1vcmUgY29tcGxleC48YnI+DQpMZXQncyBw dXQgaXQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmFzaWRlPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmFuZCBmb2N1cyBvbiB0aGUgTkFUIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJlc2VuY2UgYW5kIGJlaGF2aW9yIG9mIE5BVCBh bmQgRmlyZXdhbGwsIGFuZCBrZWVwYWxpdmU8YnI+DQppbnRlcnZhbCBjYW4gYmUgZGV0ZXJtaW5l ZCB1c2luZyBTVFVOIChkaXNjdXNzZWQgaW48YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNTc4MCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3ODA8 L2E+KS48YnI+DQo8YnI+DQotVGlydTxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjYW4gY29uc2lkZXIgbWFueSBhcHByb2FjaGVzIHRv IGRldGVjdCBhIE5BVCwgZS5nLiw8YnI+DQo8YnI+DQooMSkgVGhlIERPVFMgY2xpZW50IGluc2Vy dHMgaW4gdGhlIGNvcmUgbWVzc2FnZSB0aGUgSVA8YnI+DQphZGRyZXNzL3BvcnQgaXQ8bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnVzZXMgdG88YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VuZCB0aGUg cmVxdWVzdCB0byB0aGUgRE9UUyBzZXJ2ZXIuIFVwb24gcmVjZWlwdCBvZiB0aGU8YnI+DQpyZXF1 ZXN0IGJ5IHRoZSBET1RTIHNlcnZlciwgaXQgY2hlY2tzIGlmIHRoZSBlbmNsb3NlZCBJUDxicj4N CmFkZHJlc3MvcG9ydCBtYXRjaCB0aGUgc291cmNlPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JUDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hZGRyZXNzL3BvcnQgb2YgdGhlIHJlY2VpdmVkIHBhY2tl dC4gSWYgeWVzLCB0aGUgc2VydmVyPGJyPg0Kc2V0cyBpbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlc3BvbnNlIGE8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGVkaWNhdGVkIHBhcmFtZXRl ciB0byBpbmRpY2F0ZSB0aGF0IGEgdHJhbnNsYXRvciBpczxicj4NCmRldGVjdGVkPGJyPg0Kb24t PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wYXRoLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KDIpIFRoZSBET1RTIHNlcnZlciBpbnNlcnRz IHN5c3RlbWF0aWNhbGx5IHRoZSBzb3VyY2UgSVA8YnI+DQphZGRyZXNzL3BvcnQgaW48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmE8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVzcG9uc2UgdG8gYSBt ZXNzYWdlIGZyb20gYSBET1RTIGNsaWVudC4gVXBvbiByZWNlaXB0IG9mPGJyPg0KdGhhdCByZXNw b25zZSwgdGhlIERPVFMgY2xpZW50IGNvbXBhcmVzIHRoZSBlbmNsb3NlZDxicj4NCmFkZHJlc3Mv cG9ydCB3aXRoIHRoZSBvbmVzIGl0IHVzZWQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnNlbmQgdGhlIHJlcXVlc3QgdG8gZGV0ZWN0IGFueSBtaXNtYXRj aC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LS0gRmxlbW1pbmc8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxicj4NCk1lZDxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS0gRGUgOiBEb3RzPGJyPg0KWzxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBEZSBsYSBwYXJ0 IGRlIEpvbjxicj4NClNoYWxsb3cgRW52b3nDqSA6IGx1bmRpIDIzIG9jdG9icmUgMjAxNyAxMzox OCDDgCA6PGJyPg0KJ0ZsZW1taW5nIEFuZHJlYXNlbic7IDxhIGhyZWY9Im1haWx0bzpkb3RzQGll dGYub3JnIj5kb3RzQGlldGYub3JnPC9hPiBPYmpldCA6IFJlOjxicj4NCltEb3RzXSBET1RTIFJl cXVpcmVtZW50cyByZXZpZXcgKC0wNik8YnI+DQo8YnI+DQpIaSBGbGVtbWluZyw8YnI+DQo8YnI+ DQpUaGUgd2F5IG15IG1pbmQgd29ya3MgaXMgdG8gdGhpbmsgb2YgYSBwcmFjdGljYWw8YnI+DQpz aXR1YXRpb24gYW5kIHNlZSBpZiB0aGluZ3MgZml0Ljxicj4NCjxicj4NCkFzIEkgcmVhZCBTSUct MDEwLCB0aGVyZSBjb3VsZCBiZSBhIERPVFMgY2xpZW50IHdpdGg8YnI+DQphIG1hbmFnZW1lbnQg SVAgYWRkcmVzcyB0aGF0IGlzIFJGQzE5MTggLSB0aGlzIGNsaWVudDxicj4NCmNvdWxkIGJlIG1v bml0b3JpbmcgTmV0ZmxvdyBpbmZvcm1hdGlvbiBhbmQgY2FuPGJyPg0KcmVxdWVzdCBtaXRpZ2F0 aW9uIGZvciB0aGUgYXBwcm9wcmlhdGUgcHVibGljIElQczxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhdDxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFyZSBiZWluZyBt b25pdG9yZWQuICZuYnNwO1NvIFNJRy0wMTAgaXMgbmVlZGVkIGZvciB0aGlzPGJyPg0KdXNlPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jYXNlLjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 IGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgRE9UUyBzZXJ2ZXIgYXMgdG88YnI+DQp3aGV0 aGVyIGl0IGFjY2VwdHMgYSBtaXRpZ2F0aW9uIHJlcXVlc3QgZm9yIGE8YnI+DQpwYXJ0aWN1bGFy IHRhcmdldCBpcCAob3IgZG9tYWluPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ldGMuKSBvcjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ub3QuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JZiB0aGVyZSBpcyBnb2luZyB0byBiZSBhIE5BVCBib3JkZXIgd2hlcmUgcHVi bGljIElQczxicj4NCmFyZSBtYXBwZWQgaW50byBwcml2YXRlIElQcyAoYW5kIHZpY2UgdmVyc2Ep LCBJIHdvdWxkPGJyPg0KdGhlbiBleHBlY3QgdGhlcmUgdG8gYmUgYSBET1RTIGdhdGV3YXkgYmV0 d2VlbiB0aGVzZTxicj4NCjIgem9uZXMsIGFuZCBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2Yg dGhlIERPVFM8YnI+DQpnYXRld2F5IHRvIGRvIGFueSB0YXJnZXQtaXA8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1h cHBpbmdzLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UmVnYXJkczxicj4NCjxicj4NCkpvbjxicj4NCjxicj4NCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogRG90cyBbPGEgaHJlZj0ibWFpbHRvOmlldGYtc3Vw anBzLWRvdHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmlldGYtc3VwanBzLWRvdHMtYm91bmNl c0BpZXRmLm9yZzwvYT5dPGJyPg0KT24gQmVoYWxmIE9mIEZsZW1taW5nIEFuZHJlYXNlbjxicj4N ClNlbnQ6IDIyIE9jdG9iZXIgMjAxNyAyMDoxNzxicj4NClRvOiBkb3RzOyA8YSBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50c0BpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1kb3Rz LXJlcXVpcmVtZW50c0BpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBbRG90c10gRE9UUyBSZXF1 aXJlbWVudHMgcmV2aWV3ICgtMDYpPGJyPg0KPGJyPg0KR3JlZXRpbmdzPGJyPg0KPGJyPg0KSSBo YXZlIHJldmlld2VkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgRE9UUzxicj4NCnJlcXVpcmVt ZW50cyBkcmFmdDxicj4NCig8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1p ZXRmLWRvdHMtcmVxdWlyZW1lbnRzIj5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRm LWRvdHMtcmVxdWlyZW1lbnRzPC9hPjxicj4NCi08bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjA2LnR4dCkuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmdlbmVyYWwsPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGlu ayB0aGUgZHJhZnQgaXMgaW4gZ29vZCBzaGFwZSB3aXRoIG9ubHkgYSBmZXc8YnI+DQplZGl0cyBy ZXF1aXJlZCwgc28gSSBob3BlIHdlIGNhbiBtb3ZlIHRvIFdHTEMgc29vbi4gSTxicj4NCmhhdmUg YSBmZXcgY29tbWVudHMgYmVsb3cgKG9mIHdoaWNoPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGU8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OQVQgb25lIGlzIHRoZSBv bmx5IHJlYWwgc3Vic3RhbnRpYWwgb25lKS4gSSBoYXZlPGJyPg0KYWxzbyBzdWJtaXR0ZWQgYSBw dWxsIHJlcXVlc3Qgd2l0aCBhIGZldyBuaXQgZml4ZXMgb24gR2l0SHViOjxicj4NCjxicj4NCjxi cj4NClNlY3Rpb24gMS4yPGJyPg0KLSBUaGUgZGVmaW5pdGlvbiBvZiAmcXVvdDtET1RTIFNpZ25h bCZxdW90OyBpcyBzbGlnaHRseTxicj4NCmluY29uc2lzdGVudCB3aXRoIHRoZSByZXNwZWN0aXZl ICZxdW90O0NsaWVudCBTaWduYWwmcXVvdDsgYW5kPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtTZXJ2ZXIgU2lnbmFsJnF1b3Q7IGRlZmluaXRpb25zLjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNJRy0wMDU6PGJyPg0KLSBOb3QgY2xlYXIgdGhhdCBhbHdheXMgcmVxdWlyaW5nICZx dW90O251bWJlciBvZiBwYWNrZXRzJnF1b3Q7PGJyPg0KbWV0cmljcyBpcyBtZWFuaW5nZnVsLiBD b25zaWRlciBUQ1AtYmFzZWQgYXR0YWNrcyBmb3I8YnI+DQpleGFtcGxlLiBOdW1iZXIgb2YgYnl0 ZXMgbWF5IGFsd2F5cyBiZSBvayAtIGFib3ZlIGFuZDxicj4NCmJleW9uZCB0aGF0IGl0IHNob3Vs ZCBwcm9iYWJseSBiZSBleHRlbnNpYmxlIGFuZC9vcjxicj4NCmF0dGFjazxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+ZGVwZW5kZW50Ljxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEkgZG9uJ3QgdGhpbmsgdGhlIHJlcXVp cmVtZW50cyBkb2N1bWVudCBzaG91bGQgZ2V0PGJyPg0KaW50byBzcGVjaWZ5aW5nPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij50aW1lcjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPnZhbHVlcyAtIGV4cG9udGlhbCBiYWNrb2ZmIHdpdGggc29tZSBtYXhpbXVtIHZhbHVlPGJy Pg0Kc2VlbXMgYWJvdXQgdGhlPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yaWdodDxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxldmVsIG9mIGRldGFpbCBoZXJlLjxicj4N Cjxicj4NClNJRy0wMDk6PGJyPg0KLSBUbyBiZSBjbGVhciwgdGhlIGNvbmZsaWN0cyBvbmx5IGFw cGx5IHdpdGhpbiBhPGJyPg0Kc2luZ2xlIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgcmlnaHQgPyBG b3IgZXhhbXBsZSwgaWY8YnI+DQphIGNsaWVudCB0ZWxscyB0aGUgc2FtZSBkb21haW4gdG8gYWx0 ZXJuYXRlbHkgdHVybjxicj4NCm9uL29mZiBtaXRpZ2F0aW9uIGZvciBhIGdpdmVuIHByZWZpeCwg cm91dGUgZmxhcHBpbmc8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1heTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9jY3VyLiBUaGUgc2FtZSBjb25jZXJuIGRvZXMgbm90 IGFwcGx5IGlmIGEgY2xpZW50PGJyPg0KdGVsbHMgdHdvIGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2 ZSBkb21haW5zIHRvPGJyPg0KcmVzcGVjdGl2ZSB0dXJuIG1pdGlnYXRpb24gb24gKGRvbWFpbiAx KSBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPm9mZjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPihkb21haW4gMikuIElmIHNvLCBjYW4gd2UgY2xhcmlmeSB0aGF0IChh bHNvIGluIGxpZXU8YnI+DQpvZiBzb21lIG9mIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bXVsdGktPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aG9taW5nIGNvbW1l bnRzIHJhaXNlZCBwcmV2aW91c2x5KSA/PGJyPg0KPGJyPg0KU0lHLTAxMDo8YnI+DQotIERPVFMg Q2xpZW50IGJlaGluZCBOQVQuIE9uIG9uZSBoYW5kLCBpdCBzZWVtczxicj4NCnJlYXNvbmFibGUg dG8gaGF2ZSB0aGlzIHJlcXVpcmVtZW50IHNpbmNlIGNsaWVudHMgZm9yPGJyPg0Kc3VyZSBjYW4g YmUgYmVoaW5kIE5BVHMsIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+d2l0aDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij50aGluZ3M8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmxpa2UgZHluYW1pYyBETlMsIHRoZXkgY2FuICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2NlcnRhaW5seSBiZSByZWFjaGFibGUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ib3dldmVyLDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmlmPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+d2U8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5kbzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPndhbnQgdG8gYWxsb3cgZm9yIHRoaXMgc2NlbmFyaW8sIGFuZCBpbiBwYXJ0 aWN1bGFyPGJyPg0KZm9yIHRoZSBET1RTIGNsaWVudDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG88YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5oYXZlIGEgcHJpdmF0ZSBJ UC1hZGRyZXNzIChwb3RlbnRpYWxseSBiZWhpbmQ8YnI+DQptdWx0aXBsZSBOQVRzKSwgdGhlbiB3 ZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+aGF2ZTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPm1vcmUgd29yayB0byBkbyBiZWNhdXNlIGl0IHdvbid0IGRvIHRoZSBET1RT IHNlcnZlcjxicj4NCmFueSBnb29kIHRvIGdldCBhIG1pdGlnYXRpb24gcmVxdWVzdCByZWZlcnJp bmcgdG88YnI+DQp0aGF0IHByaXZhdGUgSVAtYWRkcmVzcyAob3I8bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnByZWZpeCkuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoYW5rczxicj4NCjxicj4NCi0t IEZsZW1taW5nPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpEb3RzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpE b3RzQGlldGYub3JnIj5Eb3RzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kb3RzPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRG90cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyI+RG90c0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpEb3RzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpEb3RzQGll dGYub3JnIj5Eb3RzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG90cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kb3RzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpEb3RzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpEb3RzQGll dGYub3JnIj5Eb3RzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG90cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kb3RzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4u PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkRv dHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPkRvdHNA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kb3RzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_065D9BA7C7AAA94BA6F5BDB1A41269DD721DD2EEBRN1WNEXMBX01vc_-- From nobody Thu Oct 26 10:37:27 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669A913F421 for ; Thu, 26 Oct 2017 10:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P08--B2rx5UO for ; Thu, 26 Oct 2017 10:37:21 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4608913F403 for ; Thu, 26 Oct 2017 10:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=86377; q=dns/txt; s=iport; t=1509039441; x=1510249041; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=9OYsBNQyzHVWagowE7TexXmIIuvha1UL3LeIYWXNZsQ=; b=Fm196ocjaTmkqAE/LPHWf1a8Lm/sT62Q5vaOqgPtHUkJ+eNbLBpNN06s S61G77IZbEYyO9ySfqW6ZojPTjPmCbqpstRpXtjeeeHdZpiFdeG6RoBz/ qN2/PwhAySkpvYudW7lmTX0tMrfYo1SyfOGDlpodagl7XbmLXUaxf3Vn9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAABMHPJZ/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbieDeoofjxGBVCZ8jSuEdj6CZRCBfgMKGAEKhRgChEE/GAE?= =?us-ascii?q?CAQEBAQEBAWsohR0BAQEBAgEBARgBCEsLBQcECQIRAQMBAQEgAQYDAgInHwMGC?= =?us-ascii?q?AYNBgIBAReJeAUIEItanWeCJyaKTgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyo?= =?us-ascii?q?EgSpdgVCBaSkLgWlYNYRJJoMqgmEFmH2IfodlgReFJYZYghWFf4NeJIcViimLY?= =?us-ascii?q?YE5HziBaFUlFUmCZIJZAxyCAyU2jEYBAQE?= X-IronPort-AV: E=Sophos; i="5.44,301,1505779200"; d="scan'208,217"; a="22666870" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2017 17:37:19 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v9QHbIhi009571; Thu, 26 Oct 2017 17:37:18 GMT To: "Mortensen, Andrew" Cc: Dave Dolson , "mohamed.boucadair@orange.com" , "Konda, Tirumaleswar Reddy" , Jon Shallow , "dots@ietf.org" References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> From: Flemming Andreasen Message-ID: Date: Thu, 26 Oct 2017 13:37:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> Content-Type: multipart/alternative; boundary="------------3820AFCD83EC294B03B5BA90" Content-Language: en-US Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 17:37:25 -0000 This is a multi-part message in MIME format. --------------3820AFCD83EC294B03B5BA90 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/26/17 12:58 PM, Mortensen, Andrew wrote: > >> On Oct 26, 2017, at 9:46 AM, Flemming Andreasen > > wrote: >> >> As I have stated several times before, I'm not all that comfortable >> with the current requirement around always sending keep-alives, >> whether attacks are in progress or now. My concerns are around >> scalability/cost of the overall solution, so I think it's worth >> considering during peace-time at least. > > Hi Flemming. I suspect your concerns aren’t fully addressed by > reducing the heartbeat MUST to a SHOULD, as captured in this issue: > > > Thanks for capturing it in the issue, and you are right, I would still have concerns with a SHOULD requirement (but it would obviously be better than the current MUST). > Do we need to recast the requirement to capture the peace-time aspect? > For example, should a DOTS server be able to tell a client to stop > heartbeats, or slow the heartbeat rate? > That seems useful to me, however we may need to couple that with the client unilaterally increasing the rate when it's under attack to ensure bi-directional communication is still possible. Thanks -- Flemming > andrew > > >> >> On 10/26/17 9:13 AM, Dave Dolson wrote: >>> I'm not pushing for this. I saw the working group struggling with >>> the firewall/NAT problem, and offered a different way of thinking >>> about it. >>> To be clear, my suggestion is to remove unsolicited messages from >>> the server to client. >>> >>> -Dave >>> >>> >>> -----Original Message----- >>> From: mohamed.boucadair@orange.com >>> >>> [mailto:mohamed.boucadair@orange.com] >>> Sent: Thursday, October 26, 2017 3:06 PM >>> To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon >>> Shallow; dots@ietf.org >>> Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >>> >>> Re-, >>> >>> Not sure how to get rid of the constraint imposed by the NAT/FW >>> timer, Dave. >>> >>> The current text says the following: >>> >>>    To provide a metric of signal health and distinguish an 'idle' signal >>>    channel from a 'disconnected' or 'defunct' session, the DOTS agent >>>    sends a heartbeat over the signal channel to maintain its half of the >>>    channel.  The DOTS agent similarly expects a heartbeat from its peer >>>    DOTS agent, and may consider a session terminated in the extended >>>    absence of a peer agent heartbeat. >>> >>> Which covers your proposal. No? >>> >>> Solicited messages from the server do not prevent from failures. >>> Consider the case where a DOTS server has to send a mitigation >>> status update back to the client, but the client didn't refreshed >>> the state. Or when the NAT fired out a mapping and assigns the >>> external port to another host than the DOTS client. >>> >>> Did I missed something? >>> >>> Thank you. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Dave Dolson [mailto:ddolson@sandvine.com] Envoyé : jeudi 26 >>>> octobre 2017 14:50 À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar >>>> Reddy; Flemming Andreasen; Jon Shallow; dots@ietf.org >>>> Objet : Re: >>>> [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >>>> >>>> My point was that if server status was solicited, keep-alive interval >>>> would be independent of firewall/NAT timeout. Keep-alives would be >>>> optional. >>>> >>>> Solicited means that client says "get status" vs. the server just >>>> sending updates. >>>> >>>> >>>> >>>> David Dolson >>>> Sandvine >>>>   Original Message >>>> From: mohamed.boucadair@orange.com >>>> >>>> Sent: Thursday, October 26, 2017 2:11 PM >>>> To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon >>>> Shallow; dots@ietf.org >>>> Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review >>>> (-06)) >>>> >>>> >>>> Hi Dave, >>>> >>>> The protocol does already support a mechanism to send keepalive >>>> messages every 30s (recommended value). >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Dave Dolson [mailto:ddolson@sandvine.com] Envoyé : jeudi 26 >>>>> octobre 2017 13:15 À : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed >>>>> IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org >>>>> Objet : RE: >>>>> [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >>>>> >>>>> I think there is another option to handle the NAT/firewall problems >>>>> by changing the protocol. >>>>> >>>>> If I understand correctly, currently the NAT and firewall need to be >>>> kept >>>>> open to permit unsolicited server packets. >>>>> >>>>> If the protocol is changed to require client polling of the server >>>>> updates, the NAT and firewall problems go away. >>>>> >>>>> -Dave >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda, >>>> Tirumaleswar >>>>> Reddy >>>>> Sent: Thursday, October 26, 2017 12:58 PM >>>>> To: mohamed.boucadair@orange.com >>>>> ; Flemming Andreasen; Jon >>>>> Shallow; >>>>> dots@ietf.org >>>>> Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review >>>>> (-06)) >>>>> >>>>>> -----Original Message----- >>>>>> From: mohamed.boucadair@orange.com >>>>>> [mailto:mohamed.boucadair@orange.com] >>>>>> Sent: Thursday, October 26, 2017 2:21 PM >>>>>> To: Konda, Tirumaleswar Reddy >>>>>> ; >>>>>> Flemming Andreasen ; Jon Shallow >>>>> ietf@jpshallow.com>; dots@ietf.org >>>>>> Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review >>>>>> (-06)) >>>>>> >>>>>> Re-, >>>>>> >>>>>> I hear you. My take is that we don't need to recommend which >>>>>> companion "protocols/mechanisms" need to be supported for NAT/FW >>>>>> traversal purposes. Having a discussion at the same level in 8085 >>>>>> would be sufficient, IMHO. >>>>>> >>>>>> Let's focus on the simple built-in feature for NAT detect. >>>>> I don't think the simple built-in feature is sufficient, DOTS client >>>> will >>>>> have to rely on mechanisms discussed in 8085 for both firewall and >>>>> NAT traversal. >>>>> >>>>> -Tiru >>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Konda, Tirumaleswar Reddy >>>>>>> [mailto:TirumaleswarReddy_Konda@McAfee.com] >>>>>>> Envoyé : jeudi 26 octobre 2017 10:36 À : BOUCADAIR Mohamed >>>>>>> IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org >>>>>>> Objet : >>>>>>> RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >>>>>>> >>>>>>> But NATs are not the only problem, firewalls will also be most >>>>>>> likely present, and STUN helps discover both NATs and firewalls >>>>>>> and useful even in IPv6 networks to determine the keepalive >>>>>>> interval of >>>>> firewall. >>>>>>> -Tiru >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mohamed.boucadair@orange.com >>>>>>>> >>>>>>>> [mailto:mohamed.boucadair@orange.com] >>>>>>>> Sent: Thursday, October 26, 2017 1:52 PM >>>>>>>> To: Konda, Tirumaleswar Reddy >>>>>> >>>>> >; >>>>>>>> Flemming Andreasen >>>>>>> >; Jon Shallow >>>>>>> ietf@jpshallow.com >; dots@ietf.org >>>>>>>> >>>>>>>> Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements >>>>>>>> review >>>>>>>> (-06)) >>>>>>>> >>>>>>>> Tiru, >>>>>>>> >>>>>>>> Yes, STUN can be listed as part of the existing tools box >>>>>>>> (among the >>>>>>> lines of >>>>>>>> what is already discussed in 8085). >>>>>>>> >>>>>>>> I don't think that it makes sense to require STUN support by >>>>>>>> DOTS >>>>>>> clients. >>>>>>>> The proposal is to include a simple built-in feature in the >>>>>>>> DOTS >>>>>>> protocol itself >>>>>>>> that can help to detect NATs. The support of such feature >>>>>>>> will, e.g., >>>>>>> ease >>>>>>>> troubleshooting when connectivity problems are experienced on >>>>>>>> the path between a client and a server. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>> >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : Konda, Tirumaleswar Reddy >>>>>>>>> [mailto:TirumaleswarReddy_Konda@McAfee.com] >>>>>>>>> Envoyé : jeudi 26 octobre 2017 09:44 À : BOUCADAIR Mohamed >>>>>>>>> IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org >>>>>>>>> Objet : >>>>>>>>> RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review >>>>>>>>> (-06)) >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of >>>>>>>>>> mohamed.boucadair@orange.com >>>>>>>>>> >>>>>>>>>> Sent: Tuesday, October 24, 2017 2:20 PM >>>>>>>>>> To: Flemming Andreasen ; Jon Shallow >>>>>>>>>> ; dots@ietf.org >>>>>>>>>> Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements >>>>>>>>>> review >>>>>>>>>> (-06)) >>>>>>>>>> >>>>>>>>>> Hi Flemming, all, >>>>>>>>>> >>>>>>>>>> Please see inline. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Med >>>>>>>>>> >>>>>>>>>>> -----Message d'origine----- De : Flemming Andreasen >>>>>>>>>>> [mailto:fandreas@cisco.com] Envoyé : >>>>>>>>>>> lundi >>>>>>>>>>> 23 octobre 2017 17:36 À : BOUCADAIR Mohamed IMT/OLN; Jon >>>>>>>>>>> Shallow; dots@ietf.org Objet : Re: DOTS & NAT (was RE: >>>>>>>>>>> [Dots] DOTS Requirements review (-06)) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/23/17 8:28 AM, mohamed.boucadair@orange.com wrote: >>>>>>>>>>>> Hi Jon, all, >>>>>>>>>>>> >>>>>>>>>>>> I agree with Flemming that "some more work" is needed. >>>>>>>>>>>> IMHO, this is a >>>>>>>>>>> typical discussion to include in a dedicated section in >>>>>>>>>>> the DOTS architecture I-D. >>>>>>>>>>> Agreed. >>>>>>>>>>>> >From a requirement standpoint, we don't need to >>>>>>>>>>>>> elaborate how the >>>>>>>>>>> protocols will fulfil it. SIG-10 does even a nice job by >>>>>>>>>>> citing >>>>>>>>>>> RFC8085 which points to NAT traversal mechanisms. One >>>>>>>>>>> could pick his/her favorite protocol from the list in >>>>>>>>>>> 8085 to discover the external IP address/prefix, if >>>>>>>>>>> needed. External IP addresses/prefixes can be IPv4 for a >>>>>>>>>>> NAT44 or NAT64, but can be >>>>>>>>>>> IPv6 prefixes for enterprises deploying NPTv6, and so on. >>>>>>>>>>> Part of the challenge here is that the attack target and >>>>>>>>>>> the DOTS client are not necessarily one and the same, >>>>>>>>>>> which makes it more difficult to determine the >>>>>>>>>>> public-facing IP-address/port under attack (at least if >>>>>>>>>>> the DOTS client is going to >>>>>> do it). >>>>>>>>>> [Med] This is exactly the kind of the discussion to have. >>>>> Thanks. >>>>>>>>>> With or without NAT, DOTS clients are assumed to be fed >>>>>>>>>> with the >>>>>>>>> internal >>>>>>>>>> target(s). This can be achieved by provisioning (likely) >>>>>>>>>> or by discovery >>>>>>>>> means >>>>>>>>>> (e.g., residential or small enterprise networks). >>>>>>>>>> >>>>>>>>>> Can we assume that the discovery of the external IP >>>>>>>>>> address/prefix/.. is >>>>>>>>> done >>>>>>>>>> by a DOTS client only if it is explicitly instructed to do so? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> In some deployments, DOTS clients may be provisioned >>>>>>>>>>>> with the set of >>>>>>>>>>> internal resources, so there is no need for discovery. >>>>>>>>>>>> Also, as Jon mentioned, DOTS gateways can be of help >>>>>>>>>>>> to set the >>>>>>>>>>> appropriate IP addresses/prefixes/port numbers in the >>>>>>>>>>> presence of translators. >>>>>>>>>>> Agreed - but they still need a way to figure out the >>>>>>>>>>> private/public mapping for a given attack target. >>>>>>>>>> [Med] Because a DDoS attack is observed from the internal >>>>>>>>>> network, >>>>>>>>>> mapping(s) are necessarily maintained by the on-path >>>>> translator(s). >>>>>>>>>> Otherwise, the incoming attack traffic couldn't be >>>>>>>>>> forwarded to internal >>>>>>>>> hosts. >>>>>>>>>> This model assumes that the gateway is collocated with the >>>> NAT. >>>>>>>>>> So, the gateway can replace the internal IP address/prefix >>>>>>>>>> with the one >>>>>>>>> retrieves >>>>>>>>>> from the NAT mapping table. >>>>>>>>>> >>>>>>>>>> Do you see any issue with this scheme? >>>>>>>>>> >>>>>>>>>>>> An open question though would be to discuss if there >>>>>>>>>>>> is a value in >>>>>>>>>>> having a feature in the DOTS protocol to inform a DOTS >>>>>>>>>>> client that a NAT is detected on-path. This can be >>>>>>>>>>> presented as an information element returned by the >>>>>>>>>>> server to the client. This information can be, for >>>>>>>>>>> example, used by the client to adjust its HT interval, >>>>>>>>>>> adjust the internal IP addresses/prefixes to be >>>>>> protected, etc. >>>>>>> Opinions? >>>>>>>>>>> It sounds appealing, but it's very difficult to do this >>>>>>>>>>> reliably, and it's not just NATs that are an issue here; >>>>>>>>>>> Firewalls present similar challenges (and they may or >>>>>>>>>>> may not be NAT'ing individual >>>>>>>> flows). >>>>>>>>>> [Med] I fully agree that firewalls detect is more complex. >>>>>>>>>> Let's put it >>>>>>>>> aside >>>>>>>>>> and focus on the NAT case. >>>>>>>>> The presence and behavior of NAT and Firewall, and keepalive >>>>>>>>> interval can be determined using STUN (discussed in >>>>>>>>> https://tools.ietf.org/html/rfc5780). >>>>>>>>> >>>>>>>>> -Tiru >>>>>>>>> >>>>>>>>>> We can consider many approaches to detect a NAT, e.g., >>>>>>>>>> >>>>>>>>>> (1) The DOTS client inserts in the core message the IP >>>>>>>>>> address/port it >>>>>>>>> uses to >>>>>>>>>> send the request to the DOTS server. Upon receipt of the >>>>>>>>>> request by the DOTS server, it checks if the enclosed IP >>>>>>>>>> address/port match the source >>>>>>>>> IP >>>>>>>>>> address/port of the received packet. If yes, the server >>>>>>>>>> sets in the >>>>>>>>> response a >>>>>>>>>> dedicated parameter to indicate that a translator is >>>>>>>>>> detected >>>>>>>>>> on- >>>>>>> path. >>>>>>>>>> (2) The DOTS server inserts systematically the source IP >>>>>>>>>> address/port in >>>>>>>>> a >>>>>>>>>> response to a message from a DOTS client. Upon receipt of >>>>>>>>>> that response, the DOTS client compares the enclosed >>>>>>>>>> address/port with the ones it used >>>>>>>>> to >>>>>>>>>> send the request to detect any mismatch. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -- Flemming >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Med >>>>>>>>>>>> >>>>>>>>>>>>> -----Message d'origine----- De : Dots >>>>>>>>>>>>> [mailto:dots-bounces@ietf.org] De la part de Jon >>>>>>>>>>>>> Shallow Envoyé : lundi 23 octobre 2017 13:18 À : >>>>>>>>>>>>> 'Flemming Andreasen'; dots@ietf.org >>>>>>>>>>>>> Objet : Re: >>>>>>>>>>>>> [Dots] DOTS Requirements review (-06) >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Flemming, >>>>>>>>>>>>> >>>>>>>>>>>>> The way my mind works is to think of a practical >>>>>>>>>>>>> situation and see if things fit. >>>>>>>>>>>>> >>>>>>>>>>>>> As I read SIG-010, there could be a DOTS client with >>>>>>>>>>>>> a management IP address that is RFC1918 - this client >>>>>>>>>>>>> could be monitoring Netflow information and can >>>>>>>>>>>>> request mitigation for the appropriate public IPs >>>>>>>>>>> that >>>>>>>>>>>>> are being monitored.  So SIG-010 is needed for this >>>>>>>>>>>>> use >>>>> case. >>>>>>>>>>>>> It is the responsibility of the DOTS server as to >>>>>>>>>>>>> whether it accepts a mitigation request for a >>>>>>>>>>>>> particular target ip (or domain >>>>>>>>> etc.) or >>>>>>>>>> not. >>>>>>>>>>>>> If there is going to be a NAT border where public IPs >>>>>>>>>>>>> are mapped into private IPs (and vice versa), I would >>>>>>>>>>>>> then expect there to be a DOTS gateway between these >>>>>>>>>>>>> 2 zones, and it is the responsibility of the DOTS >>>>>>>>>>>>> gateway to do any target-ip >>>>>>> mappings. >>>>>>>>>>>>> Regards >>>>>>>>>>>>> >>>>>>>>>>>>> Jon >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] >>>>>>>>>>>>> On Behalf Of Flemming Andreasen >>>>>>>>>>>>> Sent: 22 October 2017 20:17 >>>>>>>>>>>>> To: dots; draft-ietf-dots-requirements@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> Subject: [Dots] DOTS Requirements review (-06) >>>>>>>>>>>>> >>>>>>>>>>>>> Greetings >>>>>>>>>>>>> >>>>>>>>>>>>> I have reviewed the latest version of the DOTS >>>>>>>>>>>>> requirements draft >>>>>>>>>>>>> (https://www.ietf.org/id/draft-ietf-dots-requirements >>>>>>>>>>>>> - >>>>> 06.txt). >>>>>>>>>>>>> In >>>>>>>>>>> general, >>>>>>>>>>>>> I think the draft is in good shape with only a few >>>>>>>>>>>>> edits required, so I hope we can move to WGLC soon. I >>>>>>>>>>>>> have a few comments below (of which >>>>>>>>>>> the >>>>>>>>>>>>> NAT one is the only real substantial one). I have >>>>>>>>>>>>> also submitted a pull request with a few nit fixes on GitHub: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Section 1.2 >>>>>>>>>>>>> - The definition of "DOTS Signal" is slightly >>>>>>>>>>>>> inconsistent with the respective "Client Signal" and >>>>> "Server Signal" definitions. >>>>>>>>>>>>> SIG-005: >>>>>>>>>>>>> - Not clear that always requiring "number of packets" >>>>>>>>>>>>> metrics is meaningful. Consider TCP-based attacks for >>>>>>>>>>>>> example. Number of bytes may always be ok - above and >>>>>>>>>>>>> beyond that it should probably be extensible and/or >>>>>>>>>>>>> attack >>>>>> dependent. >>>>>>>>>>>>> - I don't think the requirements document should get >>>>>>>>>>>>> into specifying >>>>>>>>>>> timer >>>>>>>>>>>>> values - expontial backoff with some maximum value >>>>>>>>>>>>> seems about the >>>>>>>>>>> right >>>>>>>>>>>>> level of detail here. >>>>>>>>>>>>> >>>>>>>>>>>>> SIG-009: >>>>>>>>>>>>> - To be clear, the conflicts only apply within a >>>>>>>>>>>>> single administrative domain, right ? For example, if >>>>>>>>>>>>> a client tells the same domain to alternately turn >>>>>>>>>>>>> on/off mitigation for a given prefix, route flapping >>>>>>>>>>> may >>>>>>>>>>>>> occur. The same concern does not apply if a client >>>>>>>>>>>>> tells two different administrative domains to >>>>>>>>>>>>> respective turn mitigation on (domain 1) and >>>>>>>>>>> off >>>>>>>>>>>>> (domain 2). If so, can we clarify that (also in lieu >>>>>>>>>>>>> of some of the >>>>>>>>>>> multi- >>>>>>>>>>>>> homing comments raised previously) ? >>>>>>>>>>>>> >>>>>>>>>>>>> SIG-010: >>>>>>>>>>>>> - DOTS Client behind NAT. On one hand, it seems >>>>>>>>>>>>> reasonable to have this requirement since clients for >>>>>>>>>>>>> sure can be behind NATs, and >>>>>>>>> with >>>>>>>>>> things >>>>>>>>>>>>> like dynamic DNS, they can     certainly be reachable. >>>>> However, >>>>>>> if >>>>>>>>> we >>>>>>>>>>> do >>>>>>>>>>>>> want to allow for this scenario, and in particular >>>>>>>>>>>>> for the DOTS client >>>>>>>>>>> to >>>>>>>>>>>>> have a private IP-address (potentially behind >>>>>>>>>>>>> multiple NATs), then we >>>>>>>>>>> have >>>>>>>>>>>>> more work to do because it won't do the DOTS server >>>>>>>>>>>>> any good to get a mitigation request referring to >>>>>>>>>>>>> that private IP-address (or >>>>>>>>> prefix). >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> -- Flemming >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Dots mailing list >>>>>>>>>>>>> Dots@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Dots mailing list >>>>>>>>>>>>> Dots@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Dots mailing list >>>>>>>>>> Dots@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots >>>>> _______________________________________________ >>>>> Dots mailing list >>>>> Dots@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dots >>> . >>> >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > --------------3820AFCD83EC294B03B5BA90 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 10/26/17 12:58 PM, Mortensen, Andrew wrote:

On Oct 26, 2017, at 9:46 AM, Flemming Andreasen <fandreas@cisco.com> wrote:

As I have stated several times before, I'm not all that comfortable with the current requirement around always sending keep-alives, whether attacks are in progress or now. My concerns are around scalability/cost of the overall solution, so I think it's worth considering during peace-time at least.

Hi Flemming. I suspect your concerns aren’t fully addressed by reducing the heartbeat MUST to a SHOULD, as captured in this issue:


Thanks for capturing it in the issue, and you are right, I would still have concerns with a SHOULD requirement (but it would obviously be better than the current MUST).

Do we need to recast the requirement to capture the peace-time aspect? For example, should a DOTS server be able to tell a client to stop heartbeats, or slow the heartbeat rate?

That seems useful to me, however we may need to couple that with the client unilaterally increasing the rate when it's under attack to ensure bi-directional communication is still possible.

Thanks

-- Flemming

andrew



On 10/26/17 9:13 AM, Dave Dolson wrote:
I'm not pushing for this. I saw the working group struggling with the firewall/NAT problem, and offered a different way of thinking about it.
To be clear, my suggestion is to remove unsolicited messages from the server to client.

-Dave


-----Original Message-----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Thursday, October 26, 2017 3:06 PM
To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon Shallow; dots@ietf.org
Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

Re-,

Not sure how to get rid of the constraint imposed by the NAT/FW timer, Dave.

The current text says the following:

   To provide a metric of signal health and distinguish an 'idle' signal
   channel from a 'disconnected' or 'defunct' session, the DOTS agent
   sends a heartbeat over the signal channel to maintain its half of the
   channel.  The DOTS agent similarly expects a heartbeat from its peer
   DOTS agent, and may consider a session terminated in the extended
   absence of a peer agent heartbeat.

Which covers your proposal. No?

Solicited messages from the server do not prevent from failures. Consider the case where a DOTS server has to send a mitigation status update back to the client, but the client didn't refreshed the state. Or when the NAT fired out a mapping and assigns the external port to another host than the DOTS client.

Did I missed something?

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Dave Dolson [mailto:ddolson@sandvine.com] Envoyé : jeudi 26
octobre 2017 14:50 À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar
Reddy; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : Re:
[Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

My point was that if server status was solicited, keep-alive interval
would be independent of firewall/NAT timeout. Keep-alives would be
optional.

Solicited means that client says "get status" vs. the server just
sending updates.



David Dolson
Sandvine
  Original Message
From: mohamed.boucadair@orange.com
Sent: Thursday, October 26, 2017 2:11 PM
To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon
Shallow; dots@ietf.org
Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review
(-06))


Hi Dave,

The protocol does already support a mechanism to send keepalive
messages every 30s (recommended value).

Cheers,
Med

-----Message d'origine-----
De : Dave Dolson [mailto:ddolson@sandvine.com] Envoyé : jeudi 26
octobre 2017 13:15 À : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed
IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet : RE:
[Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

I think there is another option to handle the NAT/firewall problems
by changing the protocol.

If I understand correctly, currently the NAT and firewall need to be
kept
open to permit unsolicited server packets.

If the protocol is changed to require client polling of the server
updates, the NAT and firewall problems go away.

-Dave


-----Original Message-----
From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda,
Tirumaleswar
Reddy
Sent: Thursday, October 26, 2017 12:58 PM
To: mohamed.boucadair@orange.com; Flemming Andreasen; Jon Shallow;
dots@ietf.org
Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review
(-06))

-----Original Message-----
From: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Sent: Thursday, October 26, 2017 2:21 PM
To: Konda, Tirumaleswar Reddy
<TirumaleswarReddy_Konda@McAfee.com>;
Flemming Andreasen <fandreas@cisco.com>; Jon Shallow <supjps-
ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review
(-06))

Re-,

I hear you. My take is that we don't need to recommend which
companion "protocols/mechanisms" need to be supported for NAT/FW
traversal purposes. Having a discussion at the same level in 8085
would be sufficient, IMHO.

Let's focus on the simple built-in feature for NAT detect.
I don't think the simple built-in feature is sufficient, DOTS client
will
have to rely on mechanisms discussed in 8085 for both firewall and
NAT traversal.

-Tiru

Cheers,
Med

-----Message d'origine-----
De : Konda, Tirumaleswar Reddy
[mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoyé : jeudi 26 octobre 2017 10:36 À : BOUCADAIR Mohamed
IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet :
RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

But NATs are not the only problem, firewalls will also be most
likely present, and STUN helps discover both NATs and firewalls
and useful even in IPv6 networks to determine the keepalive
interval of
firewall.
-Tiru

-----Original Message-----
From: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Sent: Thursday, October 26, 2017 1:52 PM
To: Konda, Tirumaleswar Reddy
<TirumaleswarReddy_Konda@McAfee.com>;
Flemming Andreasen <fandreas@cisco.com>; Jon Shallow <supjps-
ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements
review
(-06))

Tiru,

Yes, STUN can be listed as part of the existing tools box
(among the
lines of
what is already discussed in 8085).

I don't think that it makes sense to require STUN support by
DOTS
clients.
The proposal is to include a simple built-in feature in the
DOTS
protocol itself
that can help to detect NATs. The support of such feature
will, e.g.,
ease
troubleshooting when connectivity problems are experienced on
the path between a client and a server.

Cheers,
Med

-----Message d'origine-----
De : Konda, Tirumaleswar Reddy
[mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoyé : jeudi 26 octobre 2017 09:44 À : BOUCADAIR Mohamed
IMT/OLN; Flemming Andreasen; Jon Shallow; dots@ietf.org Objet :
RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review
(-06))

-----Original Message-----
From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of
mohamed.boucadair@orange.com
Sent: Tuesday, October 24, 2017 2:20 PM
To: Flemming Andreasen <fandreas@cisco.com>; Jon Shallow
<supjps- ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements
review
(-06))

Hi Flemming, all,

Please see inline.

Cheers,
Med

-----Message d'origine----- De : Flemming Andreasen
[mailto:fandreas@cisco.com] Envoyé :
lundi
23 octobre 2017 17:36 À : BOUCADAIR Mohamed IMT/OLN; Jon
Shallow; dots@ietf.org Objet : Re: DOTS & NAT (was RE:
[Dots] DOTS Requirements review (-06))



On 10/23/17 8:28 AM, mohamed.boucadair@orange.com wrote:
Hi Jon, all,

I agree with Flemming that "some more work" is needed.
IMHO, this is a
typical discussion to include in a dedicated section in
the DOTS architecture I-D.
Agreed.
>From a requirement standpoint, we don't need to
elaborate how the
protocols will fulfil it. SIG-10 does even a nice job by
citing
RFC8085 which points to NAT traversal mechanisms. One
could pick his/her favorite protocol from the list in
8085 to discover the external IP address/prefix, if
needed. External IP addresses/prefixes can be IPv4 for a
NAT44 or NAT64, but can be
IPv6 prefixes for enterprises deploying NPTv6, and so on.
Part of the challenge here is that the attack target and
the DOTS client are not necessarily one and the same,
which makes it more difficult to determine the
public-facing IP-address/port under attack (at least if
the DOTS client is going to
do it).
[Med] This is exactly the kind of the discussion to have.
Thanks.
With or without NAT, DOTS clients are assumed to be fed
with the
internal
target(s). This can be achieved by provisioning (likely)
or by discovery
means
(e.g., residential or small enterprise networks).

Can we assume that the discovery of the external IP
address/prefix/.. is
done
by a DOTS client only if it is explicitly instructed to do so?


In some deployments, DOTS clients may be provisioned
with the set of
internal resources, so there is no need for discovery.
Also, as Jon mentioned, DOTS gateways can be of help
to set the
appropriate IP addresses/prefixes/port numbers in the
presence of translators.
Agreed - but they still need a way to figure out the
private/public mapping for a given attack target.
[Med] Because a DDoS attack is observed from the internal
network,
mapping(s) are necessarily maintained by the on-path
translator(s).
Otherwise, the incoming attack traffic couldn't be
forwarded to internal
hosts.
This model assumes that the gateway is collocated with the
NAT.
So, the gateway can replace the internal IP address/prefix
with the one
retrieves
from the NAT mapping table.

Do you see any issue with this scheme?

An open question though would be to discuss if there
is a value in
having a feature in the DOTS protocol to inform a DOTS
client that a NAT is detected on-path. This can be
presented as an information element returned by the
server to the client. This information can be, for
example, used by the client to adjust its HT interval,
adjust the internal IP addresses/prefixes to be
protected, etc.
Opinions?
It sounds appealing, but it's very difficult to do this
reliably, and it's not just NATs that are an issue here;
Firewalls present similar challenges (and they may or
may not be NAT'ing individual
flows).
[Med] I fully agree that firewalls detect is more complex.
Let's put it
aside
and focus on the NAT case.
The presence and behavior of NAT and Firewall, and keepalive
interval can be determined using STUN (discussed in
https://tools.ietf.org/html/rfc5780).

-Tiru

We can consider many approaches to detect a NAT, e.g.,

(1) The DOTS client inserts in the core message the IP
address/port it
uses to
send the request to the DOTS server. Upon receipt of the
request by the DOTS server, it checks if the enclosed IP
address/port match the source
IP
address/port of the received packet. If yes, the server
sets in the
response a
dedicated parameter to indicate that a translator is
detected
on-
path.
(2) The DOTS server inserts systematically the source IP
address/port in
a
response to a message from a DOTS client. Upon receipt of
that response, the DOTS client compares the enclosed
address/port with the ones it used
to
send the request to detect any mismatch.


-- Flemming


Cheers,
Med

-----Message d'origine----- De : Dots
[mailto:dots-bounces@ietf.org] De la part de Jon
Shallow Envoyé : lundi 23 octobre 2017 13:18 À :
'Flemming Andreasen'; dots@ietf.org Objet : Re:
[Dots] DOTS Requirements review (-06)

Hi Flemming,

The way my mind works is to think of a practical
situation and see if things fit.

As I read SIG-010, there could be a DOTS client with
a management IP address that is RFC1918 - this client
could be monitoring Netflow information and can
request mitigation for the appropriate public IPs
that
are being monitored.  So SIG-010 is needed for this
use
case.
It is the responsibility of the DOTS server as to
whether it accepts a mitigation request for a
particular target ip (or domain
etc.) or
not.
If there is going to be a NAT border where public IPs
are mapped into private IPs (and vice versa), I would
then expect there to be a DOTS gateway between these
2 zones, and it is the responsibility of the DOTS
gateway to do any target-ip
mappings.
Regards

Jon

-----Original Message-----
From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org]
On Behalf Of Flemming Andreasen
Sent: 22 October 2017 20:17
To: dots; draft-ietf-dots-requirements@ietf.org
Subject: [Dots] DOTS Requirements review (-06)

Greetings

I have reviewed the latest version of the DOTS
requirements draft
(https://www.ietf.org/id/draft-ietf-dots-requirements
-
06.txt).
In
general,
I think the draft is in good shape with only a few
edits required, so I hope we can move to WGLC soon. I
have a few comments below (of which
the
NAT one is the only real substantial one). I have
also submitted a pull request with a few nit fixes on GitHub:


Section 1.2
- The definition of "DOTS Signal" is slightly
inconsistent with the respective "Client Signal" and
"Server Signal" definitions.
SIG-005:
- Not clear that always requiring "number of packets"
metrics is meaningful. Consider TCP-based attacks for
example. Number of bytes may always be ok - above and
beyond that it should probably be extensible and/or
attack
dependent.
- I don't think the requirements document should get
into specifying
timer
values - expontial backoff with some maximum value
seems about the
right
level of detail here.

SIG-009:
- To be clear, the conflicts only apply within a
single administrative domain, right ? For example, if
a client tells the same domain to alternately turn
on/off mitigation for a given prefix, route flapping
may
occur. The same concern does not apply if a client
tells two different administrative domains to
respective turn mitigation on (domain 1) and
off
(domain 2). If so, can we clarify that (also in lieu
of some of the
multi-
homing comments raised previously) ?

SIG-010:
- DOTS Client behind NAT. On one hand, it seems
reasonable to have this requirement since clients for
sure can be behind NATs, and
with
things
like dynamic DNS, they can     certainly be reachable.
However,
if
we
do
want to allow for this scenario, and in particular
for the DOTS client
to
have a private IP-address (potentially behind
multiple NATs), then we
have
more work to do because it won't do the DOTS server
any good to get a mitigation request referring to
that private IP-address (or
prefix).

Thanks

-- Flemming

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots
.

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots
_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots
.


_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots


--------------3820AFCD83EC294B03B5BA90-- From nobody Thu Oct 26 13:35:53 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9AD13899A for ; Thu, 26 Oct 2017 13:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQghWdUFE0el for ; Thu, 26 Oct 2017 13:35:49 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 85FC213F5FC for ; Thu, 26 Oct 2017 13:35:48 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e7osT-0000LR-UJ for ietf-supjps-dots@ietf.org; Thu, 26 Oct 2017 21:35:46 +0100 From: "Jon Shallow" To: Date: Thu, 26 Oct 2017 21:35:45 +0100 Message-ID: <017001d34e9a$000d7b50$002871f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0171_01D34EA2.61D2F4C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdNOmftpS0b6T9g6S+iNSHMqb5xZmA== Content-Language: en-gb Archived-At: Subject: [Dots] Full Pipe Scenario X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 20:35:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0171_01D34EA2.61D2F4C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, DOTS Client (C) --------- Pipe -------- DOTS Server (S) We have been testing DOTS server and DOTS client signal channel interaction with a full inbound pipe scenario where all traffic from DOTS server to DOTS client is dropped, but traffic from DOTS client is getting through to the DOTS server. The outbound pipe may be lossy, but testing was done with very little loss outbound. If the outbound pipe is running full, then the DOTS Client environment has to control this traffic as the DOTS Server is very unlikely to be able to do anything here - so this scenario ignored! With this full inbound pipe (direction S to C), we are seeing the following . DOTS server sees the Heartbeat requests from the DOTS client . DOTS server sees any mitigation requests from the DOTS client . DOTS server thinks the signal channel is dead as there are no responses to the DOTS server's Heartbeats . DOTS client thinks the signal channel is dead as there are no responses to the DOTS client's Heartbeats . DOTS client is unable to establish a new signal channel with the server (this may be down to the fact that we internally have not (yet) got session resumption working over DTLS) and so cannot send mitigation requests over this channel If the DOTS server is seeing and noting the DOTS client Heartbeat requests, it can determine the session is still alive and keep it going, even if its own Heartbeats are failing (perhaps just mark the session as 'Heartbeat Failing' after the missing heartbeat counter has expired). Should we be doing this noting of DOTS Client heartbeats? -The DOTS server can safely assume there is a pipe full scenario (or network routing issue) if it continues to see the DOTS client heartbeats. If the DOTS server is still keeping the session going, and receives a DOTS client mitigation request it can be acted on, even though there is a full pipe. Is this a good thing? Should the DOTS client continue to send Heartbeats after the DOTS client has determined the session has 'Heartbeat Failed' - so that that the DOTS server is kept "warm" in case a mitigation request has to blindly be sent. If the DOTS client closes the session after Heartbeat failure, fails to establish a new session, then there is no mechanism to send a mitigation request - the DOTS client may have discovered a new IP or subnet under attack. - I appreciate that we have a trigger-mitigation flag which may help here. - If the new session gets going, then the "Heartbeat Failure" session should be closed down. Keeping the Heartbeats going, even after the determination that Heartbeats are failing has benefits in supporting additional mitigation requests, but potentially conflicts with the DOTS requirements specification of considering a DOTS signal channel as no longer active after receipt of heartbeat responses. I know SIG-003 is the subject of another debate - do we need heartbeats at all. SIG-003 Channel Health Monitoring: Peer DOTS agents MUST regularly send heartbeats to each other after mutual authentication in order to keep the DOTS signal channel active. A signal channel MUST be considered active until a DOTS agent explicitly ends the session, or either DOTS agent fails to receive heartbeats from the other after a mutually agreed upon timeout period has elapsed. Regards Jon ------=_NextPart_000_0171_01D34EA2.61D2F4C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

DOTS Client = (C) –--------  Pipe –------- DOTS Server = (S)

 

We have been testing DOTS server and DOTS client = signal channel interaction with a full inbound pipe scenario where all = traffic from DOTS server to DOTS client is dropped, but traffic from = DOTS client is getting through to the DOTS server.

 

The outbound = pipe may be lossy, but testing was done with very little loss = outbound.

 

If the outbound pipe is running full, then the DOTS = Client environment has to control this traffic as the DOTS Server is = very unlikely to be able to do anything here – so this scenario = ignored!

 

With this full inbound pipe (direction S to C), we are = seeing the following

 

·        = DOTS server sees the Heartbeat requests = from the DOTS client

·        = DOTS server sees any mitigation requests = from the DOTS client

·        = DOTS server thinks the signal channel is = dead as there are no responses to the DOTS server’s = Heartbeats

·        = DOTS client thinks the signal channel is = dead as there are no responses to the DOTS client’s = Heartbeats

·        = DOTS client is unable to establish a new = signal channel with the server (this may be down to the fact that we = internally have not (yet) got session resumption working over DTLS) and = so cannot send mitigation requests over  this = channel

 

If the DOTS server is seeing and noting the DOTS = client Heartbeat requests, it can determine the session is still alive = and keep it going, even if its own Heartbeats are failing (perhaps just = mark the session as ‘Heartbeat Failing’ after the missing = heartbeat counter has expired).  Should we be doing this noting of = DOTS Client heartbeats?

-The DOTS = server can safely assume there is a pipe full scenario (or network = routing issue) if it continues to see the DOTS client = heartbeats.

 

If the DOTS server is still keeping the session going, = and receives a DOTS client mitigation request it can be acted on, even = though there is a full pipe.  Is this a good = thing?

 

Should the DOTS client continue to send Heartbeats = after the DOTS client has determined the session has ‘Heartbeat = Failed’ – so that that the DOTS server is kept = “warm” in case a mitigation request has to blindly be = sent.

 

If the DOTS client closes the session after Heartbeat = failure, fails to establish a new session, then there is no mechanism to = send a mitigation request – the DOTS client may have discovered a = new IP or subnet under attack.

- I = appreciate that we have a trigger-mitigation flag which may help = here.

- If the new session gets = going, then the “Heartbeat Failure” session should be closed = down.

 

Keeping the Heartbeats going, even after the = determination that Heartbeats are failing has benefits in supporting = additional mitigation requests, but potentially conflicts with the DOTS = requirements specification of considering a DOTS signal channel as no = longer active after receipt of heartbeat responses.  I know SIG-003 = is the subject of another debate – do we need heartbeats at = all.

 

   SIG-003  Channel Health Monitoring: = Peer DOTS agents MUST regularly

      send heartbeats to each = other after mutual authentication in order

      to keep the DOTS signal = channel active.  A signal channel MUST be

      considered active until = a DOTS agent explicitly ends the session,

      or either DOTS agent = fails to receive heartbeats from the other

      after a mutually agreed = upon timeout period has elapsed.

 

Regards

 

Jon

------=_NextPart_000_0171_01D34EA2.61D2F4C0-- From nobody Thu Oct 26 13:44:42 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83A139567 for ; Thu, 26 Oct 2017 13:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQCfdW9ajjJo for ; Thu, 26 Oct 2017 13:44:38 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 99BDD13899A for ; Thu, 26 Oct 2017 13:44:37 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e7p11-0000Lw-SQ; Thu, 26 Oct 2017 21:44:35 +0100 From: "Jon Shallow" To: "'Mortensen, Andrew'" , "Konda, Tirumaleswar Reddy" , References: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> <0CEBEED4-F958-467A-98D5-54F7C4CB0883@arbor.net> In-Reply-To: <0CEBEED4-F958-467A-98D5-54F7C4CB0883@arbor.net> Date: Thu, 26 Oct 2017 21:44:35 +0100 Message-ID: <018601d34e9b$3beb2540$b3c16fc0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0187_01D34EA3.9DB1B020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJzltLgqVNK+TC2PfzhCbifUE2P7AM1pYPqAJ29zH6hl2u5EA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS signal and resource path discovery X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 20:44:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0187_01D34EA3.9DB1B020 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This works for me. It means that we no longer need = =E2=80=9Cdots-signal=E2=80=9D in the path (saves packet space). I still = would like to see =E2=80=9Csignal=E2=80=9D in the path renamed to, say, = =E2=80=9Cmitigate=E2=80=9D as DOTS signal covers both mitigation and = configuration. =20 However, what happens if DOTS has a version change from v1 to v2 ? - How do we handle this (unlikely) event? =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Mortensen, = Andrew Sent: 26 October 2017 15:50 To: Konda, Tirumaleswar Reddy Cc: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS signal and resource path discovery =20 =20 On Oct 26, 2017, at 10:29 AM, Konda, Tirumaleswar Reddy = wrote: =20 I don=E2=80=99t see the need to complicate the DOTS signal channel by = introducing resource discovery (see = = https://tools.ietf.org/html/rfc5785),=20 Many protocols like EST use well-known locations (e.g. = = https://www.example.com/.well-known/est/) where uri-suffix 'est' is = allocated by the IANA to avoid collisions.=20 We can consider a similar approach and request IANA to allocate = uri-suffix 'dots=E2=80=99. =20 I like this approach. =20 andrew =20 =20 =20 =20 =20 =20 =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, October 26, 2017 7:25 PM To: dots@ietf.org Subject: [Dots] DOTS signal and resource path discovery =20 Hi there =20 Following on from the recent virtual conference with discussions about = what should be the signal request path (should .wellknown be included in = it etc.). =20 RFC7252 7.1 Service Discovery =E2=80=9CThe CoAP default port number 5683 MUST be supported by a server = that offers resources for resource discovery (see Section 7.2 below) and SHOULD be supported for providing access to other resources. The default port number 5684 for DTLS-secured CoAP MAY be supported by a server for resource discovery and for providing access to other resources. In addition, other endpoints may be hosted at other ports, e.g., in the dynamic port space.=E2=80=9D =20 DOTS is not hosting non (D)TLS COAP, and so we will be breaking the MUST = for port 5683. I propose that we do the following for the signal = channel spec and support resource discovery. =20 1) Update the 2 paths (signal and configuration) in the = specification, when can then be the default values. Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "signal" To Uri-Path: "v1" << We are v1 as = described in the text Uri-Path: "dots-signal" Uri-Path: "mitigation" << overloaded use of signal, = this is the mitigate part of dots-signal And Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "config" To Uri-Path: "v1" Uri-Path: "dots-signal" Uri-Path: "configuration" 2) Add in the following =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.7 Resource Discovery =20 As per [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support = the CoRe Link Format of discoverable resource as described in [RFC6690], = except where fully manual configuration is desired. =20 The two discoverable resources that SHOULD be available to a DOTS client = are =E2=80=9Cmitigation=E2=80=9D and =E2=80=9Cconfiguration=E2=80=9D. = If the appropriate URI paths are returned, the DOTS client MUST use = them, overriding any default configuration. A DOTS client SHOULD do a = resource discovery, which is done by a GET request to = =E2=80=9C/.wellknown/core=E2=80=9D =20 Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".wellknown" Uri-Path: "core" =20 Figure xxx: GET to retrieve dots-signal resources =20 Content-Format:application/link-format =20 ;rt=3D"mitigation";title=3D"DOTS Signal = Mitigation";ct=3D60, ;rt=3D"configuration";title=3D"DOTS = Signal Configuration";ct=3D60 =20 Figure yyy: Example response to GET to retrieve dots-signal resources =20 =20 As to CoAP being on different ports on the server hosting DOTS server = (or DOTS gateway), this may have to be configurable in the DOTS clients, = or configurable on the Data Channel as an extension to =20 =E2=80=9CThe DOTS client will perform the root resource discovery = procedure discussed in Section 3.1 of [RFC8040] to determine the root of the RESTCONF API. After discovering the RESTCONF API root, the DOTS client uses this value as the initial part of the path in the request URI, in any subsequent request to the DOTS server. The DOTS server may support retrieval of the YANG modules it supports (Section 3.7 in [RFC8040]), for example, a DOTS client may use RESTCONF to retrieve the company proprietary YANG modules supported by the DOTS = server.=E2=80=9D =20 Regards =20 Jon =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0187_01D34EA3.9DB1B020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This works for me.=C2=A0 It means that we no longer need = =E2=80=9Cdots-signal=E2=80=9D in the path (saves packet space).=C2=A0 I = still would like to see =E2=80=9Csignal=E2=80=9D in the path renamed to, = say, =E2=80=9Cmitigate=E2=80=9D as DOTS signal covers both mitigation = and configuration.

 

However, what happens if DOTS has a version change from v1 to v2 = ?

- How do we handle this (unlikely) event?

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Mortensen, = Andrew
Sent: 26 October 2017 15:50
To: Konda, = Tirumaleswar Reddy
Cc: Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] DOTS signal and resource = path discovery

 

 

On Oct 26, 2017, at 10:29 AM, Konda, Tirumaleswar = Reddy <TirumaleswarReddy_Kond= a@McAfee.com> wrote:

 

I =
don=E2=80=99t see the need to complicate the DOTS signal channel by =
introducing resource discovery (see https://tools.ietf.org/html/rfc5785), =

Many =
protocols like EST use well-known locations (e.g. https://www.example.com/.well-known/est/) where uri-suffix 'est' is allocated by the IANA to avoid collisions. =

We can =
consider a similar approach and request IANA to allocate uri-suffix =
'dots=E2=80=99.
 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon = Shallow
Sent: Thursday, October 26, 2017 = 7:25 PM
To: dots@ietf.org
Subject: [Dots] DOTS signal and = resource path discovery

 =

Hi = there

 =

Following = on from the recent virtual conference with discussions about what should = be the signal request path (should .wellknown be included in it = etc.).

 =

RFC7252 = 7.1 Service Discovery

=E2=80=9CTh= e CoAP default port number 5683 MUST be supported by a server = that

  = ; offers resources for resource discovery (see Section 7.2 below) = and

  = ; SHOULD be supported for providing access to other resources.  = The

  = ; default port number 5684 for DTLS-secured CoAP MAY be supported by = a

  = ; server for resource discovery and for providing access to = other

  = ; resources.  In addition, other endpoints may be hosted at = other

  = ; ports, e.g., in the dynamic port = space.=E2=80=9D

 =

DOTS is = not hosting non (D)TLS COAP, and so we will be breaking the MUST for = port 5683.  I propose that we do the following for the signal = channel spec and support resource = discovery.

 =

1)      Update the = 2 paths (signal and configuration) in the specification, when can then = be the default values.

  = ;   Uri-Path: = "version"

  = ;   Uri-Path: = "dots-signal"

  = ;   Uri-Path: = "signal"

To

  = ;   Uri-Path: "v1" =             &= nbsp;           &n= bsp;    << We are v1 as described in the = text

  = ;   Uri-Path: = "dots-signal"

  = ;   Uri-Path: = "mitigation"        &nb= sp;        << overloaded use of = signal, this is the mitigate part of = dots-signal

  = ;            = And

  = ;   Uri-Path: = "version"

  = ;   Uri-Path: = "dots-signal"

  = ;   Uri-Path: = "config"

To

  = ;   Uri-Path: "v1"

  = ;   Uri-Path: = "dots-signal"

  = ;   Uri-Path: = "configuration"

2)      Add in the = following

 =

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

5.7 = Resource Discovery

 =

As per = [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support the CoRe = Link Format of discoverable resource as described in [RFC6690], except = where fully manual configuration is = desired.

 =

The two = discoverable resources that SHOULD be available to a DOTS client are = =E2=80=9Cmitigation=E2=80=9D and =E2=80=9Cconfiguration=E2=80=9D.  = If the appropriate URI paths are returned, the DOTS client MUST use = them, overriding any default configuration.  A DOTS client SHOULD = do a resource discovery, which is done by a GET request to = =E2=80=9C/.wellknown/core=E2=80=9D

 =

Header: = GET (Code=3D0.01)

  = ;   Uri-Host: = "host"

  = ;   Uri-Path: = ".wellknown"

  = ;   Uri-Path: = "core"

 =

Figure = xxx: GET to retrieve dots-signal = resources

 =

Content-For= mat:application/link-format

 =

<v1/dots= -signal/mitigation>;rt=3D"mitigation";title=3D"DOTS = Signal Mitigation";ct=3D60,

</v1/dot= s-signal/configuration>;rt=3D"configuration";title=3D"D= OTS Signal = Configuration";ct=3D60

 =

Figure = yyy: Example response to GET to retrieve dots-signal = resources

 =

 =

As to CoAP = being on different ports on the server hosting DOTS server (or DOTS = gateway), this may have to be configurable in the DOTS clients, or = configurable on the Data Channel as an extension = to

 =

=E2=80=9CTh= e DOTS client will perform the root resource discovery = procedure

  = ; discussed in Section 3.1 of [RFC8040] to determine the root of = the

  = ; RESTCONF API.  After discovering the RESTCONF API root, the = DOTS

  = ; client uses this value as the initial part of the path in the = request

  = ; URI, in any subsequent request to the DOTS server.  The DOTS = server

  = ; may support retrieval of the YANG modules it supports (Section 3.7 = in

  = ; [RFC8040]), for example, a DOTS client may use RESTCONF to = retrieve

  = ; the company proprietary YANG modules supported by the DOTS = server.=E2=80=9D

 =

Regards

 =

Jon

 =

__________= _____________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/= mailman/listinfo/dots

<= p class=3DMsoNormal> 

------=_NextPart_000_0187_01D34EA3.9DB1B020-- From nobody Thu Oct 26 13:47:59 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034CE139F5C for ; Thu, 26 Oct 2017 13:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 rM33whTBkSDR for ; Thu, 26 Oct 2017 13:47:56 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0128.outbound.protection.outlook.com [104.47.41.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B21139564 for ; Thu, 26 Oct 2017 13:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6CPBddwL/+K8h5M0QjAyzNr7MC4ONq2sBgm5S0ltHQc=; b=A2+ykUDXd1+0RHWzR5jgcqEaF0nPQhkAhxQqN4ncdGgpD3LHP65yEcP+MwIAZ8/zyEoNiXOmqFYnFZ757W9PQLK9QNmEAD5xX0WPo7emFK55K0xDVrWRWpqGwizqtPfRprLmeQ6iTXp5bD1a6NfdNPNs5QBsTwWm8ipNrsDIfvY= Received: from [172.19.254.109] (184.82.228.32) by CY1PR0101MB1036.prod.exchangelabs.com (10.160.225.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 26 Oct 2017 20:47:52 +0000 From: "Roland Dobbins" To: dots@ietf.org Date: Fri, 27 Oct 2017 03:47:38 +0700 Message-ID: <8D7017D9-3C59-4CBE-84A0-0023ABA4D525@arbor.net> In-Reply-To: <017001d34e9a$000d7b50$002871f0$@jpshallow.com> References: <017001d34e9a$000d7b50$002871f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) X-Originating-IP: [184.82.228.32] X-ClientProxiedBy: SG2PR0601CA0014.apcprd06.prod.outlook.com (10.170.128.24) To CY1PR0101MB1036.prod.exchangelabs.com (10.160.225.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7124fdc3-a591-4696-7f50-08d51cb2d485 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603238); SRVR:CY1PR0101MB1036; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 3:tBB2Ua0t+ysW5ztr3Dvos0ZBjBqNLzluVXt+NvqVIKC2Zf9/nBP0u+ilcJItAATnbLLeEykmmjWPcIet1FxWhWKMZVRQmX2IhN3+H8V05Zd51h3AbEYGxrBWcsTuJQrMLjhHu6k7Q6NkwSdRxXdnym7jfgtsnVyvfKfA+HK5TgXmNwMz+vPj1yuOxcj1YmgGVzo+pBJ+kmk1ACDzA7kwgf2xfxcda71Vb/5FbhEnuTpVu1NjJZsZ/1ItximqGVTD; 25:YziSMTzVIjM1JqaIkV+kZN0oZoEtNioZnwU/nELPj/SoDhceJxpKoACAS6Rpq3AFLXFMxokjycakbjYpgVq4DmSPZSE7DMQQjAejOlKtTvIq+2p50RwopHb6LN4qbBmtKrDhc0P/gHwFduB7fN+fKx9KBHnHfY+awcPomENKPs2c6/PMpYskn9pK8lT2r8rt0ipAukS1i/L6u8wouG49L2QnPqWbjXWgxAyS84tdTrGWsY31dqfQ9RlfnO5FkCDyns/5+u7PQT74LrWypfStqYWgAdyhu+w3IzX0GSxou742Ibh3UfTvmgKhuLoHiIFCpXQRRsLptGX5lJ/ziGg7wg==; 31:Oz3/5Rc+RR59WaTQOYIcIJ7UMKmKg1jXK4+V6BkGzWUKQ5Z8Uxmo7YVu9DFbH4W0f2f2/YwH03V7pu8JpoXhL9Q0sQ2dK/FJ63UYTjdyesabhW/0BBcpM951VfwqYoaDcY1yal7GhoylNnI4E3JzLKRWWwxMwxy5Bws2gfP8P61Gj3w4xTija3TmVCTUW9CUCidbxWz9iXTnr5bTrC+HN3eImAIOhYp/jNR0ZzQg8Dw= X-MS-TrafficTypeDiagnostic: CY1PR0101MB1036: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 20:cuYrn9stYUt4uoP1M3vd75QoCtffa/0hoz/tGPI4wbsA1R8GmACTCYStChXwxR1j7sBbqKIL727B3U3jvIsiox4FhCatW88VvKlQ7K5GN+CbaLE6ZQ90CBXWGNxOkMkMMlIGIuzZaP/o7DmEjfqcQlKEE1/AsRzfW16WZyZfoRsqTow2ZbcNcaetgA/y8HIj/qZ5nMhEtvjmycXYN9fT6fOD0shQ5lsYII0DHSIHPk09RoLY4TAD1hPOTaE5rwDYIXkKhMP/QziIU8ctsxdKwj0qvrLb9guydN3W5zp8zfg70fu6j5SjVw3eAM0Av09R+Uv9IUaxoqiw521NHsnPonFxDfbRAu63N2mWR4FXlbGRU58EBeoOgD2LWL7FE4AqSdGLo5pwiTQNfjooSxyEGaFpggMEXhahwO6oGRDp0MQiKhX8Kz4i7QkAHkvmUQilwQ2gFxWRb964jALXEvoZuIQWogymUnOu+zQI/F88YXa3ol5rY2VpZhhyziuJpHeU; 4:TbU6CSe5gp6nHfZsF0jdDM+EMxJu8caZmQrvTn94lRM8pp0DVxyyT1pi6gHqxpO0nIhxRtgaais0gm3OJBxVJwT4dDc6DDK4xx2nFHwCzGYSRVrZROLLg1tWkcmKp72QLFG84duE+KmG5PB6ewyDA66xdZzVPJHSWZqT/NFixTKChDnR+4VStM7EcjCnC7MD91vMAPc1xfs3G/B16EC3YuavlvjfhXNrIObccGbed8cAXj59VYPW7Vixxy0A2ejuHsWxfW6MsoY6A1N7sFy0zkQ3A0lb/nA/EvD0OoOAYxs= X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231020)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0101MB1036; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0101MB1036; X-Forefront-PRVS: 04724A515E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(376002)(346002)(199003)(189002)(24454002)(105586002)(82746002)(53546010)(33656002)(47776003)(16576012)(97736004)(5003940100001)(305945005)(316002)(189998001)(50466002)(2361001)(5660300001)(7736002)(478600001)(3846002)(16586007)(25786009)(86362001)(2950100002)(6666003)(6246003)(50986999)(6486002)(2351001)(6916009)(36756003)(229853002)(90366009)(76176999)(6116002)(2906002)(50226002)(101416001)(77096006)(68736007)(8676002)(81156014)(83716003)(81166006)(66066001)(16526018)(8936002)(53936002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB1036; H:[172.19.254.109]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1036; 23:YStC+yl286w9dGk9OcxyjgGJiSOMqOhrIp1p4wZ?= =?us-ascii?Q?uwoTqcHDJQPEVCPkauqmExWolwRKBIAGXsH2w9+yz9abiTmADjY6Fn/vOMU/?= =?us-ascii?Q?gCq/m3w1u9VMVXQjuOO1kafirxMEFyc2AgU4POO0UPKSslagq0j1Y64DDT+7?= =?us-ascii?Q?mx/wwIX1wlnPgMxG8UgVFCMg+FcBi+37gSR6uDlxrUUtTKi3GLIYAvxBzaoF?= =?us-ascii?Q?S8NgWSsCsLLsAxltCSqxnCfDJASzalbvph4tkrOxttVVTeT4SG7fL1Ukf1XH?= =?us-ascii?Q?+Ixkh0TgGTkrI/YvYDRwJC4WtDfzZVrVUWCoLliGzOP9t4iAi4yFK85xnfit?= =?us-ascii?Q?i0JZy+ihs5+Z6NjL4INjWOw+sLBDfYCzFVLL5ENASFVVJMBTf6HOKm4rGr3c?= =?us-ascii?Q?iTsMLQu9YDmNGsuLm+OqBWfVhe3REuUYG+cJkwZ/HGWD/Cd8VQ2sXC98PdBO?= =?us-ascii?Q?+t+ZKAFdMeoY5zeb+enUzrMK+SPDMUdu9e98tUpxujrEqAVCXocrzTOln8Dm?= =?us-ascii?Q?q5gYfKrEfADsG4gLHKoA4m77FixBiLBjfzp6s0ld1cPNcJ4o23QmbvhB6xhI?= =?us-ascii?Q?MBa8/lphZU/8YqV+RzG3L+XqdXQ4I3JRsPgURzimsr8c8TJ6XIhkW18ZvQOb?= =?us-ascii?Q?tSrBV6zR2eTgoS/SAxN1D5vLXurJ6qDFuW1D8KRPgaizF8fXZuB7jqjBROKs?= =?us-ascii?Q?CMLT1g5dULv8i6ywEsD8v4CWOFY6Oq3R4dEhtE4KoLpnS+/8x1ZwyVC/u3rm?= =?us-ascii?Q?87rQj5GnChdaJJn2ULj/A5WJdFzWY8AZAH06UgT4W4VTxjvyoYtqkXFlzwF2?= =?us-ascii?Q?EF8wZpqhixcuG9z4CIV2Mw2wWbkv7nQIlQO/Hn7V/Dg58w4P+vdP8fVj95IB?= =?us-ascii?Q?c0B/jhm9BBzTeRlZfOkA7DSfVy2IOaGyPAmvq0gkh0YTNyAZQv188YYNb7Qo?= =?us-ascii?Q?mETyrDYcO05bgZv8ZbcizjX8MGr16tWMAEVJiCgPuI/mdhbEj+VfCWZ9EbzB?= =?us-ascii?Q?6gt9PT4BnZz5o+Xw3H+0H3pryKtdky9aSp2ffeKoxyUyKWmuTP2pDzPD8wm5?= =?us-ascii?Q?pdMwvt0g6WODUx/Arrk6BU33WGZCE447aUYnke8KxjfNJ969K+mPUuiyJ6eP?= =?us-ascii?Q?73YWxmejHI/cx2ckxKI7bk71Q5pTlNgKiYBYAy8iulMPKOUJ+8/6qOnei4go?= =?us-ascii?Q?K9iy0WB5GUcPZIWO7gJ0tD20A5ckQO/XvXK37+x/OyKo9cKfbtTs84C1nRA?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1036; 6:NkW+gUf6oNEfqhNkkj3nZTGKNP+g3EcCVyF5xJMVCa8FbHzVFgQX05u1b+634i+QE5heHgRxt76O8xznUqb/FUbs955/dkvJESRFKlGtMzJ31PgIui2/S4k1M0qLr3zB6/eyg/w+hv8ZOnfqt8ZvPPPpTWq/3JYvO6G7yBB0derzHNYy9V10y/vcy0afW6R/83xLohsTQSlOaEbwZ+rbsHNlAfY1dDlAxPzobjcWyN6LtnwnHdoWHuJOGHy8c42ZKPZbjwBs0nayTblsprRsygSTg1MK8A2P4T9V8pYWcIfl9H3gZSZFLKM+mnNCAFVWSED5WcsMUAKYr9Ysrx828w==; 5:GQzMMwJ+yGoLSkCL9CNN70gOwXluN239jNoCIixRdkhbHcMDRxV1ner5+oonK041m0G9jKb/N+9q+IUqTdcTY9fbZOmfrCmgBGr5x+wxPShqpHrNTktJVkEfBVsUJCS3HBNuqA8sAmceWsAZOZcMHA==; 24:EwOG+NVGD9BtxmLPNohoWsXwTISjXadELJn3jM9zfqPvuugyUrVyi95yS3ChhRDi6TPXpYBzRg5s4KZS1+CySb1CiHW8w8joVC99l5bIuBM=; 7:dAv/JrLw1Y3VN3qIdN1NsBQg9fp9fIjbMuQyD1qdy3rV1XD6mSQZANKDGII1FHfE3dynfqUvVKeES0VvE2hAhOl3DPLkoPqxyoJD7S7rut+dksmrkoNB6lxrZ0aBHtpasDN267+QHA0+d10WUpZU5U2+Kbo7G4OzQzCqPYqHBpGHekPEeF9n6gfn9QJmvSp8D7kNupg6umQGa4RnQD8Li3rw2ao9A3H8Ytfq2TF21ww= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2017 20:47:52.7130 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7124fdc3-a591-4696-7f50-08d51cb2d485 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1036 Archived-At: Subject: Re: [Dots] Full Pipe Scenario X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 20:47:58 -0000 On 27 Oct 2017, at 3:35, Jon Shallow wrote: > Should the DOTS client continue to send Heartbeats after the DOTS > client has > determined the session has 'Heartbeat Failed' - so that that the DOTS > server > is kept "warm" in case a mitigation request has to blindly be sent. Yes. ----------------------------------- Roland Dobbins From nobody Thu Oct 26 22:49:28 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2411389BC for ; Thu, 26 Oct 2017 22:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugod4ig2oNej for ; Thu, 26 Oct 2017 22:49:24 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE9C138BE2 for ; Thu, 26 Oct 2017 22:49:24 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 7783BC08B9; Fri, 27 Oct 2017 07:49:22 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 5809B1A0066; Fri, 27 Oct 2017 07:49:22 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0361.001; Fri, 27 Oct 2017 07:49:22 +0200 From: To: Flemming Andreasen , Jon Shallow , "dots@ietf.org" Thread-Topic: DOTS & NAT (was RE: [Dots] DOTS Requirements review (-06)) Thread-Index: AQHTTl/MCmEN9U9jFUmHTeWk5x/erqL3MSIw Date: Fri, 27 Oct 2017 05:49:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05F016@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <04fc065f-9657-bfcf-fdc4-4fe75da92cfc@cisco.com> <787AE7BB302AE849A7480A190F8B93300A05A87B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 05:49:26 -0000 SGkgRmVsbW1pbmcsIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEZsZW1taW5nIEFuZHJlYXNlbiBb bWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbV0NCj4gRW52b3nDqcKgOiBqZXVkaSAyNiBvY3RvYnJl IDIwMTcgMTU6MzkNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgSm9uIFNoYWxs b3c7IGRvdHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IERPVFMgJiBOQVQgKHdhcyBSRTogW0Rv dHNdIERPVFMgUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KSkNCj4gDQo+IA0KPiANCj4gT24gMTAv MjQvMTcgNDo1MCBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPiBI aSBGbGVtbWluZywgYWxsLA0KPiA+DQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4NCj4gPiBD aGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ ID4+IERlwqA6IEZsZW1taW5nIEFuZHJlYXNlbiBbbWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbV0N Cj4gPj4gRW52b3nDqcKgOiBsdW5kaSAyMyBvY3RvYnJlIDIwMTcgMTc6MzYNCj4gPj4gw4DCoDog Qk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgSm9uIFNoYWxsb3c7IGRvdHNAaWV0Zi5vcmcNCj4g Pj4gT2JqZXTCoDogUmU6IERPVFMgJiBOQVQgKHdhcyBSRTogW0RvdHNdIERPVFMgUmVxdWlyZW1l bnRzIHJldmlldyAoLTA2KSkNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT24gMTAvMjMvMTcgODoy OCBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPj4+IEhpIEpvbiwg YWxsLA0KPiA+Pj4NCj4gPj4+IEkgYWdyZWUgd2l0aCBGbGVtbWluZyB0aGF0ICJzb21lIG1vcmUg d29yayIgaXMgbmVlZGVkLiBJTUhPLCB0aGlzIGlzIGENCj4gPj4gdHlwaWNhbCBkaXNjdXNzaW9u IHRvIGluY2x1ZGUgaW4gYSBkZWRpY2F0ZWQgc2VjdGlvbiBpbiB0aGUgRE9UUw0KPiA+PiBhcmNo aXRlY3R1cmUgSS1ELg0KPiA+PiBBZ3JlZWQuDQo+ID4+PiA+RnJvbSBhIHJlcXVpcmVtZW50IHN0 YW5kcG9pbnQsIHdlIGRvbid0IG5lZWQgdG8gZWxhYm9yYXRlIGhvdyB0aGUNCj4gPj4gcHJvdG9j b2xzIHdpbGwgZnVsZmlsIGl0LiBTSUctMTAgZG9lcyBldmVuIGEgbmljZSBqb2IgYnkgY2l0aW5n IFJGQzgwODUNCj4gPj4gd2hpY2ggcG9pbnRzIHRvIE5BVCB0cmF2ZXJzYWwgbWVjaGFuaXNtcy4g T25lIGNvdWxkIHBpY2sgaGlzL2hlcg0KPiBmYXZvcml0ZQ0KPiA+PiBwcm90b2NvbCBmcm9tIHRo ZSBsaXN0IGluIDgwODUgdG8gZGlzY292ZXIgdGhlIGV4dGVybmFsIElQDQo+IGFkZHJlc3MvcHJl Zml4LA0KPiA+PiBpZiBuZWVkZWQuIEV4dGVybmFsIElQIGFkZHJlc3Nlcy9wcmVmaXhlcyBjYW4g YmUgSVB2NCBmb3IgYSBOQVQ0NCBvcg0KPiA+PiBOQVQ2NCwgYnV0IGNhbiBiZSBJUHY2IHByZWZp eGVzIGZvciBlbnRlcnByaXNlcyBkZXBsb3lpbmcgTlBUdjYsIGFuZCBzbw0KPiA+PiBvbi4NCj4g Pj4gUGFydCBvZiB0aGUgY2hhbGxlbmdlIGhlcmUgaXMgdGhhdCB0aGUgYXR0YWNrIHRhcmdldCBh bmQgdGhlIERPVFMNCj4gY2xpZW50DQo+ID4+IGFyZSBub3QgbmVjZXNzYXJpbHkgb25lIGFuZCB0 aGUgc2FtZSwgd2hpY2ggbWFrZXMgaXQgbW9yZSBkaWZmaWN1bHQgdG8NCj4gPj4gZGV0ZXJtaW5l IHRoZSBwdWJsaWMtZmFjaW5nIElQLWFkZHJlc3MvcG9ydCB1bmRlciBhdHRhY2sgKGF0IGxlYXN0 IGlmDQo+ID4+IHRoZSBET1RTIGNsaWVudCBpcyBnb2luZyB0byBkbyBpdCkuDQo+ID4gW01lZF0g VGhpcyBpcyBleGFjdGx5IHRoZSBraW5kIG9mIHRoZSBkaXNjdXNzaW9uIHRvIGhhdmUuIFRoYW5r cy4NCj4gPg0KPiA+IFdpdGggb3Igd2l0aG91dCBOQVQsIERPVFMgY2xpZW50cyBhcmUgYXNzdW1l ZCB0byBiZSBmZWQgd2l0aCB0aGUNCj4gaW50ZXJuYWwgdGFyZ2V0KHMpLiBUaGlzIGNhbiBiZSBh Y2hpZXZlZCBieSBwcm92aXNpb25pbmcgKGxpa2VseSkgb3IgYnkNCj4gZGlzY292ZXJ5IG1lYW5z IChlLmcuLCByZXNpZGVudGlhbCBvciBzbWFsbCBlbnRlcnByaXNlIG5ldHdvcmtzKS4NCj4gPg0K PiA+IENhbiB3ZSBhc3N1bWUgdGhhdCB0aGUgZGlzY292ZXJ5IG9mIHRoZSBleHRlcm5hbCBJUCBh ZGRyZXNzL3ByZWZpeC8uLiBpcw0KPiBkb25lIGJ5IGEgRE9UUyBjbGllbnQgb25seSBpZiBpdCBp cyBleHBsaWNpdGx5IGluc3RydWN0ZWQgdG8gZG8gc28/DQo+ID4NCj4gU2VlbXMgcmVhc29uYWJs ZSwgaG93ZXZlciBoYXZpbmcgdGhlIERPVFMgY2xpZW50IGluc3RlYWQgb2YgdGhlIGF0dGFjaw0K PiB0YXJnZXQgZG9pbmcgdGhlIGRpc2NvdmVyeSBtYXkgbm90IGFsd2F5cyB3b3JrLg0KDQpbTWVk XSBBZ3JlZS4gVGhpcyBpcyBkZXBsb3ltZW50LXNwZWNpZmljLiBUaGUgY2xpZW50IHdpbGwgZG8g c28gb25seSBpZiBpdCBpcyAiZXhwbGljaXRseSBpbnN0cnVjdGVkIi4NCg0KPiA+Pj4gSW4gc29t ZSBkZXBsb3ltZW50cywgRE9UUyBjbGllbnRzIG1heSBiZSBwcm92aXNpb25lZCB3aXRoIHRoZSBz ZXQgb2YNCj4gPj4gaW50ZXJuYWwgcmVzb3VyY2VzLCBzbyB0aGVyZSBpcyBubyBuZWVkIGZvciBk aXNjb3ZlcnkuDQo+ID4+PiBBbHNvLCBhcyBKb24gbWVudGlvbmVkLCBET1RTIGdhdGV3YXlzIGNh biBiZSBvZiBoZWxwIHRvIHNldCB0aGUNCj4gPj4gYXBwcm9wcmlhdGUgSVAgYWRkcmVzc2VzL3By ZWZpeGVzL3BvcnQgbnVtYmVycyBpbiB0aGUgcHJlc2VuY2Ugb2YNCj4gPj4gdHJhbnNsYXRvcnMu DQo+ID4+IEFncmVlZCAtIGJ1dCB0aGV5IHN0aWxsIG5lZWQgYSB3YXkgdG8gZmlndXJlIG91dCB0 aGUgcHJpdmF0ZS9wdWJsaWMNCj4gPj4gbWFwcGluZyBmb3IgYSBnaXZlbiBhdHRhY2sgdGFyZ2V0 Lg0KPiA+IFtNZWRdIEJlY2F1c2UgYSBERG9TIGF0dGFjayBpcyBvYnNlcnZlZCBmcm9tIHRoZSBp bnRlcm5hbCBuZXR3b3JrLA0KPiBtYXBwaW5nKHMpIGFyZSBuZWNlc3NhcmlseSBtYWludGFpbmVk IGJ5IHRoZSBvbi1wYXRoIHRyYW5zbGF0b3IocykuDQo+IE90aGVyd2lzZSwgdGhlIGluY29taW5n IGF0dGFjayB0cmFmZmljIGNvdWxkbid0IGJlIGZvcndhcmRlZCB0byBpbnRlcm5hbA0KPiBob3N0 cy4NCj4gPiBUaGlzIG1vZGVsIGFzc3VtZXMgdGhhdCB0aGUgZ2F0ZXdheSBpcyBjb2xsb2NhdGVk IHdpdGggdGhlIE5BVC4gU28sIHRoZQ0KPiBnYXRld2F5IGNhbiByZXBsYWNlIHRoZSBpbnRlcm5h bCBJUCBhZGRyZXNzL3ByZWZpeCB3aXRoIHRoZSBvbmUgcmV0cmlldmVzDQo+IGZyb20gdGhlIE5B VCBtYXBwaW5nIHRhYmxlLg0KPiA+DQo+ID4gRG8geW91IHNlZSBhbnkgaXNzdWUgd2l0aCB0aGlz IHNjaGVtZT8NCj4gUmVxdWlyaW5nIGNvLWxvY2F0aW9uIG9mIHRoZSBET1RTIGdhdGV3YXkgYW5k IHRoZSBOQVQgc2VlbXMgbGlrZSBhDQo+IHNpZ25pZmljYW50IG9ic3RhY2xlIHRvIHJlYWwtbGlm ZSBkZXBsb3ltZW50Lg0KPiANCg0KW01lZF0gQWdhaW4sIHRoaXMgaXMgb25lIGRlcGxveW1lbnQg bW9kZWwgYW1vbmcgb3RoZXJzLiBUaGUgaW50ZW50IGlzIG5vdCB0byByZXF1aXJlIGl0LCBidXQg Y29uc2lkZXIgdGhhdCB0aGlzIG1vZGVsIG1heSBleGlzdC4gDQoNCj4gPj4+IEFuIG9wZW4gcXVl c3Rpb24gdGhvdWdoIHdvdWxkIGJlIHRvIGRpc2N1c3MgaWYgdGhlcmUgaXMgYSB2YWx1ZSBpbg0K PiA+PiBoYXZpbmcgYSBmZWF0dXJlIGluIHRoZSBET1RTIHByb3RvY29sIHRvIGluZm9ybSBhIERP VFMgY2xpZW50IHRoYXQgYQ0KPiBOQVQNCj4gPj4gaXMgZGV0ZWN0ZWQgb24tcGF0aC4gVGhpcyBj YW4gYmUgcHJlc2VudGVkIGFzIGFuIGluZm9ybWF0aW9uIGVsZW1lbnQNCj4gPj4gcmV0dXJuZWQg YnkgdGhlIHNlcnZlciB0byB0aGUgY2xpZW50LiBUaGlzIGluZm9ybWF0aW9uIGNhbiBiZSwgZm9y DQo+ID4+IGV4YW1wbGUsIHVzZWQgYnkgdGhlIGNsaWVudCB0byBhZGp1c3QgaXRzIEhUIGludGVy dmFsLCBhZGp1c3QgdGhlDQo+IGludGVybmFsDQo+ID4+IElQIGFkZHJlc3Nlcy9wcmVmaXhlcyB0 byBiZSBwcm90ZWN0ZWQsIGV0Yy4gT3BpbmlvbnM/DQo+ID4+IEl0IHNvdW5kcyBhcHBlYWxpbmcs IGJ1dCBpdCdzIHZlcnkgZGlmZmljdWx0IHRvIGRvIHRoaXMgcmVsaWFibHksIGFuZA0KPiA+PiBp dCdzIG5vdCBqdXN0IE5BVHMgdGhhdCBhcmUgYW4gaXNzdWUgaGVyZTsgRmlyZXdhbGxzIHByZXNl bnQgc2ltaWxhcg0KPiA+PiBjaGFsbGVuZ2VzIChhbmQgdGhleSBtYXkgb3IgbWF5IG5vdCBiZSBO QVQnaW5nIGluZGl2aWR1YWwgZmxvd3MpLg0KPiA+Pg0KPiA+IFtNZWRdIEkgZnVsbHkgYWdyZWUg dGhhdCBmaXJld2FsbHMgZGV0ZWN0IGlzIG1vcmUgY29tcGxleC4gTGV0J3MgcHV0IGl0DQo+IGFz aWRlIGFuZCBmb2N1cyBvbiB0aGUgTkFUIGNhc2UuDQo+ID4NCj4gPiBXZSBjYW4gY29uc2lkZXIg bWFueSBhcHByb2FjaGVzIHRvIGRldGVjdCBhIE5BVCwgZS5nLiwNCj4gPg0KPiA+ICgxKSBUaGUg RE9UUyBjbGllbnQgaW5zZXJ0cyBpbiB0aGUgY29yZSBtZXNzYWdlIHRoZSBJUCBhZGRyZXNzL3Bv cnQgaXQNCj4gdXNlcyB0byBzZW5kIHRoZSByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4gVXBv biByZWNlaXB0IG9mIHRoZSByZXF1ZXN0DQo+IGJ5IHRoZSBET1RTIHNlcnZlciwgaXQgY2hlY2tz IGlmIHRoZSBlbmNsb3NlZCBJUCBhZGRyZXNzL3BvcnQgbWF0Y2ggdGhlDQo+IHNvdXJjZSBJUCBh ZGRyZXNzL3BvcnQgb2YgdGhlIHJlY2VpdmVkIHBhY2tldC4gSWYgeWVzLCB0aGUgc2VydmVyIHNl dHMgaW4NCj4gdGhlIHJlc3BvbnNlIGEgZGVkaWNhdGVkIHBhcmFtZXRlciB0byBpbmRpY2F0ZSB0 aGF0IGEgdHJhbnNsYXRvciBpcw0KPiBkZXRlY3RlZCBvbi1wYXRoLg0KPiA+DQo+ID4gKDIpIFRo ZSBET1RTIHNlcnZlciBpbnNlcnRzIHN5c3RlbWF0aWNhbGx5IHRoZSBzb3VyY2UgSVAgYWRkcmVz cy9wb3J0IGluDQo+IGEgcmVzcG9uc2UgdG8gYSBtZXNzYWdlIGZyb20gYSBET1RTIGNsaWVudC4g VXBvbiByZWNlaXB0IG9mIHRoYXQgcmVzcG9uc2UsDQo+IHRoZSBET1RTIGNsaWVudCBjb21wYXJl cyB0aGUgZW5jbG9zZWQgYWRkcmVzcy9wb3J0IHdpdGggdGhlIG9uZXMgaXQgdXNlZA0KPiB0byBz ZW5kIHRoZSByZXF1ZXN0IHRvIGRldGVjdCBhbnkgbWlzbWF0Y2guDQo+IFdlIHdpbGwgcHJvYmFi bHkgZW5kIHVwIHJlaW52ZW50aW5nIFNUVU4gYmVmb3JlIHdlIGFyZSBkb25lLCBzbyBJJ2QNCj4g cmF0aGVyIGxldmVyYWdlIHRoYXQuDQo+IA0KPiBUaGFua3MNCj4gDQo+IC0tIEZsZW1taW5nDQo+ IA0KPiA+DQo+ID4+IC0tIEZsZW1taW5nDQo+ID4+DQo+ID4+DQo+ID4+PiBDaGVlcnMsDQo+ID4+ PiBNZWQNCj4gPj4+DQo+ID4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+Pj4g RGXCoDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBK b24gU2hhbGxvdw0KPiA+Pj4+IEVudm95w6nCoDogbHVuZGkgMjMgb2N0b2JyZSAyMDE3IDEzOjE4 DQo+ID4+Pj4gw4DCoDogJ0ZsZW1taW5nIEFuZHJlYXNlbic7IGRvdHNAaWV0Zi5vcmcNCj4gPj4+ PiBPYmpldMKgOiBSZTogW0RvdHNdIERPVFMgUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KQ0KPiA+ Pj4+DQo+ID4+Pj4gSGkgRmxlbW1pbmcsDQo+ID4+Pj4NCj4gPj4+PiBUaGUgd2F5IG15IG1pbmQg d29ya3MgaXMgdG8gdGhpbmsgb2YgYSBwcmFjdGljYWwgc2l0dWF0aW9uIGFuZCBzZWUgaWYNCj4g Pj4+PiB0aGluZ3MgZml0Lg0KPiA+Pj4+DQo+ID4+Pj4gQXMgSSByZWFkIFNJRy0wMTAsIHRoZXJl IGNvdWxkIGJlIGEgRE9UUyBjbGllbnQgd2l0aCBhIG1hbmFnZW1lbnQgSVANCj4gPj4+PiBhZGRy ZXNzIHRoYXQgaXMgUkZDMTkxOCAtIHRoaXMgY2xpZW50IGNvdWxkIGJlIG1vbml0b3JpbmcgTmV0 Zmxvdw0KPiA+Pj4+IGluZm9ybWF0aW9uIGFuZCBjYW4gcmVxdWVzdCBtaXRpZ2F0aW9uIGZvciB0 aGUgYXBwcm9wcmlhdGUgcHVibGljIElQcw0KPiA+PiB0aGF0DQo+ID4+Pj4gYXJlIGJlaW5nIG1v bml0b3JlZC4gIFNvIFNJRy0wMTAgaXMgbmVlZGVkIGZvciB0aGlzIHVzZSBjYXNlLg0KPiA+Pj4+ DQo+ID4+Pj4gSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBET1RTIHNlcnZlciBhcyB0 byB3aGV0aGVyIGl0IGFjY2VwdHMNCj4gYQ0KPiA+Pj4+IG1pdGlnYXRpb24gcmVxdWVzdCBmb3Ig YSBwYXJ0aWN1bGFyIHRhcmdldCBpcCAob3IgZG9tYWluIGV0Yy4pIG9yDQo+IG5vdC4NCj4gPj4+ Pg0KPiA+Pj4+IElmIHRoZXJlIGlzIGdvaW5nIHRvIGJlIGEgTkFUIGJvcmRlciB3aGVyZSBwdWJs aWMgSVBzIGFyZSBtYXBwZWQgaW50bw0KPiA+Pj4+IHByaXZhdGUgSVBzIChhbmQgdmljZSB2ZXJz YSksIEkgd291bGQgdGhlbiBleHBlY3QgdGhlcmUgdG8gYmUgYSBET1RTDQo+ID4+Pj4gZ2F0ZXdh eSBiZXR3ZWVuIHRoZXNlIDIgem9uZXMsIGFuZCBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2Yg dGhlDQo+IERPVFMNCj4gPj4+PiBnYXRld2F5IHRvIGRvIGFueSB0YXJnZXQtaXAgbWFwcGluZ3Mu DQo+ID4+Pj4NCj4gPj4+PiBSZWdhcmRzDQo+ID4+Pj4NCj4gPj4+PiBKb24NCj4gPj4+Pg0KPiA+ Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogRG90cyBbbWFpbHRv OmlldGYtc3VwanBzLWRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4+Pj4g RmxlbW1pbmcgQW5kcmVhc2VuDQo+ID4+Pj4gU2VudDogMjIgT2N0b2JlciAyMDE3IDIwOjE3DQo+ ID4+Pj4gVG86IGRvdHM7IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHNAaWV0Zi5vcmcNCj4g Pj4+PiBTdWJqZWN0OiBbRG90c10gRE9UUyBSZXF1aXJlbWVudHMgcmV2aWV3ICgtMDYpDQo+ID4+ Pj4NCj4gPj4+PiBHcmVldGluZ3MNCj4gPj4+Pg0KPiA+Pj4+IEkgaGF2ZSByZXZpZXdlZCB0aGUg bGF0ZXN0IHZlcnNpb24gb2YgdGhlIERPVFMgcmVxdWlyZW1lbnRzIGRyYWZ0DQo+ID4+Pj4gKGh0 dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMDYudHh0 KS4gSW4NCj4gPj4gZ2VuZXJhbCwNCj4gPj4+PiBJIHRoaW5rIHRoZSBkcmFmdCBpcyBpbiBnb29k IHNoYXBlIHdpdGggb25seSBhIGZldyBlZGl0cyByZXF1aXJlZCwgc28NCj4gSQ0KPiA+Pj4+IGhv cGUgd2UgY2FuIG1vdmUgdG8gV0dMQyBzb29uLiBJIGhhdmUgYSBmZXcgY29tbWVudHMgYmVsb3cg KG9mIHdoaWNoDQo+ID4+IHRoZQ0KPiA+Pj4+IE5BVCBvbmUgaXMgdGhlIG9ubHkgcmVhbCBzdWJz dGFudGlhbCBvbmUpLiBJIGhhdmUgYWxzbyBzdWJtaXR0ZWQgYQ0KPiBwdWxsDQo+ID4+Pj4gcmVx dWVzdCB3aXRoIGEgZmV3IG5pdCBmaXhlcyBvbiBHaXRIdWI6DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+ Pj4+IFNlY3Rpb24gMS4yDQo+ID4+Pj4gLSBUaGUgZGVmaW5pdGlvbiBvZiAiRE9UUyBTaWduYWwi IGlzIHNsaWdodGx5IGluY29uc2lzdGVudCB3aXRoIHRoZQ0KPiA+Pj4+IHJlc3BlY3RpdmUgIkNs aWVudCBTaWduYWwiIGFuZCAiU2VydmVyIFNpZ25hbCIgZGVmaW5pdGlvbnMuDQo+ID4+Pj4NCj4g Pj4+PiBTSUctMDA1Og0KPiA+Pj4+IC0gTm90IGNsZWFyIHRoYXQgYWx3YXlzIHJlcXVpcmluZyAi bnVtYmVyIG9mIHBhY2tldHMiIG1ldHJpY3MgaXMNCj4gPj4+PiBtZWFuaW5nZnVsLiBDb25zaWRl ciBUQ1AtYmFzZWQgYXR0YWNrcyBmb3IgZXhhbXBsZS4gTnVtYmVyIG9mIGJ5dGVzDQo+IG1heQ0K PiA+Pj4+IGFsd2F5cyBiZSBvayAtIGFib3ZlIGFuZCBiZXlvbmQgdGhhdCBpdCBzaG91bGQgcHJv YmFibHkgYmUgZXh0ZW5zaWJsZQ0KPiA+Pj4+IGFuZC9vciBhdHRhY2sgZGVwZW5kZW50Lg0KPiA+ Pj4+IC0gSSBkb24ndCB0aGluayB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50IHNob3VsZCBnZXQg aW50byBzcGVjaWZ5aW5nDQo+ID4+IHRpbWVyDQo+ID4+Pj4gdmFsdWVzIC0gZXhwb250aWFsIGJh Y2tvZmYgd2l0aCBzb21lIG1heGltdW0gdmFsdWUgc2VlbXMgYWJvdXQgdGhlDQo+ID4+IHJpZ2h0 DQo+ID4+Pj4gbGV2ZWwgb2YgZGV0YWlsIGhlcmUuDQo+ID4+Pj4NCj4gPj4+PiBTSUctMDA5Og0K PiA+Pj4+IC0gVG8gYmUgY2xlYXIsIHRoZSBjb25mbGljdHMgb25seSBhcHBseSB3aXRoaW4gYSBz aW5nbGUNCj4gYWRtaW5pc3RyYXRpdmUNCj4gPj4+PiBkb21haW4sIHJpZ2h0ID8gRm9yIGV4YW1w bGUsIGlmIGEgY2xpZW50IHRlbGxzIHRoZSBzYW1lIGRvbWFpbiB0bw0KPiA+Pj4+IGFsdGVybmF0 ZWx5IHR1cm4gb24vb2ZmIG1pdGlnYXRpb24gZm9yIGEgZ2l2ZW4gcHJlZml4LCByb3V0ZSBmbGFw cGluZw0KPiA+PiBtYXkNCj4gPj4+PiBvY2N1ci4gVGhlIHNhbWUgY29uY2VybiBkb2VzIG5vdCBh cHBseSBpZiBhIGNsaWVudCB0ZWxscyB0d28NCj4gZGlmZmVyZW50DQo+ID4+Pj4gYWRtaW5pc3Ry YXRpdmUgZG9tYWlucyB0byByZXNwZWN0aXZlIHR1cm4gbWl0aWdhdGlvbiBvbiAoZG9tYWluIDEp DQo+IGFuZA0KPiA+PiBvZmYNCj4gPj4+PiAoZG9tYWluIDIpLiBJZiBzbywgY2FuIHdlIGNsYXJp ZnkgdGhhdCAoYWxzbyBpbiBsaWV1IG9mIHNvbWUgb2YgdGhlDQo+ID4+IG11bHRpLQ0KPiA+Pj4+ IGhvbWluZyBjb21tZW50cyByYWlzZWQgcHJldmlvdXNseSkgPw0KPiA+Pj4+DQo+ID4+Pj4gU0lH LTAxMDoNCj4gPj4+PiAtIERPVFMgQ2xpZW50IGJlaGluZCBOQVQuIE9uIG9uZSBoYW5kLCBpdCBz ZWVtcyByZWFzb25hYmxlIHRvIGhhdmUNCj4gdGhpcw0KPiA+Pj4+IHJlcXVpcmVtZW50IHNpbmNl IGNsaWVudHMgZm9yIHN1cmUgY2FuIGJlIGJlaGluZCBOQVRzLCBhbmQgd2l0aA0KPiB0aGluZ3MN Cj4gPj4+PiBsaWtlIGR5bmFtaWMgRE5TLCB0aGV5IGNhbiAgICAgY2VydGFpbmx5IGJlIHJlYWNo YWJsZS4gSG93ZXZlciwgaWYgd2UNCj4gPj4gZG8NCj4gPj4+PiB3YW50IHRvIGFsbG93IGZvciB0 aGlzIHNjZW5hcmlvLCBhbmQgaW4gcGFydGljdWxhciBmb3IgdGhlIERPVFMNCj4gY2xpZW50DQo+ ID4+IHRvDQo+ID4+Pj4gaGF2ZSBhIHByaXZhdGUgSVAtYWRkcmVzcyAocG90ZW50aWFsbHkgYmVo aW5kIG11bHRpcGxlIE5BVHMpLCB0aGVuIHdlDQo+ID4+IGhhdmUNCj4gPj4+PiBtb3JlIHdvcmsg dG8gZG8gYmVjYXVzZSBpdCB3b24ndCBkbyB0aGUgRE9UUyBzZXJ2ZXIgYW55IGdvb2QgdG8gZ2V0 IGENCj4gPj4+PiBtaXRpZ2F0aW9uIHJlcXVlc3QgcmVmZXJyaW5nIHRvIHRoYXQgcHJpdmF0ZSBJ UC1hZGRyZXNzIChvciBwcmVmaXgpLg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBUaGFua3MNCj4g Pj4+Pg0KPiA+Pj4+IC0tIEZsZW1taW5nDQo+ID4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+IERvdHMgbWFpbGluZyBsaXN0 DQo+ID4+Pj4gRG90c0BpZXRmLm9yZw0KPiA+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG90cw0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+Pj4+ IERvdHNAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RvdHMNCj4gPj4+IC4NCj4gPj4+DQoNCg== From nobody Thu Oct 26 23:06:40 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFF113AAC7 for ; Thu, 26 Oct 2017 23:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 BH3g0LmAf68B for ; Thu, 26 Oct 2017 23:06:37 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 93DD0139B9F for ; Thu, 26 Oct 2017 23:06:36 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509084395; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=D f2dBCRQdZjUtQGjhAxGc9XplwCDxvrd3lHB7HRNBC I=; b=Buw331pLdVUsguvYshIUTbo2dWRWal7ZhoU4DJs1NJQG 4KSabb/yXHHx1ORbsJ4c28QcsBM2LTw4LsILzZaUbGzYCt8HTE Lpwxnfe3hHhzTJvGEbrmIJPtkz/sl+81Wz8R6jkBopndp933iS w8DqTE+V91V/6P8VX4G3e9Qdn3Q= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 225e_46fb_c6c52702_7257_460a_8c3f_5846102f9840; Fri, 27 Oct 2017 01:06:34 -0500 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 02:06:33 -0400 Received: from MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 02:06:32 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 27 Oct 2017 02:06:32 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 02:06:32 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Fri, 27 Oct 2017 06:06:31 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0156.007; Fri, 27 Oct 2017 06:06:31 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Full Pipe Scenario Thread-Index: AdNOmftpS0b6T9g6S+iNSHMqb5xZmAAPOwUA Date: Fri, 27 Oct 2017 06:06:30 +0000 Message-ID: References: <017001d34e9a$000d7b50$002871f0$@jpshallow.com> In-Reply-To: <017001d34e9a$000d7b50$002871f0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.133.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:l3FO8q4Lwgva7oGJZX9j6HqykN50nQpW4102dvVzLhYGBlupeQ3wJZLyn6lZkRXfUhKO4toq0eBl6GBJVvopncLEqEJGbWRG0t+nNisKjXi9e/oEkyvrrGiA1oUv0rscb6jMkaNb4OyBk5bjMUhbb4Lm0MvYtbZdqVTx86Tp2BPTncA4icd2mhN858FxCK9PwA5ynmV6TE0ooLU7FAMNURf8TOUCqzeYMaa06uZrxnRgokuLon8oiDMdWW0ak8zS1WYZlS+oYhhViaJEU5Z9+Wmj+Fj6iadRiVSlT4534givirXzcXbj45Zvgh9/Tsa5pPpll4E3xhzfZsRpgHLdLQ==; 5:DmfWZH2cBlidrEfWszexeFH9Ncx+siY9H+2GZWdP2Y0YEUz0BZyrCrDVuQuWjqMuR/xLgO1nMJFzOrqZDQF1JuDNB7imp4Glt+9PYmQiZtfXfTmR9Ea231uhoEoBq2ML/NhwSa+NhwDvuDV+P6FOIA==; 24:egQ6a25ceRYLpc9+GXfqoGSoD4rE1p7j/k+dbNaK2C4vNgZy2bNCsWO5fF5mYPc8XfyAmCBIhR4Hp6rPrAuYe2bf9Oz+zTJHYQrUaHHfoTA=; 7:OqwwqS59j6MRebOTAClFZ5w//XgnbKPkXz9Um22HqlV2bINCKBY+CT7pDlrIAwR4U0MMchqYSaQRuhv0yXqq1NL5OTMvq5wf5ZPPw+/qc4n72oqKI7T/kTLuhLi03cjNMcfEMVNsUaOS90HDOx/CCIyMIEemzbNmc4rEkVsFPsAf4E3FpHiO5hSOortw5QDDeAoZgbUmU/BjcMwBXNnT/WJqqOSWgpEIl8dfBeQKAD0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 965843e3-3d85-4699-5cc1-08d51d00de56 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(3231020)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(57704003)(189002)(199003)(32952001)(2900100001)(6436002)(97736004)(790700001)(50986999)(316002)(76176999)(2950100002)(54356999)(102836003)(8936002)(6116002)(3846002)(2906002)(55016002)(77096006)(110136005)(25786009)(14454004)(6306002)(86362001)(101416001)(19609705001)(54896002)(33656002)(6506006)(81166006)(72206003)(229853002)(9686003)(68736007)(6246003)(53936002)(189998001)(80792005)(5660300001)(66066001)(478600001)(7696004)(81156014)(2501003)(8676002)(966005)(3660700001)(105586002)(3280700002)(53546010)(74316002)(7736002)(106356001)(99286003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178813BF5443A5DBE872D98EEA5A0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 965843e3-3d85-4699-5cc1-08d51d00de56 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 06:06:30.9731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6145> : inlines <6149> : streams <1768540> : uri <2523088> Archived-At: Subject: Re: [Dots] Full Pipe Scenario X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 06:06:39 -0000 --_000_DM5PR16MB178813BF5443A5DBE872D98EEA5A0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Heartbeat mechanism is triggered only when the communication b/w the DOTS a= gents is idle (see https://tools.ietf.org/html/draft-ietf-dots-signal-chann= el-05#section-5.6). In this case, the DOTS client does not receive any mitigation response from= the DOTS server, and the DOTS client knows the inbound pipe is saturated, = but the DOTS client does not know if the DOTS session is disconnected. To h= andle both the problems, and maximize reachability, the DOTS client can con= tinue to use the same DOTS session even if no response is received for the = heartbeat but at the same time try (D)TLS session resumption or use 0-RTT m= ode in (D)TLS 1.3 to piggyback the mitigation request in the ClientHello. When the inbound pipe is no longer saturated, but the DOTS client does not = receive any heartbeat responses from the DOTS server then it should conside= r the session is defunct after missing-hb-allowed number of times. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, October 27, 2017 2:06 AM To: dots@ietf.org Subject: [Dots] Full Pipe Scenario Hi, DOTS Client (C) --------- Pipe -------- DOTS Server (S) We have been testing DOTS server and DOTS client signal channel interaction= with a full inbound pipe scenario where all traffic from DOTS server to DO= TS client is dropped, but traffic from DOTS client is getting through to th= e DOTS server. The outbound pipe may be lossy, but testing was done with very little loss = outbound. If the outbound pipe is running full, then the DOTS Client environment has = to control this traffic as the DOTS Server is very unlikely to be able to d= o anything here - so this scenario ignored! With this full inbound pipe (direction S to C), we are seeing the following * DOTS server sees the Heartbeat requests from the DOTS client * DOTS server sees any mitigation requests from the DOTS client * DOTS server thinks the signal channel is dead as there are no respo= nses to the DOTS server's Heartbeats * DOTS client thinks the signal channel is dead as there are no respo= nses to the DOTS client's Heartbeats * DOTS client is unable to establish a new signal channel with the se= rver (this may be down to the fact that we internally have not (yet) got se= ssion resumption working over DTLS) and so cannot send mitigation requests = over this channel If the DOTS server is seeing and noting the DOTS client Heartbeat requests,= it can determine the session is still alive and keep it going, even if its= own Heartbeats are failing (perhaps just mark the session as 'Heartbeat Fa= iling' after the missing heartbeat counter has expired). Should we be doin= g this noting of DOTS Client heartbeats? [TR] Yes, it s -The DOTS server can safely assume there is a pipe full scenario (or networ= k routing issue) if it continues to see the DOTS client heartbeats. If the DOTS server is still keeping the session going, and receives a DOTS = client mitigation request it can be acted on, even though there is a full p= ipe. Is this a good thing? Should the DOTS client continue to send Heartbeats after the DOTS client ha= s determined the session has 'Heartbeat Failed' - so that that the DOTS ser= ver is kept "warm" in case a mitigation request has to blindly be sent. If the DOTS client closes the session after Heartbeat failure, fails to est= ablish a new session, then there is no mechanism to send a mitigation reque= st - the DOTS client may have discovered a new IP or subnet under attack. - I appreciate that we have a trigger-mitigation flag which may help here. - If the new session gets going, then the "Heartbeat Failure" session shoul= d be closed down. Keeping the Heartbeats going, even after the determination that Heartbeats = are failing has benefits in supporting additional mitigation requests, but = potentially conflicts with the DOTS requirements specification of consideri= ng a DOTS signal channel as no longer active after receipt of heartbeat res= ponses. I know SIG-003 is the subject of another debate - do we need heart= beats at all. SIG-003 Channel Health Monitoring: Peer DOTS agents MUST regularly send heartbeats to each other after mutual authentication in order to keep the DOTS signal channel active. A signal channel MUST be considered active until a DOTS agent explicitly ends the session, or either DOTS agent fails to receive heartbeats from the other after a mutually agreed upon timeout period has elapsed. Regards Jon --_000_DM5PR16MB178813BF5443A5DBE872D98EEA5A0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Heartbeat= mechanism is triggered only when the communication b/w the DOTS agents is = idle (see https://tools.ietf.org/html/draft-ietf-dots-signal-channel-05#sec= tion-5.6).  

In this c= ase, the DOTS client does not receive any mitigation response from the DOTS= server, and the DOTS client knows the inbound pipe is saturated, but the D= OTS client does not know if the DOTS session is disconnected. To handle both the problems, and maximize reachab= ility, the DOTS client can continue to use the same DOTS session even if no= response is received for the heartbeat but at the same time try (D)TLS ses= sion resumption or use 0-RTT mode in (D)TLS 1.3 to piggyback the mitigation request in the ClientHello.

When the = inbound pipe is no longer saturated, but the DOTS client does not receive a= ny heartbeat responses from the DOTS server then it should consider the ses= sion is defunct

after mis= sing-hb-allowed number of times.

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, October 27, 2017 2:06 AM
To: dots@ietf.org
Subject: [Dots] Full Pipe Scenario

 

Hi,

 

DOTS Client (C) –-------- &n= bsp;Pipe –------- DOTS Server (S)

 

We have been testing DOTS serve= r and DOTS client signal channel interaction with a full inbound pipe scena= rio where all traffic from DOTS server to DOTS client is dropped, but traff= ic from DOTS client is getting through to the DOTS server.

 

The outbound pipe may be lossy,= but testing was done with very little loss outbound.

 

If the outbound pipe is running= full, then the DOTS Client environment has to control this traffic as the = DOTS Server is very unlikely to be able to do anything here – so this= scenario ignored!

 

With this full inbound pipe (di= rection S to C), we are seeing the following

 

·       DOTS server sees the Heartbeat requests from the DOTS client

·       DOTS server sees any mitigation requests from the DOTS client<= /span>

·       DOTS server thinks the signal channel is dead as there are no responses t= o the DOTS server’s Heartbeats

·       DOTS client thinks the signal channel is dead as there are no responses t= o the DOTS client’s Heartbeats

·       DOTS client is unable to establish a new signal channel with the server (= this may be down to the fact that we internally have not (yet) got session = resumption working over DTLS) and so cannot send mitigation requests over  this channel<= /p>

 

If the DOTS server is seeing an= d noting the DOTS client Heartbeat requests, it can determine the session i= s still alive and keep it going, even if its own Heartbeats are failing (pe= rhaps just mark the session as ‘Heartbeat Failing’ after the missing heartbeat counter has expired).  Sho= uld we be doing this noting of DOTS Client heartbeats?

 

[TR] Yes, it s

 

-The DOTS server can safely ass= ume there is a pipe full scenario (or network routing issue) if it continue= s to see the DOTS client heartbeats.

 

If the DOTS server is still kee= ping the session going, and receives a DOTS client mitigation request it ca= n be acted on, even though there is a full pipe.  Is this a good thing= ?

 

Should the DOTS client continue= to send Heartbeats after the DOTS client has determined the session has &#= 8216;Heartbeat Failed’ – so that that the DOTS server is kept &= #8220;warm” in case a mitigation request has to blindly be sent.=

 

If the DOTS client closes the s= ession after Heartbeat failure, fails to establish a new session, then ther= e is no mechanism to send a mitigation request – the DOTS client may = have discovered a new IP or subnet under attack.

- I appreciate that we have a t= rigger-mitigation flag which may help here.

- If the new session gets going= , then the “Heartbeat Failure” session should be closed down.

 

Keeping the Heartbeats going, e= ven after the determination that Heartbeats are failing has benefits in sup= porting additional mitigation requests, but potentially conflicts with the = DOTS requirements specification of considering a DOTS signal channel as no longer active after receipt of heartbeat respo= nses.  I know SIG-003 is the subject of another debate – do we n= eed heartbeats at all.

 

   SIG-003  Chan= nel Health Monitoring: Peer DOTS agents MUST regularly

      = send heartbeats to each other after mutual authentication in order

      = to keep the DOTS signal channel active.  A signal channel MUST be=

      = considered active until a DOTS agent explicitly ends the session,

      = or either DOTS agent fails to receive heartbeats from the other<= /span>

      = after a mutually agreed upon timeout period has elapsed.<= /p>

 

Regards

 

Jon

--_000_DM5PR16MB178813BF5443A5DBE872D98EEA5A0DM5PR16MB1788namp_-- From nobody Thu Oct 26 23:23:35 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88C213AC0E for ; Thu, 26 Oct 2017 23:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJjEEKnByIBq for ; Thu, 26 Oct 2017 23:23:32 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B42139B9F for ; Thu, 26 Oct 2017 23:23:32 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id D0B661807AF; Fri, 27 Oct 2017 08:23:30 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id A9AD220067; Fri, 27 Oct 2017 08:23:30 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0361.001; Fri, 27 Oct 2017 08:23:30 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] DOTS signal and resource path discovery Thread-Index: AdNOYfsbT1udcdezQbua6sZ/aw7wYAAAz3awACGwm/A= Date: Fri, 27 Oct 2017 06:23:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A05F0A2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A05F0A2OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS signal and resource path discovery X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 06:23:35 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A05F0A2OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Fully agree with Tiru. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : jeudi 26 octobre 2017 16:30 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS signal and resource path discovery I don't see the need to complicate the DOTS signal channel by introducing r= esource discovery (see https://tools.ietf.org/html/rfc5785), Many protocols like EST use well-known locations (e.g. https://www.example.= com/.well-known/est/) where uri-suffix 'est' is allocated by the IANA to av= oid collisions. We can consider a similar approach and request IANA to allocate uri-suffix = 'dots'. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, October 26, 2017 7:25 PM To: dots@ietf.org Subject: [Dots] DOTS signal and resource path discovery Hi there Following on from the recent virtual conference with discussions about what= should be the signal request path (should .wellknown be included in it etc= .). RFC7252 7.1 Service Discovery "The CoAP default port number 5683 MUST be supported by a server that offers resources for resource discovery (see Section 7.2 below) and SHOULD be supported for providing access to other resources. The default port number 5684 for DTLS-secured CoAP MAY be supported by a server for resource discovery and for providing access to other resources. In addition, other endpoints may be hosted at other ports, e.g., in the dynamic port space." DOTS is not hosting non (D)TLS COAP, and so we will be breaking the MUST fo= r port 5683. I propose that we do the following for the signal channel spe= c and support resource discovery. 1) Update the 2 paths (signal and configuration) in the specification,= when can then be the default values. Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "signal" To Uri-Path: "v1" << We are v1 as described = in the text Uri-Path: "dots-signal" Uri-Path: "mitigation" << overloaded use of signal, th= is is the mitigate part of dots-signal And Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "config" To Uri-Path: "v1" Uri-Path: "dots-signal" Uri-Path: "configuration" 2) Add in the following =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.7 Resource Discovery As per [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support the = CoRe Link Format of discoverable resource as described in [RFC6690], except= where fully manual configuration is desired. The two discoverable resources that SHOULD be available to a DOTS client ar= e "mitigation" and "configuration". If the appropriate URI paths are retur= ned, the DOTS client MUST use them, overriding any default configuration. = A DOTS client SHOULD do a resource discovery, which is done by a GET reques= t to "/.wellknown/core" Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".wellknown" Uri-Path: "core" Figure xxx: GET to retrieve dots-signal resources Content-Format:application/link-format ;rt=3D"mitigation";title=3D"DOTS Signal Mitigati= on";ct=3D60, ;rt=3D"configuration";title=3D"DOTS Signal C= onfiguration";ct=3D60 Figure yyy: Example response to GET to retrieve dots-signal resources As to CoAP being on different ports on the server hosting DOTS server (or D= OTS gateway), this may have to be configurable in the DOTS clients, or conf= igurable on the Data Channel as an extension to "The DOTS client will perform the root resource discovery procedure discussed in Section 3.1 of [RFC8040] to determine the root of the RESTCONF API. After discovering the RESTCONF API root, the DOTS client uses this value as the initial part of the path in the request URI, in any subsequent request to the DOTS server. The DOTS server may support retrieval of the YANG modules it supports (Section 3.7 in [RFC8040]), for example, a DOTS client may use RESTCONF to retrieve the company proprietary YANG modules supported by the DOTS server." Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A05F0A2OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Fully agree with Tiru.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : jeudi 26 octobre 2017 16:30
=C0 : Jon Shallow; dots@ietf.org
Objet : Re: [Dots] DOTS signal and resource path discovery=

 

I don’t see the need to complicate t=
he DOTS signal channel by introducing resource discovery (see https://tools.ietf.org/html/rfc5785)=
, 
Many protocols like EST use well-known loc=
ations (e.g. https://w=
ww.example.com/.well-known/est/) where uri-suffix 'est' is allocated by=
 the IANA to avoid collisions. 
We can consider a similar approach and req=
uest IANA to allocate uri-suffix 'dots'.
 
-Tiru
 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Thursday, October 26, 2017 7:25 PM
To: dots@ietf.org
Subject: [Dots] DOTS signal and resource path discovery

 

Hi there

 

Following on from the recent vi= rtual conference with discussions about what should be the signal request p= ath (should .wellknown be included in it etc.).

 

RFC7252 7.1 Service Discovery

“The CoAP default port nu= mber 5683 MUST be supported by a server that

   offers resources f= or resource discovery (see Section 7.2 below) and

   SHOULD be supporte= d for providing access to other resources.  The

   default port numbe= r 5684 for DTLS-secured CoAP MAY be supported by a

   server for resourc= e discovery and for providing access to other

   resources.  I= n addition, other endpoints may be hosted at other

   ports, e.g., in th= e dynamic port space.”

 

DOTS is not hosting non (D)TLS = COAP, and so we will be breaking the MUST for port 5683.  I propose th= at we do the following for the signal channel spec and support resource dis= covery.

 

1)      Update the 2 paths (signal and configuration) i= n the specification, when can then be the default values.=

    = Uri-Path: "version"

    = Uri-Path: "dots-signal"

    = Uri-Path: "signal"

To

    = Uri-Path: "v1"         &= nbsp;           &nbs= p;        << We are v1 as describe= d in the text

    = Uri-Path: "dots-signal"

    = Uri-Path: "mitigation"       =           << overloaded = use of signal, this is the mitigate part of dots-signal

     &= nbsp;         And=

&n= bsp;    Uri-Path: "version"

    = Uri-Path: "dots-signal"

    = Uri-Path: "config"

To

    = Uri-Path: "v1"

    = Uri-Path: "dots-signal"

    = Uri-Path: "configuration"

2)      Add in the following

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

5.7 Resource Discovery

 

As per [RFC7252 7.2 Resource Di= scovery] the DOTS server SHOULD support the CoRe Link Format of discoverabl= e resource as described in [RFC6690], except where fully manual configurati= on is desired.

 

The two discoverable resources = that SHOULD be available to a DOTS client are “mitigation” and = “configuration”.  If the appropriate URI paths are returne= d, the DOTS client MUST use them, overriding any default configuration.&nbs= p; A DOTS client SHOULD do a resource discovery, which is done by a GET reque= st to “/.wellknown/core”

 

Header: GET (Code=3D0.01)<= /o:p>

     Uri-Ho= st: "host"

     Uri-Pa= th: ".wellknown"

     Uri-Pa= th: "core"

 

Figure xxx: GET to retrieve dot= s-signal resources

 

Content-Format:application/link= -format

 

<v1/dots-signal/mitigation&g= t;;rt=3D"mitigation";title=3D"DOTS Signal Mitigation";c= t=3D60,

</v1/dots-signal/configurati= on>;rt=3D"configuration";title=3D"DOTS Signal Configurati= on";ct=3D60

 

Figure yyy: Example response to= GET to retrieve dots-signal resources

 

 

As to CoAP being on different p= orts on the server hosting DOTS server (or DOTS gateway), this may have to = be configurable in the DOTS clients, or configurable on the Data Channel as= an extension to

 

“The DOTS client will per= form the root resource discovery procedure

   discussed in Secti= on 3.1 of [RFC8040] to determine the root of the

   RESTCONF API. = ; After discovering the RESTCONF API root, the DOTS

   client uses this v= alue as the initial part of the path in the request

   URI, in any subseq= uent request to the DOTS server.  The DOTS server

   may support retrie= val of the YANG modules it supports (Section 3.7 in

   [RFC8040]), for ex= ample, a DOTS client may use RESTCONF to retrieve

   the company propri= etary YANG modules supported by the DOTS server.”

 

Regards

 

Jon

 

--_000_787AE7BB302AE849A7480A190F8B93300A05F0A2OPEXCLILMA3corp_-- From nobody Thu Oct 26 23:44:35 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9652613F4CB for ; Thu, 26 Oct 2017 23:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 QAXtgM8Xj2Zp for ; Thu, 26 Oct 2017 23:44:32 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 2F4EF139B9F for ; Thu, 26 Oct 2017 23:44:26 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509086651; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=J IBgjWzhkm+ERELj2FK4qdJ9AVB9fuhUhmCQWHmlDP c=; b=Rn+0JBcBNka3NApwmXaNuMyvzUPyEIIG2NXl+gc/AKer hgSTkAf88aHuZaxMkpoXoFvJI1A8iEGWQjh8uM8/9f4rgIUtpT t8I5BsTdrrv/RCjnROKCZGcAcK67PkyTZ6xH6o1Rd21smirIGY xE5obXn/Csq0UJuGEfKtJbXgJMI= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 1b9d_b2d2_4dfa9e04_03b1_4081_a74c_2de7c2fdb0f2; Fri, 27 Oct 2017 01:44:10 -0500 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 00:44:09 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 27 Oct 2017 00:44:08 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 00:44:08 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Fri, 27 Oct 2017 06:44:07 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0156.007; Fri, 27 Oct 2017 06:44:07 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "'Mortensen, Andrew'" , "dots@ietf.org" Thread-Topic: [Dots] DOTS signal and resource path discovery Thread-Index: AdNOYfsbT1udcdezQbua6sZ/aw7wYAAAz3awAAEZqQAADGb9gAAUXrjg Date: Fri, 27 Oct 2017 06:44:07 +0000 Message-ID: References: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> <0CEBEED4-F958-467A-98D5-54F7C4CB0883@arbor.net> <018601d34e9b$3beb2540$b3c16fc0$@jpshallow.com> In-Reply-To: <018601d34e9b$3beb2540$b3c16fc0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.167.138.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:8ZEpeU4uiJ2lPmnVxWt/Nj+YQCuIcfxn7g7MoDiBFOykeFxxm9Mh8UhV6YZh8N6Wu9DoWVF2iNQQ19iCu3HtilbsMhB8ze32Jacr4UfmOgjb4p5ZrCeH1aPBA8ShmoR2YMM57sa6u4Vx66jT2BD1aWJDM+uptIjKl0ImH6ncg2rYIcrUhwp6gjc+aeAqwviAzubguqWp4ydJa20O2Mf+/2QwloTXZKpvysmpbTlYWM3oFvOAfuDFrYaO8ukSCnvXOwXv1FNxoY6zPOHn/9HaaE53JMxQR9jYUai6e0iRQzKWb5R0L5h+xySnBD4Dty6cqIkckQUsU4rb2vqqbHrLVA==; 5:UNnM433KgbnqWqD+YTsv78Hr4KRAm0KpecDykkaiRVailhvq1dvV8ccVrul/lFFk7LEMC10vLcT2szYHodoyURy3/XgVwo8T5GJQ7HPD5kVWCElEBpZ4jIHKcYY+2ZlEWSLOA7cDb7rzcRfdQn30rQ==; 24:nf8jQavo/8H5z5t8mlnYO2IctNuwvzLyMjMXWop6kJ2Kg8DxMuDKBEZZeHUIH51NEoYNSzOtXfQSDeT1eRCE8Q1Y4iTNqXkGzXqlG0+5KBI=; 7:M7a4lQlklg1AGL0oyNTCG4QOwM6eeEEYb572JkGz1y+725E55CcOyDse8MQGZGN255GC/NihSzeTwrDfNY0I6IWcqXCx8cy0TxxxJFBA7oZnd39SqSJ6nCyLuX/hrPkWRkppI6ffDAOt1Rz1zit703YA0wq64Kt3YIOCVOQYLfMUp8hFOd9IvkoOD4jGhHGjKlOY1mW05nxHxn07rWvWy6kUeLM8CyiXjQNYn7Cx1Uc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1d3ce176-627d-4513-93a4-08d51d061f32 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(79290750141951)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(32952001)(189002)(199003)(24454002)(8676002)(25786009)(68736007)(99286003)(2950100002)(7696004)(80792005)(97736004)(110136005)(76176999)(14454004)(189998001)(50986999)(106356001)(105586002)(81166006)(81156014)(54896002)(54356999)(19609705001)(9686003)(5660300001)(236005)(53936002)(33656002)(316002)(55016002)(93886005)(6306002)(966005)(6116002)(102836003)(6506006)(6436002)(3660700001)(77096006)(790700001)(8936002)(2900100001)(6246003)(2501003)(53546010)(478600001)(3846002)(66066001)(3280700002)(74316002)(2906002)(7736002)(101416001)(9326002)(229853002)(606006)(86362001)(72206003)(21314002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17882F1EAC551B7223B3B49CEA5A0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1d3ce176-627d-4513-93a4-08d51d061f32 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 06:44:07.2139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6145> : inlines <6149> : streams <1768543> : uri <2523102> Archived-At: Subject: Re: [Dots] DOTS signal and resource path discovery X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 06:44:35 -0000 --_000_DM5PR16MB17882F1EAC551B7223B3B49CEA5A0DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uLA0KDQpUaGFua3MsIFRoZSBVUkkgcGF0aCBjYW4gbG9vayBhcyBmb2xsb3dzOg0KDQog ICAgIFVyaS1Ib3N0OiAiaG9zdCINCiAgICAgVXJpLVBhdGg6ICJVUkkgc3VmZml4Ig0KICAgICBV cmktUGF0aDogInZlcnNpb24iDQogICAgIFVyaS1QYXRoOiAibWl0aWdhdGUiIG9yICJjb25maWci DQoNCklBTkEgd2lsbCBiZSByZXF1ZXN0ZWQgdG8gYWxsb2NhdGUgdGhlIHVyaS1zdWZmaXgg4oCc ZG90c+KAnSBvciDigJxkb3RzLXNpZ25hbOKAnSAoZGVwZW5kaW5nIG9uIGlmIHRoZSBXRyBkZWNp ZGVzIHRvIHRha2UgdGhlIHNhbWUgYXBwcm9hY2ggZm9yIERPVFMgZGF0YSBjaGFubmVsKS4NCg0K LVRpcnUNCg0KRnJvbTogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cu Y29tXQ0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDI3LCAyMDE3IDI6MTUgQU0NClRvOiAnTW9ydGVu c2VuLCBBbmRyZXcnIDxhbW9ydGVuc2VuQGFyYm9yLm5ldD47IEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyBkb3RzQGlldGYub3Jn DQpTdWJqZWN0OiBSRTogW0RvdHNdIERPVFMgc2lnbmFsIGFuZCByZXNvdXJjZSBwYXRoIGRpc2Nv dmVyeQ0KDQpUaGlzIHdvcmtzIGZvciBtZS4gIEl0IG1lYW5zIHRoYXQgd2Ugbm8gbG9uZ2VyIG5l ZWQg4oCcZG90cy1zaWduYWzigJ0gaW4gdGhlIHBhdGggKHNhdmVzIHBhY2tldCBzcGFjZSkuICBJ IHN0aWxsIHdvdWxkIGxpa2UgdG8gc2VlIOKAnHNpZ25hbOKAnSBpbiB0aGUgcGF0aCByZW5hbWVk IHRvLCBzYXksIOKAnG1pdGlnYXRl4oCdIGFzIERPVFMgc2lnbmFsIGNvdmVycyBib3RoIG1pdGln YXRpb24gYW5kIGNvbmZpZ3VyYXRpb24uDQoNCkhvd2V2ZXIsIHdoYXQgaGFwcGVucyBpZiBET1RT IGhhcyBhIHZlcnNpb24gY2hhbmdlIGZyb20gdjEgdG8gdjIgPw0KLSBIb3cgZG8gd2UgaGFuZGxl IHRoaXMgKHVubGlrZWx5KSBldmVudD8NCg0KUmVnYXJkcw0KDQpKb24NCg0KRnJvbTogRG90cyBb bWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9y Zz5dIE9uIEJlaGFsZiBPZiBNb3J0ZW5zZW4sIEFuZHJldw0KU2VudDogMjYgT2N0b2JlciAyMDE3 IDE1OjUwDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KQ2M6IEpvbiBTaGFsbG93OyBk b3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEb3RzXSBE T1RTIHNpZ25hbCBhbmQgcmVzb3VyY2UgcGF0aCBkaXNjb3ZlcnkNCg0KDQpPbiBPY3QgMjYsIDIw MTcsIGF0IDEwOjI5IEFNLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0Fm ZWUuY29tPj4gd3JvdGU6DQoNCg0KSSBkb27igJl0IHNlZSB0aGUgbmVlZCB0byBjb21wbGljYXRl IHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIGJ5IGludHJvZHVjaW5nIHJlc291cmNlIGRpc2NvdmVy eSAoc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1Nzg1KSwNCg0KTWFueSBwcm90 b2NvbHMgbGlrZSBFU1QgdXNlIHdlbGwta25vd24gbG9jYXRpb25zIChlLmcuIGh0dHBzOi8vd3d3 LmV4YW1wbGUuY29tLy53ZWxsLWtub3duL2VzdC8pIHdoZXJlIHVyaS1zdWZmaXggJ2VzdCcgaXMg YWxsb2NhdGVkIGJ5IHRoZSBJQU5BIHRvIGF2b2lkIGNvbGxpc2lvbnMuDQoNCldlIGNhbiBjb25z aWRlciBhIHNpbWlsYXIgYXBwcm9hY2ggYW5kIHJlcXVlc3QgSUFOQSB0byBhbGxvY2F0ZSB1cmkt c3VmZml4ICdkb3Rz4oCZLg0KDQpJIGxpa2UgdGhpcyBhcHByb2FjaC4NCg0KYW5kcmV3DQoNCg0K DQoNCg0KDQoNCg0KRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEpvbiBTaGFsbG93DQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNiwgMjAxNyA3 OjI1IFBNDQpUbzogZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NClN1YmplY3Q6 IFtEb3RzXSBET1RTIHNpZ25hbCBhbmQgcmVzb3VyY2UgcGF0aCBkaXNjb3ZlcnkNCg0KSGkgdGhl cmUNCg0KRm9sbG93aW5nIG9uIGZyb20gdGhlIHJlY2VudCB2aXJ0dWFsIGNvbmZlcmVuY2Ugd2l0 aCBkaXNjdXNzaW9ucyBhYm91dCB3aGF0IHNob3VsZCBiZSB0aGUgc2lnbmFsIHJlcXVlc3QgcGF0 aCAoc2hvdWxkIC53ZWxsa25vd24gYmUgaW5jbHVkZWQgaW4gaXQgZXRjLikuDQoNClJGQzcyNTIg Ny4xIFNlcnZpY2UgRGlzY292ZXJ5DQrigJxUaGUgQ29BUCBkZWZhdWx0IHBvcnQgbnVtYmVyIDU2 ODMgTVVTVCBiZSBzdXBwb3J0ZWQgYnkgYSBzZXJ2ZXIgdGhhdA0KICAgb2ZmZXJzIHJlc291cmNl cyBmb3IgcmVzb3VyY2UgZGlzY292ZXJ5IChzZWUgU2VjdGlvbiA3LjIgYmVsb3cpIGFuZA0KICAg U0hPVUxEIGJlIHN1cHBvcnRlZCBmb3IgcHJvdmlkaW5nIGFjY2VzcyB0byBvdGhlciByZXNvdXJj ZXMuICBUaGUNCiAgIGRlZmF1bHQgcG9ydCBudW1iZXIgNTY4NCBmb3IgRFRMUy1zZWN1cmVkIENv QVAgTUFZIGJlIHN1cHBvcnRlZCBieSBhDQogICBzZXJ2ZXIgZm9yIHJlc291cmNlIGRpc2NvdmVy eSBhbmQgZm9yIHByb3ZpZGluZyBhY2Nlc3MgdG8gb3RoZXINCiAgIHJlc291cmNlcy4gIEluIGFk ZGl0aW9uLCBvdGhlciBlbmRwb2ludHMgbWF5IGJlIGhvc3RlZCBhdCBvdGhlcg0KICAgcG9ydHMs IGUuZy4sIGluIHRoZSBkeW5hbWljIHBvcnQgc3BhY2Uu4oCdDQoNCkRPVFMgaXMgbm90IGhvc3Rp bmcgbm9uIChEKVRMUyBDT0FQLCBhbmQgc28gd2Ugd2lsbCBiZSBicmVha2luZyB0aGUgTVVTVCBm b3IgcG9ydCA1NjgzLiAgSSBwcm9wb3NlIHRoYXQgd2UgZG8gdGhlIGZvbGxvd2luZyBmb3IgdGhl IHNpZ25hbCBjaGFubmVsIHNwZWMgYW5kIHN1cHBvcnQgcmVzb3VyY2UgZGlzY292ZXJ5Lg0KDQox KSAgICAgIFVwZGF0ZSB0aGUgMiBwYXRocyAoc2lnbmFsIGFuZCBjb25maWd1cmF0aW9uKSBpbiB0 aGUgc3BlY2lmaWNhdGlvbiwgd2hlbiBjYW4gdGhlbiBiZSB0aGUgZGVmYXVsdCB2YWx1ZXMuDQog ICAgIFVyaS1QYXRoOiAidmVyc2lvbiINCiAgICAgVXJpLVBhdGg6ICJkb3RzLXNpZ25hbCINCiAg ICAgVXJpLVBhdGg6ICJzaWduYWwiDQpUbw0KICAgICBVcmktUGF0aDogInYxIiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDw8IFdlIGFyZSB2MSBhcyBkZXNjcmliZWQgaW4gdGhlIHRleHQN CiAgICAgVXJpLVBhdGg6ICJkb3RzLXNpZ25hbCINCiAgICAgVXJpLVBhdGg6ICJtaXRpZ2F0aW9u IiAgICAgICAgICAgICAgICAgPDwgb3ZlcmxvYWRlZCB1c2Ugb2Ygc2lnbmFsLCB0aGlzIGlzIHRo ZSBtaXRpZ2F0ZSBwYXJ0IG9mIGRvdHMtc2lnbmFsDQogICAgICAgICAgICAgICBBbmQNCiAgICAg VXJpLVBhdGg6ICJ2ZXJzaW9uIg0KICAgICBVcmktUGF0aDogImRvdHMtc2lnbmFsIg0KICAgICBV cmktUGF0aDogImNvbmZpZyINClRvDQogICAgIFVyaS1QYXRoOiAidjEiDQogICAgIFVyaS1QYXRo OiAiZG90cy1zaWduYWwiDQogICAgIFVyaS1QYXRoOiAiY29uZmlndXJhdGlvbiINCjIpICAgICAg QWRkIGluIHRoZSBmb2xsb3dpbmcNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCjUuNyBSZXNvdXJjZSBEaXNjb3ZlcnkNCg0KQXMgcGVyIFtSRkM3MjUy IDcuMiBSZXNvdXJjZSBEaXNjb3ZlcnldIHRoZSBET1RTIHNlcnZlciBTSE9VTEQgc3VwcG9ydCB0 aGUgQ29SZSBMaW5rIEZvcm1hdCBvZiBkaXNjb3ZlcmFibGUgcmVzb3VyY2UgYXMgZGVzY3JpYmVk IGluIFtSRkM2NjkwXSwgZXhjZXB0IHdoZXJlIGZ1bGx5IG1hbnVhbCBjb25maWd1cmF0aW9uIGlz IGRlc2lyZWQuDQoNClRoZSB0d28gZGlzY292ZXJhYmxlIHJlc291cmNlcyB0aGF0IFNIT1VMRCBi ZSBhdmFpbGFibGUgdG8gYSBET1RTIGNsaWVudCBhcmUg4oCcbWl0aWdhdGlvbuKAnSBhbmQg4oCc Y29uZmlndXJhdGlvbuKAnS4gIElmIHRoZSBhcHByb3ByaWF0ZSBVUkkgcGF0aHMgYXJlIHJldHVy bmVkLCB0aGUgRE9UUyBjbGllbnQgTVVTVCB1c2UgdGhlbSwgb3ZlcnJpZGluZyBhbnkgZGVmYXVs dCBjb25maWd1cmF0aW9uLiAgQSBET1RTIGNsaWVudCBTSE9VTEQgZG8gYSByZXNvdXJjZSBkaXNj b3ZlcnksIHdoaWNoIGlzIGRvbmUgYnkgYSBHRVQgcmVxdWVzdCB0byDigJwvLndlbGxrbm93bi9j b3Jl4oCdDQoNCkhlYWRlcjogR0VUIChDb2RlPTAuMDEpDQogICAgIFVyaS1Ib3N0OiAiaG9zdCIN CiAgICAgVXJpLVBhdGg6ICIud2VsbGtub3duIg0KICAgICBVcmktUGF0aDogImNvcmUiDQoNCkZp Z3VyZSB4eHg6IEdFVCB0byByZXRyaWV2ZSBkb3RzLXNpZ25hbCByZXNvdXJjZXMNCg0KQ29udGVu dC1Gb3JtYXQ6YXBwbGljYXRpb24vbGluay1mb3JtYXQNCg0KPHYxL2RvdHMtc2lnbmFsL21pdGln YXRpb24+O3J0PSJtaXRpZ2F0aW9uIjt0aXRsZT0iRE9UUyBTaWduYWwgTWl0aWdhdGlvbiI7Y3Q9 NjAsDQo8L3YxL2RvdHMtc2lnbmFsL2NvbmZpZ3VyYXRpb24+O3J0PSJjb25maWd1cmF0aW9uIjt0 aXRsZT0iRE9UUyBTaWduYWwgQ29uZmlndXJhdGlvbiI7Y3Q9NjANCg0KRmlndXJlIHl5eTogRXhh bXBsZSByZXNwb25zZSB0byBHRVQgdG8gcmV0cmlldmUgZG90cy1zaWduYWwgcmVzb3VyY2VzDQoN Cg0KQXMgdG8gQ29BUCBiZWluZyBvbiBkaWZmZXJlbnQgcG9ydHMgb24gdGhlIHNlcnZlciBob3N0 aW5nIERPVFMgc2VydmVyIChvciBET1RTIGdhdGV3YXkpLCB0aGlzIG1heSBoYXZlIHRvIGJlIGNv bmZpZ3VyYWJsZSBpbiB0aGUgRE9UUyBjbGllbnRzLCBvciBjb25maWd1cmFibGUgb24gdGhlIERh dGEgQ2hhbm5lbCBhcyBhbiBleHRlbnNpb24gdG8NCg0K4oCcVGhlIERPVFMgY2xpZW50IHdpbGwg cGVyZm9ybSB0aGUgcm9vdCByZXNvdXJjZSBkaXNjb3ZlcnkgcHJvY2VkdXJlDQogICBkaXNjdXNz ZWQgaW4gU2VjdGlvbiAzLjEgb2YgW1JGQzgwNDBdIHRvIGRldGVybWluZSB0aGUgcm9vdCBvZiB0 aGUNCiAgIFJFU1RDT05GIEFQSS4gIEFmdGVyIGRpc2NvdmVyaW5nIHRoZSBSRVNUQ09ORiBBUEkg cm9vdCwgdGhlIERPVFMNCiAgIGNsaWVudCB1c2VzIHRoaXMgdmFsdWUgYXMgdGhlIGluaXRpYWwg cGFydCBvZiB0aGUgcGF0aCBpbiB0aGUgcmVxdWVzdA0KICAgVVJJLCBpbiBhbnkgc3Vic2VxdWVu dCByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4gIFRoZSBET1RTIHNlcnZlcg0KICAgbWF5IHN1 cHBvcnQgcmV0cmlldmFsIG9mIHRoZSBZQU5HIG1vZHVsZXMgaXQgc3VwcG9ydHMgKFNlY3Rpb24g My43IGluDQogICBbUkZDODA0MF0pLCBmb3IgZXhhbXBsZSwgYSBET1RTIGNsaWVudCBtYXkgdXNl IFJFU1RDT05GIHRvIHJldHJpZXZlDQogICB0aGUgY29tcGFueSBwcm9wcmlldGFyeSBZQU5HIG1v ZHVsZXMgc3VwcG9ydGVkIGJ5IHRoZSBET1RTIHNlcnZlci7igJ0NCg0KUmVnYXJkcw0KDQpKb24N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRvdHMg bWFpbGluZyBsaXN0DQpEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoNCg== --_000_DM5PR16MB17882F1EAC551B7223B3B49CEA5A0DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFo b21hIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNv LXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFw cGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkhpIEpvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLCBUaGUgVVJJIHBh dGggY2FuIGxvb2sgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBsYW5nPSJTVi1GSSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlVyaS1Ib3N0OiAmcXVvdDtob3N0JnF1b3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O1VSSSBzdWZm aXg8L3NwYW4+PHNwYW4gbGFuZz0iU1YtRkkiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7 dmVyc2lvbiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPlVyaS1QYXRoOiAmcXVvdDttaXRpZ2F0ZSZxdW90OyBvciAmcXVvdDtjb25maWcmcXVv dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SUFOQSB3aWxsIGJlIHJlcXVlc3Rl ZCB0byBhbGxvY2F0ZSB0aGUgdXJpLXN1ZmZpeCDigJxkb3Rz4oCdIG9yIOKAnGRvdHMtc2lnbmFs 4oCdIChkZXBlbmRpbmcgb24gaWYgdGhlIFdHIGRlY2lkZXMgdG8gdGFrZSB0aGUgc2FtZSBhcHBy b2FjaCBmb3IgRE9UUyBkYXRhIGNoYW5uZWwpLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+LVRpcnU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgMjcsIDIwMTcgMjoxNSBBTTxicj4N CjxiPlRvOjwvYj4gJ01vcnRlbnNlbiwgQW5kcmV3JyAmbHQ7YW1vcnRlbnNlbkBhcmJvci5uZXQm Z3Q7OyBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDtUaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBNY0FmZWUuY29tJmd0OzsgZG90c0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog W0RvdHNdIERPVFMgc2lnbmFsIGFuZCByZXNvdXJjZSBwYXRoIGRpc2NvdmVyeTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyB3b3JrcyBmb3IgbWUuJm5ic3A7IEl0IG1lYW5z IHRoYXQgd2Ugbm8gbG9uZ2VyIG5lZWQg4oCcZG90cy1zaWduYWzigJ0gaW4gdGhlIHBhdGggKHNh dmVzIHBhY2tldCBzcGFjZSkuJm5ic3A7IEkgc3RpbGwgd291bGQgbGlrZSB0byBzZWUg4oCcc2ln bmFs4oCdIGluIHRoZSBwYXRoDQogcmVuYW1lZCB0bywgc2F5LCDigJxtaXRpZ2F0ZeKAnSBhcyBE T1RTIHNpZ25hbCBjb3ZlcnMgYm90aCBtaXRpZ2F0aW9uIGFuZCBjb25maWd1cmF0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5Ib3dldmVyLCB3aGF0IGhhcHBlbnMgaWYgRE9UUyBoYXMgYSB2ZXJzaW9uIGNoYW5n ZSBmcm9tIHYxIHRvIHYyID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0gSG93IGRv IHdlIGhhbmRsZSB0aGlzICh1bmxpa2VseSkgZXZlbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Sm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZiI+IERvdHMgW21haWx0bzoNCjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0 Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZg0KPC9iPk1v cnRlbnNlbiwgQW5kcmV3PGJyPg0KPGI+U2VudDo8L2I+IDI2IE9jdG9iZXIgMjAxNyAxNTo1MDxi cj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTxicj4NCjxiPkNjOjwvYj4g Sm9uIFNoYWxsb3c7IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNdIERPVFMgc2lnbmFsIGFuZCByZXNv dXJjZSBwYXRoIGRpc2NvdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gT2N0IDI2LCAyMDE3LCBhdCAxMDoyOSBBTSwg S29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dh clJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGRvbuKAmXQg c2VlIHRoZSBuZWVkIHRvIGNvbXBsaWNhdGUgdGhlIERPVFMgc2lnbmFsIGNoYW5uZWwgYnkgaW50 cm9kdWNpbmcgcmVzb3VyY2UgZGlzY292ZXJ5IChzZWUgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzU3ODUiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1Nzg1PC9zcGFuPjwvYT4pLCA8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5NYW55IHByb3RvY29scyBsaWtlIEVTVCB1c2Ugd2VsbC1rbm93biBsb2Nh dGlvbnMgKGUuZy4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vLndlbGwta25vd24v ZXN0LyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuZXhhbXBsZS5jb20v LndlbGwta25vd24vZXN0Lzwvc3Bhbj48L2E+KSB3aGVyZSB1cmktc3VmZml4ICdlc3QnIGlzIGFs bG9jYXRlZCBieSB0aGUgSUFOQSB0byBhdm9pZCBjb2xsaXNpb25zLiA8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5XZSBjYW4gY29uc2lkZXIgYSBzaW1pbGFyIGFwcHJvYWNoIGFuZCByZXF1 ZXN0IElBTkEgdG8gYWxsb2NhdGUgdXJpLXN1ZmZpeCAnZG90c+KAmS48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj5JIGxpa2UgdGhpcyBhcHByb2FjaC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPmFuZHJldzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RG90cw0KIFs8YSBocmVmPSJtYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Kb24gU2hh bGxvdzxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgT2N0b2JlciAyNiwgMjAxNyA3OjI1IFBNPGJyPg0KPGI+ VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+W0RvdHNdIERPVFMgc2lnbmFsIGFuZCByZXNvdXJjZSBwYXRoIGRpc2NvdmVyeTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSB0aGVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZvbGxvd2luZyBv biBmcm9tIHRoZSByZWNlbnQgdmlydHVhbCBjb25mZXJlbmNlIHdpdGggZGlzY3Vzc2lvbnMgYWJv dXQgd2hhdCBzaG91bGQgYmUgdGhlIHNpZ25hbCByZXF1ZXN0IHBhdGggKHNob3VsZCAud2VsbGtu b3duIGJlIGluY2x1ZGVkIGluIGl0IGV0Yy4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJGQzcyNTIgNy4xIFNl cnZpY2UgRGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCcVGhlIENv QVAgZGVmYXVsdCBwb3J0IG51bWJlciA1NjgzIE1VU1QgYmUgc3VwcG9ydGVkIGJ5IGEgc2VydmVy IHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgb2ZmZXJz IHJlc291cmNlcyBmb3IgcmVzb3VyY2UgZGlzY292ZXJ5IChzZWUgU2VjdGlvbiA3LjIgYmVsb3cp IGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBTSE9VTEQg YmUgc3VwcG9ydGVkIGZvciBwcm92aWRpbmcgYWNjZXNzIHRvIG90aGVyIHJlc291cmNlcy4mbmJz cDsgVGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IGRlZmF1 bHQgcG9ydCBudW1iZXIgNTY4NCBmb3IgRFRMUy1zZWN1cmVkIENvQVAgTUFZIGJlIHN1cHBvcnRl ZCBieSBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IHNlcnZl ciBmb3IgcmVzb3VyY2UgZGlzY292ZXJ5IGFuZCBmb3IgcHJvdmlkaW5nIGFjY2VzcyB0byBvdGhl cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyByZXNvdXJjZXMu Jm5ic3A7IEluIGFkZGl0aW9uLCBvdGhlciBlbmRwb2ludHMgbWF5IGJlIGhvc3RlZCBhdCBvdGhl cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBwb3J0cywgZS5n LiwgaW4gdGhlIGR5bmFtaWMgcG9ydCBzcGFjZS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5ET1RTIGlzIG5v dCBob3N0aW5nIG5vbiAoRClUTFMgQ09BUCwgYW5kIHNvIHdlIHdpbGwgYmUgYnJlYWtpbmcgdGhl IE1VU1QgZm9yIHBvcnQgNTY4My4mbmJzcDsgSSBwcm9wb3NlIHRoYXQgd2UgZG8gdGhlIGZvbGxv d2luZyBmb3IgdGhlIHNpZ25hbCBjaGFubmVsIHNwZWMgYW5kIHN1cHBvcnQNCiByZXNvdXJjZSBk aXNjb3ZlcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjEpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlVwZGF0ZQ0KIHRoZSAyIHBhdGhzIChzaWduYWwgYW5kIGNvbmZpZ3Vy YXRpb24pIGluIHRoZSBzcGVjaWZpY2F0aW9uLCB3aGVuIGNhbiB0aGVuIGJlIHRoZSBkZWZhdWx0 IHZhbHVlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDt2ZXJzaW9u JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7ZG90cy1zaWdu YWwmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDtzaWduYWwm cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+VG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDt2MSZxdW90 OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmx0OyZsdDsgV2UgYXJlIHYxIGFzIGRlc2NyaWJlZCBpbiB0aGUgdGV4dDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O2RvdHMtc2lnbmFsJnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7bWl0aWdhdGlvbiZxdW90OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Jmx0OyBvdmVybG9hZGVkIHVzZSBvZiBz aWduYWwsIHRoaXMgaXMgdGhlIG1pdGlnYXRlIHBhcnQgb2YgZG90cy1zaWduYWw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW5kPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7dmVyc2lvbiZxdW90OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O2RvdHMtc2lnbmFsJnF1b3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7Y29uZmlnJnF1b3Q7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7djEmcXVvdDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDtkb3RzLXNpZ25hbCZxdW90OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O2NvbmZpZ3VyYXRpb24mcXVvdDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Mik8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+QWRkDQogaW4gdGhlIGZvbGxvd2luZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+NS43IFJlc291cmNlIERpc2NvdmVyeTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkFzIHBlciBbUkZDNzI1MiA3LjIgUmVzb3VyY2UgRGlzY292ZXJ5XSB0aGUgRE9UUyBzZXJ2 ZXIgU0hPVUxEIHN1cHBvcnQgdGhlIENvUmUgTGluayBGb3JtYXQgb2YgZGlzY292ZXJhYmxlIHJl c291cmNlIGFzIGRlc2NyaWJlZCBpbiBbUkZDNjY5MF0sIGV4Y2VwdCB3aGVyZSBmdWxseQ0KIG1h bnVhbCBjb25maWd1cmF0aW9uIGlzIGRlc2lyZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHR3byBkaXNj b3ZlcmFibGUgcmVzb3VyY2VzIHRoYXQgU0hPVUxEIGJlIGF2YWlsYWJsZSB0byBhIERPVFMgY2xp ZW50IGFyZSDigJxtaXRpZ2F0aW9u4oCdIGFuZCDigJxjb25maWd1cmF0aW9u4oCdLiZuYnNwOyBJ ZiB0aGUgYXBwcm9wcmlhdGUgVVJJIHBhdGhzIGFyZSByZXR1cm5lZCwgdGhlDQogRE9UUyBjbGll bnQgTVVTVCB1c2UgdGhlbSwgb3ZlcnJpZGluZyBhbnkgZGVmYXVsdCBjb25maWd1cmF0aW9uLiZu YnNwOyBBIERPVFMgY2xpZW50IFNIT1VMRCBkbyBhIHJlc291cmNlIGRpc2NvdmVyeSwgd2hpY2gg aXMgZG9uZSBieSBhIEdFVCByZXF1ZXN0IHRvIOKAnC8ud2VsbGtub3duL2NvcmXigJ08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5IZWFkZXI6IEdFVCAoQ29kZT0wLjAxKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktSG9zdDogJnF1b3Q7aG9zdCZxdW90 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBVcmktUGF0aDogJnF1b3Q7LndlbGxrbm93biZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7Y29yZSZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZpZ3VyZSB4eHg6IEdFVCB0byByZXRyaWV2ZSBkb3RzLXNpZ25h bCByZXNvdXJjZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Db250ZW50LUZvcm1hdDphcHBsaWNhdGlvbi9saW5r LWZvcm1hdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDt2MS9kb3RzLXNpZ25hbC9taXRpZ2F0aW9uJmd0Ozty dD0mcXVvdDttaXRpZ2F0aW9uJnF1b3Q7O3RpdGxlPSZxdW90O0RPVFMgU2lnbmFsIE1pdGlnYXRp b24mcXVvdDs7Y3Q9NjAsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmx0Oy92MS9k b3RzLXNpZ25hbC9jb25maWd1cmF0aW9uJmd0OztydD0mcXVvdDtjb25maWd1cmF0aW9uJnF1b3Q7 O3RpdGxlPSZxdW90O0RPVFMgU2lnbmFsIENvbmZpZ3VyYXRpb24mcXVvdDs7Y3Q9NjA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5GaWd1cmUgeXl5OiBFeGFtcGxlIHJlc3BvbnNlIHRvIEdFVCB0byByZXRyaWV2ZSBk b3RzLXNpZ25hbCByZXNvdXJjZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1ib3R0b206ZG91YmxlIHdpbmRvd3RleHQgMi4yNXB0 O3BhZGRpbmc6MGluIDBpbiAxLjBwdCAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+QXMgdG8gQ29BUCBiZWluZyBvbiBkaWZmZXJlbnQgcG9ydHMgb24gdGhlIHNlcnZlciBob3N0 aW5nIERPVFMgc2VydmVyIChvciBET1RTIGdhdGV3YXkpLCB0aGlzIG1heSBoYXZlIHRvIGJlIGNv bmZpZ3VyYWJsZSBpbiB0aGUgRE9UUyBjbGllbnRzLCBvciBjb25maWd1cmFibGUNCiBvbiB0aGUg RGF0YSBDaGFubmVsIGFzIGFuIGV4dGVuc2lvbiB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKAnFRoZSBET1RT IGNsaWVudCB3aWxsIHBlcmZvcm0gdGhlIHJvb3QgcmVzb3VyY2UgZGlzY292ZXJ5IHByb2NlZHVy ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBkaXNjdXNzZWQg aW4gU2VjdGlvbiAzLjEgb2YgW1JGQzgwNDBdIHRvIGRldGVybWluZSB0aGUgcm9vdCBvZiB0aGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgUkVTVENPTkYgQVBJ LiZuYnNwOyBBZnRlciBkaXNjb3ZlcmluZyB0aGUgUkVTVENPTkYgQVBJIHJvb3QsIHRoZSBET1RT PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IGNsaWVudCB1c2Vz IHRoaXMgdmFsdWUgYXMgdGhlIGluaXRpYWwgcGFydCBvZiB0aGUgcGF0aCBpbiB0aGUgcmVxdWVz dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBVUkksIGluIGFu eSBzdWJzZXF1ZW50IHJlcXVlc3QgdG8gdGhlIERPVFMgc2VydmVyLiZuYnNwOyBUaGUgRE9UUyBz ZXJ2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgbWF5IHN1 cHBvcnQgcmV0cmlldmFsIG9mIHRoZSBZQU5HIG1vZHVsZXMgaXQgc3VwcG9ydHMgKFNlY3Rpb24g My43IGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IFtSRkM4 MDQwXSksIGZvciBleGFtcGxlLCBhIERPVFMgY2xpZW50IG1heSB1c2UgUkVTVENPTkYgdG8gcmV0 cmlldmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgdGhlIGNv bXBhbnkgcHJvcHJpZXRhcnkgWUFORyBtb2R1bGVzIHN1cHBvcnRlZCBieSB0aGUgRE9UUyBzZXJ2 ZXIu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkpvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpEb3RzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpEb3RzQGlldGYub3JnIj5E b3RzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG90cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k b3RzPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB17882F1EAC551B7223B3B49CEA5A0DM5PR16MB1788namp_-- From nobody Fri Oct 27 00:20:54 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D77139203; Fri, 27 Oct 2017 00:20:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150908884672.22115.5536801606930175694@ietfa.amsl.com> Date: Fri, 27 Oct 2017 00:20:46 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-06.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 07:20:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-06.txt Pages : 58 Date : 2017-10-27 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-06 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 27 00:26:02 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CC313A044; Fri, 27 Oct 2017 00:26:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150908916108.22228.16554734606756072195@ietfa.amsl.com> Date: Fri, 27 Oct 2017 00:26:01 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-06.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 07:26:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Kaname Nishizuka Liang Xia Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-data-channel-06.txt Pages : 28 Date : 2017-10-27 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data not easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-06 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 27 00:31:35 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D69B13A1F4 for ; Fri, 27 Oct 2017 00:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 kTdCbQ2SLi1j for ; Fri, 27 Oct 2017 00:31:33 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 052AB139203 for ; Fri, 27 Oct 2017 00:31:32 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509089491; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=u wOxGWyeKQ2vLV9HDDp+o+0uufhUKpPVeFk66PcAvm I=; b=MaXVAIJ88dUd8aWJMbniVVfgp2efrDinL+yuPr9NYgyK 5M9XjtTrd6L4JV3jkr2gq0cGA4pXxyxPhv3W5ROC1f/n/LOfnQ j0qPkxn0iYX1ujTcClm2IwkXBnaidUxLg11I72VelGH3/XfUr6 +I3ZQOzdH1eqJy2dhhoVffAD57I= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 225a_2140_c93effac_a767_44ef_994b_04b96062ae25; Fri, 27 Oct 2017 02:31:31 -0500 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 03:31:30 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 27 Oct 2017 03:31:30 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 03:31:30 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Fri, 27 Oct 2017 07:31:28 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0156.007; Fri, 27 Oct 2017 07:31:28 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-06.txt Thread-Index: AQHTTvQ6bTPRuNDyK0ynhxISfWBDCKL3TS5A Date: Fri, 27 Oct 2017 07:31:28 +0000 Message-ID: References: <150908884672.22115.5536801606930175694@ietfa.amsl.com> In-Reply-To: <150908884672.22115.5536801606930175694@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.44.126] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:bkhpuYk8Uv2sxkD3puLk3xDRE1j2XYXq7nbx1VaMzu75H5kxTmE8r8uThEJUdVzmA8ybc7Z4f/lVHg6UFq+BJiYtrdGuyppx2TkezrKUaHa6AlL61cpDIPYrIEIMA7zyIXcEaeBBYydlCBWaTGTEPnSRLFnRDmg4ZHvWA8PV+34TwRucPNZZ5oLiXK5uToYXM4FRVFlZB+YvLiGnEqCRW/UtYbUM/bMpUf9H4VuRofewk7rJbwo6wllKR8x3KQiW/Kq0GDzq/M69EF0YrOX8v0mBEoj0q5gqf9ItglrRw0vzCTRLmkDeeUBko9foQ69nkRehnERYZyWlwXYo6RCqKQ==; 5:NUUtf3y1U1SRsbwmPH7rV+XZwTvYcvYZfAaVpbsmSkTEjUBf/qm2MEqRogIU0ffdRk4U8V2BXP3mDe1U+Xoay1yXqRXYEQrZiLm51kquJD9pAzUK5bL2YQBHZpqmFOUCM7wV6oH24nWb2/eooA/QEw==; 24:SP83kTiOReQS9xdGnyZ0/tpGAyT3xWxmsTG3nYFv+Xai488c48w41x+1MX4d8uzKy/YWCRYyKHMOWl82oY7u/i+3AgzVvgYpx0pYvDhLZ2A=; 7:v90VMHLgpKGGcYn47CIykrhSlHR91MKwy9bMpDZ+fZ4h6wbQIfZ6BDHwO2GF7HNOsuvzoihdoh/PSqnBND/+13cpona/+FEFL/68ZX/uG6Jo7Y0f2VHNpjQ3W9f86/AgxgeT4jzZGRl3yT/+7u/CleO1T+vZGyAhCYT9a/8b0hIQheXmFHux1cpW4+Qbj+thZXSUjlAR9oKySXxUclNj5lEZp4KjFJTcf+fJ2jzTquc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bf67c3f5-87a3-46a6-a124-08d51d0cbcb5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(3231020)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(13464003)(189002)(32952001)(199003)(377424004)(2900100001)(6246003)(2501003)(3846002)(478600001)(53546010)(5640700003)(6506006)(6116002)(102836003)(3660700001)(6436002)(966005)(8936002)(77096006)(230783001)(101416001)(86362001)(72206003)(229853002)(3280700002)(66066001)(305945005)(7736002)(74316002)(2906002)(105586002)(106356001)(4001150100001)(14454004)(189998001)(50986999)(1730700003)(6916009)(81166006)(81156014)(76176999)(99286003)(2950100002)(8676002)(25786009)(68736007)(2351001)(97736004)(80792005)(7696004)(33656002)(316002)(53936002)(6306002)(55016002)(9686003)(5660300001)(54356999)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bf67c3f5-87a3-46a6-a124-08d51d0cbcb5 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 07:31:28.4219 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6145> : inlines <6149> : streams <1768546> : uri <2523122> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-06.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 07:31:34 -0000 This revision https://tools.ietf.org/html/draft-ietf-dots-signal-channel-06= and https://tools.ietf.org/html/draft-ietf-dots-data-channel-06 addresses = various comments from Jon,=20 especially related to the usage of 'client-identifier'. -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, October 27, 2017 12:51 PM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-06.txt > Pages : 58 > Date : 2017-10-27 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. A companion > document defines the DOTS data channel, a separate reliable > communication layer for DOTS management and configuration. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-06 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Oct 27 01:11:20 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374CB13942F for ; Fri, 27 Oct 2017 01:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 5dUd3Njy97zz for ; Fri, 27 Oct 2017 01:11:16 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 6139D138FA0 for ; Fri, 27 Oct 2017 01:11:16 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509091875; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=f XmMrDClvXNOYMhyceMua972RIwQae3oKSDoDTVwKr c=; b=AR9mqE3hqTWuFy/E5dTFebwixQCVAx8BVbdP3iEdP6Zj nkL767hOpS469YH/N6zeOktWu/Cqh2Mkbw/PzrhxCZqxcN50B3 CW8h/3MI5atwZ9MeTKjy1WVhiQ868d7M9X8Rm3S8v2KXaRDPWw Rz7IcCzEfyCOqxYIWMeu4ndELZc= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 1b97_4770_1528c957_26bb_4378_96a5_c6b99a110bfd; Fri, 27 Oct 2017 03:11:15 -0500 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 02:11:12 -0600 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 02:11:11 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 27 Oct 2017 02:11:11 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 02:11:11 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Fri, 27 Oct 2017 08:11:10 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0156.007; Fri, 27 Oct 2017 08:11:09 +0000 From: "Konda, Tirumaleswar Reddy" To: "Mortensen, Andrew" CC: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS signal and resource path discovery Thread-Index: AdNOYfsbT1udcdezQbua6sZ/aw7wYAAAz3awAAEZqQAAJFkVkA== Date: Fri, 27 Oct 2017 08:11:09 +0000 Message-ID: References: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> <0CEBEED4-F958-467A-98D5-54F7C4CB0883@arbor.net> In-Reply-To: <0CEBEED4-F958-467A-98D5-54F7C4CB0883@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.88.205] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:J7B+rlgzFrD0n44f6vr2pE7Is/UF2IPwbf2pOIVMG5b72T0NFc7tbu5Gb0cNrxp2L9Zddf4iBlhqfnZmWzckUskB06fA64aQYTK3k2JnoJn2pb3jsXXkqIIJYD0dwcxgp42jIrieMQrZ3/4/1DyvgK1MkRD/dEiFzFZRMV6UNpI07tLAYg3C/ZeCRUSOojyhWBN8E7exHLB5nFm3Lg6/dsfSYotfQlMH+5B95eHQ4ysDfUnwW897GLyaVCHmckS2bQpltQTpUCEnnFwgY9Ug9JC0oaW0agBD8rKKirwp+UO92IGkwkDvQ8Nb/Kv6KTQX6AZh02OSCwmNfXDEUF0x6g==; 5:PNl3/CjEeBxj+5WpdItRYLpD0+kyy0M2Knf2WXo6RUPGflcXDm74biTH7+GRPYb3Iz8H59lekWqb/69pNAhKL4QJ+gxjhUswFB+oHLOQe2cpTyjVgwAh5ljpSSbBE/OQJCWZ5jgg636euTLvk4kcBg==; 24:ml6X18oKLjlR0gFi7tqhIrsliR4vY56D9zeDy2wqAxErVpJGszl7cg17T+DIBrKBGUmEdgsedbMELdkNLoRsyXwdgo1Qe3NlLshOk06HBKY=; 7:RTyxLhukw69vLnZZ6scLhJ3BN85s46zGP2XA1d7tlt2RhVUhixZeX4Wsq2qBm44B0zG0+I/4awDXrMNoUBo5BtONmmLGrEX+NjzF82hYRHjZZOroL4n6B0FJ8KpK2pEoM1HGb+6uVw19F7mdXfgBTeuF9MXaO8c1ewjv4TCLTUWuUkHwzzkPKZ4jfgbjlcWCkYV+JXDie7/1gBhBE+sEoMLd2sBNHV/+iRH9U4iJrak= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4c50ebe6-1b03-41b7-e322-08d51d124827 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(79290750141951)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3231020)(3002001)(6041248)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(189002)(24454002)(199003)(69224002)(32952001)(72206003)(606006)(3846002)(68736007)(81156014)(2900100001)(106356001)(102836003)(6116002)(8936002)(790700001)(105586002)(8676002)(81166006)(236005)(4326008)(3660700001)(9686003)(3280700002)(229853002)(97736004)(54896002)(77096006)(6506006)(6436002)(55016002)(19609705001)(99286003)(53936002)(6246003)(80792005)(6306002)(478600001)(7736002)(2906002)(966005)(2950100002)(5660300001)(54906003)(86362001)(101416001)(25786009)(189998001)(6916009)(74316002)(53546010)(7696004)(76176999)(50986999)(66066001)(14454004)(316002)(33656002)(54356999)(21314002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788CEDB49A690C0DC38B7A0EA5A0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4c50ebe6-1b03-41b7-e322-08d51d124827 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 08:11:09.8577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6145> : inlines <6149> : streams <1768548> : uri <2523138> Archived-At: Subject: Re: [Dots] DOTS signal and resource path discovery X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 08:11:19 -0000 --_000_DM5PR16MB1788CEDB49A690C0DC38B7A0EA5A0DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBhbGwgdGhlIHJlc3BvbnNlcywgd2Ugd2lsbCBhZGRyZXNzIHRoaXMgY29tbWVu dCBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KLVRpcnUNCg0KRnJvbTogTW9ydGVuc2VuLCBBbmRy ZXcgW21haWx0bzphbW9ydGVuc2VuQGFyYm9yLm5ldF0NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVy IDI2LCAyMDE3IDg6MjAgUE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFs ZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPg0KQ2M6IEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0 ZkBqcHNoYWxsb3cuY29tPjsgZG90c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEb3RzXSBET1RT IHNpZ25hbCBhbmQgcmVzb3VyY2UgcGF0aCBkaXNjb3ZlcnkNCg0KDQpPbiBPY3QgMjYsIDIwMTcs IGF0IDEwOjI5IEFNLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRk eV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUu Y29tPj4gd3JvdGU6DQoNCg0KSSBkb27igJl0IHNlZSB0aGUgbmVlZCB0byBjb21wbGljYXRlIHRo ZSBET1RTIHNpZ25hbCBjaGFubmVsIGJ5IGludHJvZHVjaW5nIHJlc291cmNlIGRpc2NvdmVyeSAo c2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1Nzg1KSwNCg0KTWFueSBwcm90b2Nv bHMgbGlrZSBFU1QgdXNlIHdlbGwta25vd24gbG9jYXRpb25zIChlLmcuIGh0dHBzOi8vd3d3LmV4 YW1wbGUuY29tLy53ZWxsLWtub3duL2VzdC8pIHdoZXJlIHVyaS1zdWZmaXggJ2VzdCcgaXMgYWxs b2NhdGVkIGJ5IHRoZSBJQU5BIHRvIGF2b2lkIGNvbGxpc2lvbnMuDQoNCldlIGNhbiBjb25zaWRl ciBhIHNpbWlsYXIgYXBwcm9hY2ggYW5kIHJlcXVlc3QgSUFOQSB0byBhbGxvY2F0ZSB1cmktc3Vm Zml4ICdkb3Rz4oCZLg0KDQpJIGxpa2UgdGhpcyBhcHByb2FjaC4NCg0KYW5kcmV3DQoNCg0KDQoN Cg0KDQoNCg0KRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEpvbiBTaGFsbG93DQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNiwgMjAxNyA3OjI1 IFBNDQpUbzogZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFtE b3RzXSBET1RTIHNpZ25hbCBhbmQgcmVzb3VyY2UgcGF0aCBkaXNjb3ZlcnkNCg0KSGkgdGhlcmUN Cg0KRm9sbG93aW5nIG9uIGZyb20gdGhlIHJlY2VudCB2aXJ0dWFsIGNvbmZlcmVuY2Ugd2l0aCBk aXNjdXNzaW9ucyBhYm91dCB3aGF0IHNob3VsZCBiZSB0aGUgc2lnbmFsIHJlcXVlc3QgcGF0aCAo c2hvdWxkIC53ZWxsa25vd24gYmUgaW5jbHVkZWQgaW4gaXQgZXRjLikuDQoNClJGQzcyNTIgNy4x IFNlcnZpY2UgRGlzY292ZXJ5DQrigJxUaGUgQ29BUCBkZWZhdWx0IHBvcnQgbnVtYmVyIDU2ODMg TVVTVCBiZSBzdXBwb3J0ZWQgYnkgYSBzZXJ2ZXIgdGhhdA0KICAgb2ZmZXJzIHJlc291cmNlcyBm b3IgcmVzb3VyY2UgZGlzY292ZXJ5IChzZWUgU2VjdGlvbiA3LjIgYmVsb3cpIGFuZA0KICAgU0hP VUxEIGJlIHN1cHBvcnRlZCBmb3IgcHJvdmlkaW5nIGFjY2VzcyB0byBvdGhlciByZXNvdXJjZXMu ICBUaGUNCiAgIGRlZmF1bHQgcG9ydCBudW1iZXIgNTY4NCBmb3IgRFRMUy1zZWN1cmVkIENvQVAg TUFZIGJlIHN1cHBvcnRlZCBieSBhDQogICBzZXJ2ZXIgZm9yIHJlc291cmNlIGRpc2NvdmVyeSBh bmQgZm9yIHByb3ZpZGluZyBhY2Nlc3MgdG8gb3RoZXINCiAgIHJlc291cmNlcy4gIEluIGFkZGl0 aW9uLCBvdGhlciBlbmRwb2ludHMgbWF5IGJlIGhvc3RlZCBhdCBvdGhlcg0KICAgcG9ydHMsIGUu Zy4sIGluIHRoZSBkeW5hbWljIHBvcnQgc3BhY2Uu4oCdDQoNCkRPVFMgaXMgbm90IGhvc3Rpbmcg bm9uIChEKVRMUyBDT0FQLCBhbmQgc28gd2Ugd2lsbCBiZSBicmVha2luZyB0aGUgTVVTVCBmb3Ig cG9ydCA1NjgzLiAgSSBwcm9wb3NlIHRoYXQgd2UgZG8gdGhlIGZvbGxvd2luZyBmb3IgdGhlIHNp Z25hbCBjaGFubmVsIHNwZWMgYW5kIHN1cHBvcnQgcmVzb3VyY2UgZGlzY292ZXJ5Lg0KDQoxKSAg ICAgIFVwZGF0ZSB0aGUgMiBwYXRocyAoc2lnbmFsIGFuZCBjb25maWd1cmF0aW9uKSBpbiB0aGUg c3BlY2lmaWNhdGlvbiwgd2hlbiBjYW4gdGhlbiBiZSB0aGUgZGVmYXVsdCB2YWx1ZXMuDQogICAg IFVyaS1QYXRoOiAidmVyc2lvbiINCiAgICAgVXJpLVBhdGg6ICJkb3RzLXNpZ25hbCINCiAgICAg VXJpLVBhdGg6ICJzaWduYWwiDQpUbw0KICAgICBVcmktUGF0aDogInYxIiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDw8IFdlIGFyZSB2MSBhcyBkZXNjcmliZWQgaW4gdGhlIHRleHQNCiAg ICAgVXJpLVBhdGg6ICJkb3RzLXNpZ25hbCINCiAgICAgVXJpLVBhdGg6ICJtaXRpZ2F0aW9uIiAg ICAgICAgICAgICAgICAgPDwgb3ZlcmxvYWRlZCB1c2Ugb2Ygc2lnbmFsLCB0aGlzIGlzIHRoZSBt aXRpZ2F0ZSBwYXJ0IG9mIGRvdHMtc2lnbmFsDQogICAgICAgICAgICAgICBBbmQNCiAgICAgVXJp LVBhdGg6ICJ2ZXJzaW9uIg0KICAgICBVcmktUGF0aDogImRvdHMtc2lnbmFsIg0KICAgICBVcmkt UGF0aDogImNvbmZpZyINClRvDQogICAgIFVyaS1QYXRoOiAidjEiDQogICAgIFVyaS1QYXRoOiAi ZG90cy1zaWduYWwiDQogICAgIFVyaS1QYXRoOiAiY29uZmlndXJhdGlvbiINCjIpICAgICAgQWRk IGluIHRoZSBmb2xsb3dpbmcNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCjUuNyBSZXNvdXJjZSBEaXNjb3ZlcnkNCg0KQXMgcGVyIFtSRkM3MjUyIDcu MiBSZXNvdXJjZSBEaXNjb3ZlcnldIHRoZSBET1RTIHNlcnZlciBTSE9VTEQgc3VwcG9ydCB0aGUg Q29SZSBMaW5rIEZvcm1hdCBvZiBkaXNjb3ZlcmFibGUgcmVzb3VyY2UgYXMgZGVzY3JpYmVkIGlu IFtSRkM2NjkwXSwgZXhjZXB0IHdoZXJlIGZ1bGx5IG1hbnVhbCBjb25maWd1cmF0aW9uIGlzIGRl c2lyZWQuDQoNClRoZSB0d28gZGlzY292ZXJhYmxlIHJlc291cmNlcyB0aGF0IFNIT1VMRCBiZSBh dmFpbGFibGUgdG8gYSBET1RTIGNsaWVudCBhcmUg4oCcbWl0aWdhdGlvbuKAnSBhbmQg4oCcY29u ZmlndXJhdGlvbuKAnS4gIElmIHRoZSBhcHByb3ByaWF0ZSBVUkkgcGF0aHMgYXJlIHJldHVybmVk LCB0aGUgRE9UUyBjbGllbnQgTVVTVCB1c2UgdGhlbSwgb3ZlcnJpZGluZyBhbnkgZGVmYXVsdCBj b25maWd1cmF0aW9uLiAgQSBET1RTIGNsaWVudCBTSE9VTEQgZG8gYSByZXNvdXJjZSBkaXNjb3Zl cnksIHdoaWNoIGlzIGRvbmUgYnkgYSBHRVQgcmVxdWVzdCB0byDigJwvLndlbGxrbm93bi9jb3Jl 4oCdDQoNCkhlYWRlcjogR0VUIChDb2RlPTAuMDEpDQogICAgIFVyaS1Ib3N0OiAiaG9zdCINCiAg ICAgVXJpLVBhdGg6ICIud2VsbGtub3duIg0KICAgICBVcmktUGF0aDogImNvcmUiDQoNCkZpZ3Vy ZSB4eHg6IEdFVCB0byByZXRyaWV2ZSBkb3RzLXNpZ25hbCByZXNvdXJjZXMNCg0KQ29udGVudC1G b3JtYXQ6YXBwbGljYXRpb24vbGluay1mb3JtYXQNCg0KPHYxL2RvdHMtc2lnbmFsL21pdGlnYXRp b24+O3J0PSJtaXRpZ2F0aW9uIjt0aXRsZT0iRE9UUyBTaWduYWwgTWl0aWdhdGlvbiI7Y3Q9NjAs DQo8L3YxL2RvdHMtc2lnbmFsL2NvbmZpZ3VyYXRpb24+O3J0PSJjb25maWd1cmF0aW9uIjt0aXRs ZT0iRE9UUyBTaWduYWwgQ29uZmlndXJhdGlvbiI7Y3Q9NjANCg0KRmlndXJlIHl5eTogRXhhbXBs ZSByZXNwb25zZSB0byBHRVQgdG8gcmV0cmlldmUgZG90cy1zaWduYWwgcmVzb3VyY2VzDQoNCg0K QXMgdG8gQ29BUCBiZWluZyBvbiBkaWZmZXJlbnQgcG9ydHMgb24gdGhlIHNlcnZlciBob3N0aW5n IERPVFMgc2VydmVyIChvciBET1RTIGdhdGV3YXkpLCB0aGlzIG1heSBoYXZlIHRvIGJlIGNvbmZp Z3VyYWJsZSBpbiB0aGUgRE9UUyBjbGllbnRzLCBvciBjb25maWd1cmFibGUgb24gdGhlIERhdGEg Q2hhbm5lbCBhcyBhbiBleHRlbnNpb24gdG8NCg0K4oCcVGhlIERPVFMgY2xpZW50IHdpbGwgcGVy Zm9ybSB0aGUgcm9vdCByZXNvdXJjZSBkaXNjb3ZlcnkgcHJvY2VkdXJlDQogICBkaXNjdXNzZWQg aW4gU2VjdGlvbiAzLjEgb2YgW1JGQzgwNDBdIHRvIGRldGVybWluZSB0aGUgcm9vdCBvZiB0aGUN CiAgIFJFU1RDT05GIEFQSS4gIEFmdGVyIGRpc2NvdmVyaW5nIHRoZSBSRVNUQ09ORiBBUEkgcm9v dCwgdGhlIERPVFMNCiAgIGNsaWVudCB1c2VzIHRoaXMgdmFsdWUgYXMgdGhlIGluaXRpYWwgcGFy dCBvZiB0aGUgcGF0aCBpbiB0aGUgcmVxdWVzdA0KICAgVVJJLCBpbiBhbnkgc3Vic2VxdWVudCBy ZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlci4gIFRoZSBET1RTIHNlcnZlcg0KICAgbWF5IHN1cHBv cnQgcmV0cmlldmFsIG9mIHRoZSBZQU5HIG1vZHVsZXMgaXQgc3VwcG9ydHMgKFNlY3Rpb24gMy43 IGluDQogICBbUkZDODA0MF0pLCBmb3IgZXhhbXBsZSwgYSBET1RTIGNsaWVudCBtYXkgdXNlIFJF U1RDT05GIHRvIHJldHJpZXZlDQogICB0aGUgY29tcGFueSBwcm9wcmlldGFyeSBZQU5HIG1vZHVs ZXMgc3VwcG9ydGVkIGJ5IHRoZSBET1RTIHNlcnZlci7igJ0NCg0KUmVnYXJkcw0KDQpKb24NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRvdHMgbWFp bGluZyBsaXN0DQpEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoNCg== --_000_DM5PR16MB1788CEDB49A690C0DC38B7A0EA5A0DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlRoYW5rcyBmb3IgYWxsIHRoZSByZXNwb25zZXMsIHdlIHdpbGwgYWRkcmVzcyB0aGlzIGNvbW1l bnQgaW4gdGhlIG5leHQgcmV2aXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi1UaXJ1PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3Nl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBNb3J0ZW5zZW4sIEFuZHJldyBbbWFpbHRvOmFtb3J0ZW5zZW5AYXJib3IubmV0 XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDg6MjAgUE08 YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0O1RpcnVtYWxlc3dh clJlZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKb24gU2hhbGxvdyAm bHQ7c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSZndDs7IGRvdHNAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBET1RTIHNpZ25hbCBhbmQgcmVzb3VyY2UgcGF0aCBkaXNj b3Zlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBPY3QgMjYsIDIwMTcsIGF0IDEwOjI5IEFNLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZs dDs8YSBocmVmPSJtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+VGly dW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBkb27igJl0IHNlZSB0aGUgbmVlZCB0byBj b21wbGljYXRlIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIGJ5IGludHJvZHVjaW5nIHJlc291cmNl IGRpc2NvdmVyeSAoc2VlIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1 Nzg1Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTc4NTwvc3Bhbj48L2E+KSwgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+TWFueSBwcm90b2NvbHMgbGlrZSBFU1QgdXNlIHdlbGwta25vd24gbG9j YXRpb25zIChlLmcuIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmV4YW1wbGUuY29tLy53ZWxsLWtub3du L2VzdC8iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmV4YW1wbGUuY29t Ly53ZWxsLWtub3duL2VzdC88L3NwYW4+PC9hPikgd2hlcmUgdXJpLXN1ZmZpeCAnZXN0JyBpcyBh bGxvY2F0ZWQgYnkgdGhlIElBTkEgdG8gYXZvaWQgY29sbGlzaW9ucy4gPC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2UgY2FuIGNvbnNpZGVyIGEgc2ltaWxh ciBhcHByb2FjaCBhbmQgcmVxdWVzdCBJQU5BIHRvIGFsbG9jYXRlIHVyaS1zdWZmaXggJ2RvdHPi gJkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgbGlrZSB0aGlzIGFwcHJvYWNoLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmRyZXc8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RG90cw0KIFs8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Kb24gU2hhbGxv dzxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5UaHVyc2RheSwgT2N0b2JlciAyNiwgMjAxNyA3OjI1IFBNPGJyPg0KPGI+VG86 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ W0RvdHNdIERPVFMgc2lnbmFsIGFuZCByZXNvdXJjZSBwYXRoIGRpc2NvdmVyeTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkhpIHRoZXJlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Rm9sbG93aW5nIG9uIGZyb20gdGhlIHJlY2VudCB2aXJ0dWFs IGNvbmZlcmVuY2Ugd2l0aCBkaXNjdXNzaW9ucyBhYm91dCB3aGF0IHNob3VsZCBiZSB0aGUgc2ln bmFsIHJlcXVlc3QgcGF0aCAoc2hvdWxkIC53ZWxsa25vd24gYmUgaW5jbHVkZWQgaW4gaXQgZXRj LikuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+UkZDNzI1MiA3LjEgU2VydmljZSBEaXNjb3Zlcnk8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igJxUaGUgQ29BUCBkZWZhdWx0 IHBvcnQgbnVtYmVyIDU2ODMgTVVTVCBiZSBzdXBwb3J0ZWQgYnkgYSBzZXJ2ZXIgdGhhdDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OyZuYnNwOyBvZmZlcnMgcmVzb3VyY2VzIGZvciByZXNvdXJjZSBkaXNjb3ZlcnkgKHNlZSBTZWN0 aW9uIDcuMiBiZWxvdykgYW5kPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IFNIT1VMRCBiZSBzdXBwb3J0ZWQgZm9yIHBy b3ZpZGluZyBhY2Nlc3MgdG8gb3RoZXIgcmVzb3VyY2VzLiZuYnNwOyBUaGU8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsg ZGVmYXVsdCBwb3J0IG51bWJlciA1Njg0IGZvciBEVExTLXNlY3VyZWQgQ29BUCBNQVkgYmUgc3Vw cG9ydGVkIGJ5IGE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgc2VydmVyIGZvciByZXNvdXJjZSBkaXNjb3ZlcnkgYW5k IGZvciBwcm92aWRpbmcgYWNjZXNzIHRvIG90aGVyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IHJlc291cmNlcy4mbmJz cDsgSW4gYWRkaXRpb24sIG90aGVyIGVuZHBvaW50cyBtYXkgYmUgaG9zdGVkIGF0IG90aGVyPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7Jm5ic3A7IHBvcnRzLCBlLmcuLCBpbiB0aGUgZHluYW1pYyBwb3J0IHNwYWNlLuKAnTwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkRPVFMgaXMgbm90IGhvc3Rpbmcgbm9uIChEKVRMUyBDT0FQLCBhbmQgc28gd2Ugd2lsbCBiZSBi cmVha2luZyB0aGUgTVVTVCBmb3IgcG9ydCA1NjgzLiZuYnNwOyBJIHByb3Bvc2UgdGhhdCB3ZSBk byB0aGUgZm9sbG93aW5nIGZvciB0aGUgc2lnbmFsIGNoYW5uZWwgc3BlYyBhbmQgc3VwcG9ydA0K IHJlc291cmNlIGRpc2NvdmVyeS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+MSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+VXBkYXRlDQogdGhlIDIgcGF0aHMgKHNpZ25hbCBhbmQgY29uZmln dXJhdGlvbikgaW4gdGhlIHNwZWNpZmljYXRpb24sIHdoZW4gY2FuIHRoZW4gYmUgdGhlIGRlZmF1 bHQgdmFsdWVzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVXJpLVBhdGg6ICZxdW90O3ZlcnNpb24mcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDtkb3RzLXNpZ25hbCZxdW90 Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBh dGg6ICZxdW90O3NpZ25hbCZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ubzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90 O3YxJnF1b3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbHQ7Jmx0OyBXZSBhcmUgdjEgYXMgZGVzY3JpYmVkIGluIHRoZSB0ZXh0PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1 b3Q7ZG90cy1zaWduYWwmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDttaXRpZ2F0aW9uJnF1b3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsmbHQ7IG92ZXJsb2FkZWQgdXNlIG9mIHNp Z25hbCwgdGhpcyBpcyB0aGUgbWl0aWdhdGUgcGFydCBvZiBkb3RzLXNpZ25hbDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBBbmQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDt2ZXJzaW9uJnF1b3Q7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7ZG90cy1z aWduYWwmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFVyaS1QYXRoOiAmcXVvdDtjb25maWcmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ VG88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS1Q YXRoOiAmcXVvdDt2MSZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O2RvdHMtc2lnbmFsJnF1b3Q7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7Y29u ZmlndXJhdGlvbiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4yKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5BZGQNCiBpbiB0aGUgZm9sbG93aW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj41LjcgUmVzb3VyY2UgRGlzY292ZXJ5PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QXMg cGVyIFtSRkM3MjUyIDcuMiBSZXNvdXJjZSBEaXNjb3ZlcnldIHRoZSBET1RTIHNlcnZlciBTSE9V TEQgc3VwcG9ydCB0aGUgQ29SZSBMaW5rIEZvcm1hdCBvZiBkaXNjb3ZlcmFibGUgcmVzb3VyY2Ug YXMgZGVzY3JpYmVkIGluIFtSRkM2NjkwXSwgZXhjZXB0IHdoZXJlIGZ1bGx5DQogbWFudWFsIGNv bmZpZ3VyYXRpb24gaXMgZGVzaXJlZC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgdHdvIGRpc2NvdmVyYWJsZSByZXNvdXJj ZXMgdGhhdCBTSE9VTEQgYmUgYXZhaWxhYmxlIHRvIGEgRE9UUyBjbGllbnQgYXJlIOKAnG1pdGln YXRpb27igJ0gYW5kIOKAnGNvbmZpZ3VyYXRpb27igJ0uJm5ic3A7IElmIHRoZSBhcHByb3ByaWF0 ZSBVUkkgcGF0aHMgYXJlIHJldHVybmVkLCB0aGUNCiBET1RTIGNsaWVudCBNVVNUIHVzZSB0aGVt LCBvdmVycmlkaW5nIGFueSBkZWZhdWx0IGNvbmZpZ3VyYXRpb24uJm5ic3A7IEEgRE9UUyBjbGll bnQgU0hPVUxEIGRvIGEgcmVzb3VyY2UgZGlzY292ZXJ5LCB3aGljaCBpcyBkb25lIGJ5IGEgR0VU IHJlcXVlc3QgdG8g4oCcLy53ZWxsa25vd24vY29yZeKAnTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhlYWRlcjogR0VUIChDb2Rl PTAuMDEpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS1Ib3N0OiAmcXVvdDtob3N0JnF1b3Q7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDsud2VsbGtub3duJnF1b3Q7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDtjb3JlJnF1b3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RmlndXJlIHh4eDogR0VUIHRvIHJldHJpZXZlIGRvdHMtc2lnbmFsIHJlc291cmNlczwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNv bnRlbnQtRm9ybWF0OmFwcGxpY2F0aW9uL2xpbmstZm9ybWF0PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmx0O3YxL2RvdHMtc2ln bmFsL21pdGlnYXRpb24mZ3Q7O3J0PSZxdW90O21pdGlnYXRpb24mcXVvdDs7dGl0bGU9JnF1b3Q7 RE9UUyBTaWduYWwgTWl0aWdhdGlvbiZxdW90OztjdD02MCw8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbHQ7L3YxL2RvdHMtc2lnbmFsL2Nv bmZpZ3VyYXRpb24mZ3Q7O3J0PSZxdW90O2NvbmZpZ3VyYXRpb24mcXVvdDs7dGl0bGU9JnF1b3Q7 RE9UUyBTaWduYWwgQ29uZmlndXJhdGlvbiZxdW90OztjdD02MDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZpZ3VyZSB5eXk6IEV4 YW1wbGUgcmVzcG9uc2UgdG8gR0VUIHRvIHJldHJpZXZlIGRvdHMtc2lnbmFsIHJlc291cmNlczwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpkb3VibGUgd2luZG93dGV4dCAyLjI1 cHQ7cGFkZGluZzowaW4gMGluIDEuMHB0IDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BcyB0 byBDb0FQIGJlaW5nIG9uIGRpZmZlcmVudCBwb3J0cyBvbiB0aGUgc2VydmVyIGhvc3RpbmcgRE9U UyBzZXJ2ZXIgKG9yIERPVFMgZ2F0ZXdheSksIHRoaXMgbWF5IGhhdmUgdG8gYmUgY29uZmlndXJh YmxlIGluIHRoZSBET1RTIGNsaWVudHMsIG9yIGNvbmZpZ3VyYWJsZQ0KIG9uIHRoZSBEYXRhIENo YW5uZWwgYXMgYW4gZXh0ZW5zaW9uIHRvPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCcVGhlIERPVFMgY2xpZW50IHdpbGwgcGVy Zm9ybSB0aGUgcm9vdCByZXNvdXJjZSBkaXNjb3ZlcnkgcHJvY2VkdXJlPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IGRp c2N1c3NlZCBpbiBTZWN0aW9uIDMuMSBvZiBbUkZDODA0MF0gdG8gZGV0ZXJtaW5lIHRoZSByb290 IG9mIHRoZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyZuYnNwOyBSRVNUQ09ORiBBUEkuJm5ic3A7IEFmdGVyIGRpc2NvdmVyaW5n IHRoZSBSRVNUQ09ORiBBUEkgcm9vdCwgdGhlIERPVFM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgY2xpZW50IHVzZXMg dGhpcyB2YWx1ZSBhcyB0aGUgaW5pdGlhbCBwYXJ0IG9mIHRoZSBwYXRoIGluIHRoZSByZXF1ZXN0 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7IFVSSSwgaW4gYW55IHN1YnNlcXVlbnQgcmVxdWVzdCB0byB0aGUgRE9UUyBz ZXJ2ZXIuJm5ic3A7IFRoZSBET1RTIHNlcnZlcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBtYXkgc3VwcG9ydCByZXRy aWV2YWwgb2YgdGhlIFlBTkcgbW9kdWxlcyBpdCBzdXBwb3J0cyAoU2VjdGlvbiAzLjcgaW48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDsmbmJzcDsgW1JGQzgwNDBdKSwgZm9yIGV4YW1wbGUsIGEgRE9UUyBjbGllbnQgbWF5IHVzZSBS RVNUQ09ORiB0byByZXRyaWV2ZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyB0aGUgY29tcGFueSBwcm9wcmlldGFyeSBZ QU5HIG1vZHVsZXMgc3VwcG9ydGVkIGJ5IHRoZSBET1RTIHNlcnZlci7igJ08L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRz PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Sm9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K RG90cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyI+RG90 c0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RvdHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90 czwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB1788CEDB49A690C0DC38B7A0EA5A0DM5PR16MB1788namp_-- From nobody Fri Oct 27 01:30:26 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E6D13942F for ; Fri, 27 Oct 2017 01:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_5SPIymSBlx for ; Fri, 27 Oct 2017 01:30:22 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 3DBC0138726 for ; Fri, 27 Oct 2017 01:30:22 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e801z-0002aI-Am; Fri, 27 Oct 2017 09:30:19 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "Mortensen, Andrew" , References: <006c01d34e62$00b80da0$022828e0$@jpshallow.com> <0CEBEED4-F958-467A-98D5-54F7C4CB0883@arbor.net> <018601d34e9b$3beb2540$b3c16fc0$@jpshallow.com> In-Reply-To: Date: Fri, 27 Oct 2017 09:30:19 +0100 Message-ID: <01f701d34efd$d2e1eb70$78a5c250$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F8_01D34F06.34A91290" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJzltLgqVNK+TC2PfzhCbifUE2P7AM1pYPqAJ29zH4CAthweAF3THAJoXxhAlA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS signal and resource path discovery X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 08:30:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01F8_01D34F06.34A91290 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 My suggest would be to go with uri-suffix =E2=80=9Cdots=E2=80=9D and = have the final Uri-Path: as =E2=80=9Calias=E2=80=9D or = =E2=80=9Cfilter=E2=80=9D for the DOTS data channel. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 October 2017 07:44 To: Jon Shallow; 'Mortensen, Andrew'; dots@ietf.org Subject: Re: [Dots] DOTS signal and resource path discovery =20 Hi Jon, =20 Thanks, The URI path can look as follows: =20 Uri-Host: "host" Uri-Path: "URI suffix" Uri-Path: "version" Uri-Path: "mitigate" or "config" =20 IANA will be requested to allocate the uri-suffix =E2=80=9Cdots=E2=80=9D = or =E2=80=9Cdots-signal=E2=80=9D (depending on if the WG decides to take = the same approach for DOTS data channel).=20 =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, October 27, 2017 2:15 AM To: 'Mortensen, Andrew' ; Konda, Tirumaleswar = Reddy ; dots@ietf.org Subject: RE: [Dots] DOTS signal and resource path discovery =20 This works for me. It means that we no longer need = =E2=80=9Cdots-signal=E2=80=9D in the path (saves packet space). I still = would like to see =E2=80=9Csignal=E2=80=9D in the path renamed to, say, = =E2=80=9Cmitigate=E2=80=9D as DOTS signal covers both mitigation and = configuration. =20 However, what happens if DOTS has a version change from v1 to v2 ? - How do we handle this (unlikely) event? =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Mortensen, = Andrew Sent: 26 October 2017 15:50 To: Konda, Tirumaleswar Reddy Cc: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS signal and resource path discovery =20 =20 On Oct 26, 2017, at 10:29 AM, Konda, Tirumaleswar Reddy = wrote: =20 I don=E2=80=99t see the need to complicate the DOTS signal channel by = introducing resource discovery (see = = https://tools.ietf.org/html/rfc5785),=20 Many protocols like EST use well-known locations (e.g. = = https://www.example.com/.well-known/est/) where uri-suffix 'est' is = allocated by the IANA to avoid collisions.=20 We can consider a similar approach and request IANA to allocate = uri-suffix 'dots=E2=80=99. =20 I like this approach. =20 andrew =20 =20 =20 =20 =20 =20 =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, October 26, 2017 7:25 PM To: dots@ietf.org Subject: [Dots] DOTS signal and resource path discovery =20 Hi there =20 Following on from the recent virtual conference with discussions about = what should be the signal request path (should .wellknown be included in = it etc.). =20 RFC7252 7.1 Service Discovery =E2=80=9CThe CoAP default port number 5683 MUST be supported by a server = that offers resources for resource discovery (see Section 7.2 below) and SHOULD be supported for providing access to other resources. The default port number 5684 for DTLS-secured CoAP MAY be supported by a server for resource discovery and for providing access to other resources. In addition, other endpoints may be hosted at other ports, e.g., in the dynamic port space.=E2=80=9D =20 DOTS is not hosting non (D)TLS COAP, and so we will be breaking the MUST = for port 5683. I propose that we do the following for the signal = channel spec and support resource discovery. =20 1) Update the 2 paths (signal and configuration) in the = specification, when can then be the default values. Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "signal" To Uri-Path: "v1" << We are v1 as = described in the text Uri-Path: "dots-signal" Uri-Path: "mitigation" << overloaded use of signal, = this is the mitigate part of dots-signal And Uri-Path: "version" Uri-Path: "dots-signal" Uri-Path: "config" To Uri-Path: "v1" Uri-Path: "dots-signal" Uri-Path: "configuration" 2) Add in the following =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.7 Resource Discovery =20 As per [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support = the CoRe Link Format of discoverable resource as described in [RFC6690], = except where fully manual configuration is desired. =20 The two discoverable resources that SHOULD be available to a DOTS client = are =E2=80=9Cmitigation=E2=80=9D and =E2=80=9Cconfiguration=E2=80=9D. = If the appropriate URI paths are returned, the DOTS client MUST use = them, overriding any default configuration. A DOTS client SHOULD do a = resource discovery, which is done by a GET request to = =E2=80=9C/.wellknown/core=E2=80=9D =20 Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".wellknown" Uri-Path: "core" =20 Figure xxx: GET to retrieve dots-signal resources =20 Content-Format:application/link-format =20 ;rt=3D"mitigation";title=3D"DOTS Signal = Mitigation";ct=3D60, ;rt=3D"configuration";title=3D"DOTS = Signal Configuration";ct=3D60 =20 Figure yyy: Example response to GET to retrieve dots-signal resources =20 =20 As to CoAP being on different ports on the server hosting DOTS server = (or DOTS gateway), this may have to be configurable in the DOTS clients, = or configurable on the Data Channel as an extension to =20 =E2=80=9CThe DOTS client will perform the root resource discovery = procedure discussed in Section 3.1 of [RFC8040] to determine the root of the RESTCONF API. After discovering the RESTCONF API root, the DOTS client uses this value as the initial part of the path in the request URI, in any subsequent request to the DOTS server. The DOTS server may support retrieval of the YANG modules it supports (Section 3.7 in [RFC8040]), for example, a DOTS client may use RESTCONF to retrieve the company proprietary YANG modules supported by the DOTS = server.=E2=80=9D =20 Regards =20 Jon =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_01F8_01D34F06.34A91290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

My suggest would be to go with uri-suffix =E2=80=9Cdots=E2=80=9D and = have the final Uri-Path: as =E2=80=9Calias=E2=80=9D or = =E2=80=9Cfilter=E2=80=9D for the DOTS data = channel.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 27 October 2017 07:44
To: Jon Shallow; = 'Mortensen, Andrew'; dots@ietf.org
Subject: Re: [Dots] DOTS = signal and resource path discovery

 

Hi = Jon,

 =

Thanks, = The URI path can look as follows:

 =

     Uri-Host: = "host"

     Uri-Path: "URI suffix"

     Uri-Path: = "version"

     Uri-Path: = "mitigate" or "config"

   

IANA will = be requested to allocate the uri-suffix =E2=80=9Cdots=E2=80=9D or = =E2=80=9Cdots-signal=E2=80=9D (depending on if the WG decides to take = the same approach for DOTS data channel).

 =

-Tiru=

 =

From: Jon = Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, October 27, 2017 2:15 AM
To: = 'Mortensen, Andrew' <amortensen@arbor.net>; = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] DOTS signal and resource path = discovery

 

This works for me.  It means that we no longer need = =E2=80=9Cdots-signal=E2=80=9D in the path (saves packet space).  I = still would like to see =E2=80=9Csignal=E2=80=9D in the path renamed to, = say, =E2=80=9Cmitigate=E2=80=9D as DOTS signal covers both mitigation = and configuration.

 

However, what happens if DOTS has a version change from v1 to v2 = ?

- How do we handle this (unlikely) event?

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On = Behalf Of Mortensen, Andrew
Sent: 26 October 2017 = 15:50
To: Konda, Tirumaleswar Reddy
Cc: Jon Shallow; = dots@ietf.org
Subject: = Re: [Dots] DOTS signal and resource path = discovery

 

 

On Oct 26, 2017, at 10:29 AM, Konda, Tirumaleswar = Reddy <TirumaleswarReddy_Kond= a@McAfee.com> wrote:

 

I =
don=E2=80=99t see the need to complicate the DOTS signal channel by =
introducing resource discovery (see https://tools.ietf.org/html/rfc5785), =

Many =
protocols like EST use well-known locations (e.g. https://www.example.com/.well-known/est/) where uri-suffix 'est' is allocated by the IANA to avoid collisions. =

We can =
consider a similar approach and request IANA to allocate uri-suffix =
'dots=E2=80=99.
 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon = Shallow
Sent: Thursday, October 26, 2017 = 7:25 PM
To: dots@ietf.org
Subject: [Dots] DOTS signal and = resource path discovery

 =

Hi = there

 =

Following = on from the recent virtual conference with discussions about what should = be the signal request path (should .wellknown be included in it = etc.).

 =

RFC7252 = 7.1 Service Discovery

=E2=80=9CTh= e CoAP default port number 5683 MUST be supported by a server = that

  = ; offers resources for resource discovery (see Section 7.2 below) = and

  = ; SHOULD be supported for providing access to other resources.  = The

  = ; default port number 5684 for DTLS-secured CoAP MAY be supported by = a

  = ; server for resource discovery and for providing access to = other

  = ; resources.  In addition, other endpoints may be hosted at = other

  = ; ports, e.g., in the dynamic port = space.=E2=80=9D

 =

DOTS is = not hosting non (D)TLS COAP, and so we will be breaking the MUST for = port 5683.  I propose that we do the following for the signal = channel spec and support resource = discovery.

 =

1)      Update the = 2 paths (signal and configuration) in the specification, when can then = be the default values.

  = ;   Uri-Path: = "version"

  = ;   Uri-Path: = "dots-signal"

  = ;   Uri-Path: = "signal"

To

  = ;   Uri-Path: "v1" =             &= nbsp;           &n= bsp;    << We are v1 as described in the = text

  = ;   Uri-Path: = "dots-signal"

  = ;   Uri-Path: = "mitigation"        &nb= sp;        << overloaded use of = signal, this is the mitigate part of = dots-signal

  = ;            = And

  = ;   Uri-Path: = "version"

  = ;   Uri-Path: = "dots-signal"

  = ;   Uri-Path: = "config"

To

  = ;   Uri-Path: "v1"

  = ;   Uri-Path: = "dots-signal"

  = ;   Uri-Path: = "configuration"

2)      Add in the = following

 =

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

5.7 = Resource Discovery

 =

As per = [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support the CoRe = Link Format of discoverable resource as described in [RFC6690], except = where fully manual configuration is = desired.

 =

The two = discoverable resources that SHOULD be available to a DOTS client are = =E2=80=9Cmitigation=E2=80=9D and =E2=80=9Cconfiguration=E2=80=9D.  = If the appropriate URI paths are returned, the DOTS client MUST use = them, overriding any default configuration.  A DOTS client SHOULD = do a resource discovery, which is done by a GET request to = =E2=80=9C/.wellknown/core=E2=80=9D

 =

Header: = GET (Code=3D0.01)

  = ;   Uri-Host: = "host"

  = ;   Uri-Path: = ".wellknown"

  = ;   Uri-Path: = "core"

 =

Figure = xxx: GET to retrieve dots-signal = resources

 =

Content-For= mat:application/link-format

 =

<v1/dots= -signal/mitigation>;rt=3D"mitigation";title=3D"DOTS = Signal Mitigation";ct=3D60,

</v1/dot= s-signal/configuration>;rt=3D"configuration";title=3D"D= OTS Signal = Configuration";ct=3D60

 =

Figure = yyy: Example response to GET to retrieve dots-signal = resources

 =

 =

As to CoAP = being on different ports on the server hosting DOTS server (or DOTS = gateway), this may have to be configurable in the DOTS clients, or = configurable on the Data Channel as an extension = to

 =

=E2=80=9CTh= e DOTS client will perform the root resource discovery = procedure

  = ; discussed in Section 3.1 of [RFC8040] to determine the root of = the

  = ; RESTCONF API.  After discovering the RESTCONF API root, the = DOTS

  = ; client uses this value as the initial part of the path in the = request

  = ; URI, in any subsequent request to the DOTS server.  The DOTS = server

  = ; may support retrieval of the YANG modules it supports (Section 3.7 = in

  = ; [RFC8040]), for example, a DOTS client may use RESTCONF to = retrieve

  = ; the company proprietary YANG modules supported by the DOTS = server.=E2=80=9D

 =

Regards

 =

Jon

 =

__________= _____________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/= mailman/listinfo/dots

<= p class=3DMsoNormal> 

------=_NextPart_000_01F8_01D34F06.34A91290-- From nobody Fri Oct 27 01:34:57 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366461394E4 for ; Fri, 27 Oct 2017 01:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 4GXcFgif6vhW for ; Fri, 27 Oct 2017 01:34:54 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 491E2138103 for ; Fri, 27 Oct 2017 01:34:54 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509093293; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-exchange-antispam-report-test:x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:spamdiagnosticoutput: spamdiagnosticmetadata:Content-Type:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=Y RYFMd4hi+mQTMHqEVdOfhE54o98VmKyJInZ9lUxsA g=; b=ZZuyi2RmI5ze1DAG6uWYj4zPpNJApK81jsKsjVt9c1WU CbsxtIvMsBwsEXwD6HCrQlw3WDxzcS1XJ4DPVfPRONi4XwNTWK ozuZV7kCl2jI6nB2gw9i28DpPcM5oW6/DuSMpwqvDAnamkq0CT XQH+tWpu96sVfAIJ6gH0riyaj7o= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 1b9d_4742_da93c3f7_0d1e_4731_b5e9_3ea7ba059ba4; Fri, 27 Oct 2017 03:34:53 -0500 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 02:34:52 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 02:34:51 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 27 Oct 2017 02:34:51 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 02:34:50 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Fri, 27 Oct 2017 08:34:49 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0156.007; Fri, 27 Oct 2017 08:34:49 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: Default port for DOTS signal channel Thread-Index: AdNO9p/vkseJmoMGQQ25Q8ucMqlEeA== Date: Fri, 27 Oct 2017 08:34:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.88.205] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:abbOwk2Ml5BtJG0hkRYSJjmckBIP513V8bq6Ck6gRYqjuF7lGcL0HehPYiMYFRElsJd0HPdXSSQOod4+MtXtqKnrqXAEeC1ClH0b00c8T5dpr7FyrnAGTRxs5s7/O0zVLw2PMAdM9jz0IfjykN42VRveg7zOTyrWMFZo6h+KKzI9gbumNzpDf8gZOfQLq7lliZQxsIcg/EM2yAMhGRcX1NM0ptHQ4lbw4VBPdG1NGEUiPz8AzhIsm+bMqF32oSFGsCnJEIIgnb8KkXLnwgdPKYyJLUKyCB2TnPLFmdaRI4zA8H5f5aFAsFyDTcWACWWwM6u6OHNUzFcPJuGMj0s5SQ==; 5:wMHf+C3kNYi4Ud4keZVoZ9Pr/C7+KDP8pAvQKa9ibgefENcpaLrHbFFRl/d4wwcGIuRN1NreS4kRScc7xd+ejuSYZo8i19SeM/Trd6ha5xdheaYMn5vxstTN7T34rSKbwsW3KalvDwXSc3iYGxvHew==; 24:0JtRw2kZHmgksJ+0ro6hSVgVMlDD1GrS3H3GZXUDwfmsjy6Zx6qSKWkQlOPfgmoi9TX9J3JKvyuh8QvSh1nT0fAYU2iqle4mFPEWEoNOMzg=; 7:L3BoWAeXaPDR24wXOgf0yxgf3q6yoyoeErfVDrd3skz7p4dj6doOkqCXVr4JWD6fQ6ELHAv7Xe/3zfEdTnLpzPbYxr09jiWgdpg1iCfq6DBRdIiK7hBAOqlDznN/CdNiNhkUtaVXQGQXNcI4ukdlDq4Yxxku6SQyHEJAxgpfI/pXIauWOHOd0xQwt4RWj2PCZCQmJV7LynCGUonn5RKfTs8UFJeYo3Mhyjig/OPfUNs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9a3c021a-e859-4d62-04ab-08d51d159643 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3231020)(3002001)(6041248)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(32952001)(189002)(53754006)(199003)(25786009)(189998001)(101416001)(74316002)(2501003)(6916009)(2906002)(966005)(5660300001)(7736002)(86362001)(66066001)(14454004)(33656002)(54356999)(316002)(7696004)(50986999)(8936002)(1730700003)(5630700001)(790700001)(105586002)(102836003)(6116002)(8676002)(81166006)(606006)(72206003)(3846002)(81156014)(2900100001)(106356001)(68736007)(99286003)(53936002)(55016002)(80792005)(6306002)(478600001)(5640700003)(3660700001)(9686003)(236005)(2351001)(77096006)(54896002)(97736004)(6436002)(6506006)(3280700002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17882DF8FA85DBC399CC882AEA5A0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9a3c021a-e859-4d62-04ab-08d51d159643 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 08:34:49.3411 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6145> : inlines <6149> : streams <1768550> : uri <2523149> Archived-At: Subject: [Dots] Default port for DOTS signal channel X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 08:34:56 -0000 --_000_DM5PR16MB17882DF8FA85DBC399CC882AEA5A0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The DOTS signal channel draft is currently using the default port 5684 (use= d by (D)TLS secured CoAP), based on the discussions in the interim WG meeti= ng to handle scenarios where DOTS gateway and IOT gateway could be co-locat= ed and for network devices to enforce policies (e.g. QoS) for DOTS signal c= hannel differently, DOTS signal channel needs a different port. If there are no objections from the WG, I plan to update the draft to use a= new port assigned by the IANA from the port number registry. Further, If the WG agrees, and with the WG chairs and Area Directors help a= new port number can be temporarily assigned by the IANA. The same approach= was followed by DPRIVE WG for DNS-over-(D)TLS drafts to get a new port, af= ter the drafts were adopted by the WG and implemented (see https://www.ietf= .org/mail-archive/web/dns-privacy/current/msg00981.html and https://www.iet= f.org/mail-archive/web/dns-privacy/current/msg00922.html). -Tiru --_000_DM5PR16MB17882DF8FA85DBC399CC882AEA5A0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The DOTS signal channel draft is currently using the= default port 5684 (used by (D)TLS secured CoAP), based on the discussions = in the interim WG meeting to handle scenarios where DOTS gateway and IOT ga= teway could be co-located and for network devices to enforce policies (e.g. QoS) for DOTS signal channel dif= ferently, DOTS signal channel needs a different port.

 

If there are no objections from the WG, I plan to up= date the draft to use a new port assigned by the IANA from the port number = registry.

 

Further, If the WG agrees, and with the WG chairs an= d Area Directors help a new port number can be temporarily assigned by the = IANA. The same approach was followed by DPRIVE WG for DNS-over-(D)TLS draft= s to get a new port, after the drafts were adopted by the WG and implemented (see https://www.ietf.org/mail-archive/web/dns-privacy/current/msg00981.html= and https://www.ietf.org/mail-archive/web/dns-privacy/current/msg00922.html= ).

 

-Tiru

 

 

--_000_DM5PR16MB17882DF8FA85DBC399CC882AEA5A0DM5PR16MB1788namp_-- From nobody Fri Oct 27 04:57:11 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCC513F547 for ; Fri, 27 Oct 2017 04:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai1epf9UyPMX for ; Fri, 27 Oct 2017 04:57:05 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 6B95013F546 for ; Fri, 27 Oct 2017 04:57:04 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e83G2-0002iM-Lj; Fri, 27 Oct 2017 12:57:02 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <017001d34e9a$000d7b50$002871f0$@jpshallow.com> In-Reply-To: Date: Fri, 27 Oct 2017 12:57:02 +0100 Message-ID: <025801d34f1a$b3c62e50$1b528af0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0259_01D34F23.158C1CF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH90TIJaa97fyn3L1JI2IzhS7RCgwIy5zD8opDLv4A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Full Pipe Scenario X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 11:57:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0259_01D34F23.158C1CF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, I propose then that we add to the end of the first paragraph of [5.6 Heartbeat Mechanism] something similar to Orig: "To provide a metric of signal health and distinguish an 'idle' signal channel from a 'disconnected' or 'defunct' session, the DOTS agent sends a heartbeat over the signal channel to maintain its half of the channel. The DOTS agent similarly expects a heartbeat from its peer DOTS agent, and may consider a session terminated in the extended absence of a peer agent heartbeat." New: "With the attack scenario of the pipe going from the DOTS server to the DOTS client running full, the DOTS server will be seeing the heartbeat requests from the DOTS client, but no responses from the DOTS server initiated heartbeats. The DOTS server SHOULT NOT consider the session terminated after "missing-hb-allowed" has been exceeded, but SHOULD continue with the session and SHOULD continue sending heartbeats on the assumption that it is a pipe full scenario and there potentially could be new mitigation requests from the DOTS client. Any "trigger-mitigation" set to "false" MUST still be triggered when "missing-hb-allowed" has been exceeded. Similarly, the DOTS client will be seeing nothing coming from the DOTS server. After "missing-hb-allowed" has been exceeded, the DOTS client SHOULD try (D)TLS session resumption or use 0-RTT mode in (D)TLS 1.3 to piggyback a new mitigation request in the ClientHello, but MUST continue to send heartbeats using the "missing-hb-allowed" failing session so that the DOTS server knows there still is communication. If the DOTS client has a new mitigation request, the DOTS client SHOULD "blindly" send the new mitigation request over the "failing" session in addition to the session resumption. Only when traffic starts to arrive again from the DOTS server should the "failing" session be dropped and a new session established. Orig: " While the communication between the DOTS agents is quiescent, the DOTS client will probe the DOTS server to ensure it has maintained cryptographic state and vice versa. Such probes can also keep alive firewall and/or NAT bindings. This probing reduces the frequency of establishing a new handshake when a DOTS signal needs to be conveyed to the DOTS server." From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 27 October 2017 07:07 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Full Pipe Scenario Heartbeat mechanism is triggered only when the communication b/w the DOTS agents is idle (see https://tools.ietf.org/html/draft-ietf-dots-signal-channel-05#section-5.6). In this case, the DOTS client does not receive any mitigation response from the DOTS server, and the DOTS client knows the inbound pipe is saturated, but the DOTS client does not know if the DOTS session is disconnected. To handle both the problems, and maximize reachability, the DOTS client can continue to use the same DOTS session even if no response is received for the heartbeat but at the same time try (D)TLS session resumption or use 0-RTT mode in (D)TLS 1.3 to piggyback the mitigation request in the ClientHello. When the inbound pipe is no longer saturated, but the DOTS client does not receive any heartbeat responses from the DOTS server then it should consider the session is defunct after missing-hb-allowed number of times. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, October 27, 2017 2:06 AM To: dots@ietf.org Subject: [Dots] Full Pipe Scenario Hi, DOTS Client (C) --------- Pipe -------- DOTS Server (S) We have been testing DOTS server and DOTS client signal channel interaction with a full inbound pipe scenario where all traffic from DOTS server to DOTS client is dropped, but traffic from DOTS client is getting through to the DOTS server. The outbound pipe may be lossy, but testing was done with very little loss outbound. If the outbound pipe is running full, then the DOTS Client environment has to control this traffic as the DOTS Server is very unlikely to be able to do anything here - so this scenario ignored! With this full inbound pipe (direction S to C), we are seeing the following . DOTS server sees the Heartbeat requests from the DOTS client . DOTS server sees any mitigation requests from the DOTS client . DOTS server thinks the signal channel is dead as there are no responses to the DOTS server's Heartbeats . DOTS client thinks the signal channel is dead as there are no responses to the DOTS client's Heartbeats . DOTS client is unable to establish a new signal channel with the server (this may be down to the fact that we internally have not (yet) got session resumption working over DTLS) and so cannot send mitigation requests over this channel If the DOTS server is seeing and noting the DOTS client Heartbeat requests, it can determine the session is still alive and keep it going, even if its own Heartbeats are failing (perhaps just mark the session as 'Heartbeat Failing' after the missing heartbeat counter has expired). Should we be doing this noting of DOTS Client heartbeats? [TR] Yes, it s -The DOTS server can safely assume there is a pipe full scenario (or network routing issue) if it continues to see the DOTS client heartbeats. If the DOTS server is still keeping the session going, and receives a DOTS client mitigation request it can be acted on, even though there is a full pipe. Is this a good thing? Should the DOTS client continue to send Heartbeats after the DOTS client has determined the session has 'Heartbeat Failed' - so that that the DOTS server is kept "warm" in case a mitigation request has to blindly be sent. If the DOTS client closes the session after Heartbeat failure, fails to establish a new session, then there is no mechanism to send a mitigation request - the DOTS client may have discovered a new IP or subnet under attack. - I appreciate that we have a trigger-mitigation flag which may help here. - If the new session gets going, then the "Heartbeat Failure" session should be closed down. Keeping the Heartbeats going, even after the determination that Heartbeats are failing has benefits in supporting additional mitigation requests, but potentially conflicts with the DOTS requirements specification of considering a DOTS signal channel as no longer active after receipt of heartbeat responses. I know SIG-003 is the subject of another debate - do we need heartbeats at all. SIG-003 Channel Health Monitoring: Peer DOTS agents MUST regularly send heartbeats to each other after mutual authentication in order to keep the DOTS signal channel active. A signal channel MUST be considered active until a DOTS agent explicitly ends the session, or either DOTS agent fails to receive heartbeats from the other after a mutually agreed upon timeout period has elapsed. Regards Jon ------=_NextPart_000_0259_01D34F23.158C1CF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I propose then that we = add to the end of the first paragraph of [5.6 Heartbeat Mechanism] = something similar to

 

Orig: “To provide = a metric of signal health and distinguish an 'idle' = signal

   channel from a 'disconnected' or = 'defunct' session, the DOTS agent

   sends a = heartbeat over the signal channel to maintain its half of = the

   channel.  The DOTS agent = similarly expects a heartbeat from its peer

   DOTS agent, = and may consider a session terminated in the = extended

   absence of a peer agent = heartbeat.”

 

New: “With the = attack scenario of the pipe going from the DOTS server to the DOTS = client running full, the DOTS server will be seeing the heartbeat = requests from the DOTS client, but no responses from the DOTS server = initiated heartbeats.  The DOTS server SHOULT NOT consider the = session terminated after "missing-hb-allowed" has been = exceeded, but SHOULD continue with the session and SHOULD continue = sending heartbeats on the assumption that it is a pipe full scenario and = there potentially could be new mitigation requests from the DOTS = client.  Any “trigger-mitigation” set to = “false” MUST still be triggered when = "missing-hb-allowed" has been = exceeded.

 

Similarly, the DOTS = client will be seeing nothing coming from the DOTS server.  After = "missing-hb-allowed" has been exceeded, the DOTS client SHOULD = try (D)TLS session resumption or use 0-RTT mode in (D)TLS 1.3 to = piggyback a new mitigation request in the ClientHello, but MUST continue to send heartbeats using the = "missing-hb-allowed" failing session so that the DOTS server = knows there still is communication.  If the DOTS client has a new = mitigation request, the DOTS client SHOULD “blindly” send = the new mitigation request over the “failing” session in = addition to the session resumption.  Only when traffic starts to = arrive again from the DOTS server should the “failing” = session be dropped and a new session = established.

 

Orig: = “   While the communication between the DOTS agents is = quiescent, the

   DOTS client will probe the DOTS = server to ensure it has maintained

   = cryptographic state and vice versa.  Such probes can also keep = alive

   firewall and/or NAT bindings.  = This probing reduces the frequency of

   = establishing a new handshake when a DOTS signal needs to be = conveyed

   to the DOTS = server.“

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 27 October 2017 = 07:07
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Full Pipe Scenario

 

Heartbeat mechanism is = triggered only when the communication b/w the DOTS agents is idle (see = https://tools.ietf.org/html/draft-ietf-dots-signal-channel-05#s= ection-5.6).  

In this case, the DOTS = client does not receive any mitigation response from the DOTS server, = and the DOTS client knows the inbound pipe is saturated, but the DOTS = client does not know if the DOTS session is disconnected. To handle both = the problems, and maximize reachability, the DOTS client can continue to = use the same DOTS session even if no response is received for the = heartbeat but at the same time try (D)TLS session resumption or use = 0-RTT mode in (D)TLS 1.3 to piggyback the mitigation request in the = ClientHello.

When the inbound pipe = is no longer saturated, but the DOTS client does not receive any = heartbeat responses from the DOTS server then it should consider the = session is defunct

after = missing-hb-allowed number of times.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, October 27, 2017 = 2:06 AM
To: dots@ietf.org
Subject: = [Dots] Full Pipe Scenario

 

Hi,

 

DOTS Client (C) –-------- =  Pipe –------- DOTS Server (S)

 

We have been testing DOTS server and DOTS client = signal channel interaction with a full inbound pipe scenario where all = traffic from DOTS server to DOTS client is dropped, but traffic from = DOTS client is getting through to the DOTS server.

 

The outbound = pipe may be lossy, but testing was done with very little loss = outbound.

 

If the outbound pipe is running full, then the DOTS = Client environment has to control this traffic as the DOTS Server is = very unlikely to be able to do anything here – so this scenario = ignored!

 

With this full inbound pipe (direction S to C), we are = seeing the following

 

·       DOTS server = sees the Heartbeat requests from the DOTS client

·       DOTS server = sees any mitigation requests from the DOTS client

·       DOTS server = thinks the signal channel is dead as there are no responses to the DOTS = server’s Heartbeats

·       DOTS client = thinks the signal channel is dead as there are no responses to the DOTS = client’s Heartbeats

·       DOTS client = is unable to establish a new signal channel with the server (this may be = down to the fact that we internally have not (yet) got session = resumption working over DTLS) and so cannot send mitigation requests = over  this channel

 

If the DOTS = server is seeing and noting the DOTS client Heartbeat requests, it can = determine the session is still alive and keep it going, even if its own = Heartbeats are failing (perhaps just mark the session as = ‘Heartbeat Failing’ after the missing heartbeat counter has = expired).  Should we be doing this noting of DOTS Client = heartbeats?

 

[TR] Yes, it s

 

-The DOTS = server can safely assume there is a pipe full scenario (or network = routing issue) if it continues to see the DOTS client = heartbeats.

 

If the DOTS server is still keeping the session going, = and receives a DOTS client mitigation request it can be acted on, even = though there is a full pipe.  Is this a good = thing?

 

Should the DOTS client continue to send Heartbeats = after the DOTS client has determined the session has ‘Heartbeat = Failed’ – so that that the DOTS server is kept = “warm” in case a mitigation request has to blindly be = sent.

 

If the DOTS client closes the session after Heartbeat = failure, fails to establish a new session, then there is no mechanism to = send a mitigation request – the DOTS client may have discovered a = new IP or subnet under attack.

- I = appreciate that we have a trigger-mitigation flag which may help = here.

- If the new session gets = going, then the “Heartbeat Failure” session should be closed = down.

 

Keeping the Heartbeats going, even after the = determination that Heartbeats are failing has benefits in supporting = additional mitigation requests, but potentially conflicts with the DOTS = requirements specification of considering a DOTS signal channel as no = longer active after receipt of heartbeat responses.  I know SIG-003 = is the subject of another debate – do we need heartbeats at = all.

 

   SIG-003  Channel Health Monitoring: = Peer DOTS agents MUST regularly

      send heartbeats to each = other after mutual authentication in order

      to keep the DOTS signal = channel active.  A signal channel MUST be

      considered active until = a DOTS agent explicitly ends the session,

      or either DOTS agent = fails to receive heartbeats from the other

      after a mutually agreed = upon timeout period has elapsed.

 

Regards

 

Jon

------=_NextPart_000_0259_01D34F23.158C1CF0-- From nobody Fri Oct 27 07:50:45 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EC113F553 for ; Fri, 27 Oct 2017 07:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNvv-jP6CJHF for ; Fri, 27 Oct 2017 07:50:41 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497A213F516 for ; Fri, 27 Oct 2017 07:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7855; q=dns/txt; s=iport; t=1509115841; x=1510325441; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=nQ4oEqIXCb/BCJ4b5SE5SuKFWLPoLkzGmxD9Vup6Zsw=; b=WKjZUGXtIDyJOwQ98E55IgvDmINTEBYeKg+xKUVSmZFNpx87vpuzeUqj OANenYDPsBG1j7qVPHdjD4Fp4+RvaPpSAQDuYXuwsBYI6mWBVKM24xq8m 5RtUSBV2tVGMBiZIZlJgnZ1UFUzLnDjnapMwp7KbFbVi/fgRlQnrsqLSM g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAACTRvNZ/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9wZG4njhmPEoFUJpB9hUWCEQoYAQqFGAKESz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFHgEBAQMBAStBGwsYLicwBgEMBgIBAYoSDRCrNiaKRQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgy6CB4FQgWkpC4J2hGUBAYYUAQSZAokBlHyCFYlfhzmKLIt?= =?us-ascii?q?kgTkfOIFoVSUVSYJkhHslNgGJIA8YBIIZAQEB?= X-IronPort-AV: E=Sophos; i="5.44,304,1505779200"; d="scan'208,217"; a="23012195" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2017 14:50:40 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9REod8w032363; Fri, 27 Oct 2017 14:50:39 GMT To: "Konda, Tirumaleswar Reddy" , "dots@ietf.org" References: From: Flemming Andreasen Message-ID: <896e0fcb-7360-5f15-8208-89353c07bdbb@cisco.com> Date: Fri, 27 Oct 2017 10:50:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E152522A0FD2C7131F5981BC" Content-Language: en-US Archived-At: Subject: Re: [Dots] Default port for DOTS signal channel X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 14:50:43 -0000 This is a multi-part message in MIME format. --------------E152522A0FD2C7131F5981BC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sounds good to me. -- Flemming On 10/27/17 4:34 AM, Konda, Tirumaleswar Reddy wrote: > > Hi all, > > The DOTS signal channel draft is currently using the default port 5684 > (used by (D)TLS secured CoAP), based on the discussions in the interim > WG meeting to handle scenarios where DOTS gateway and IOT gateway > could be co-located and for network devices to enforce policies (e.g. > QoS) for DOTS signal channel differently, DOTS signal channel needs a > different port. > > If there are no objections from the WG, I plan to update the draft to > use a new port assigned by the IANA from the port number registry. > > Further, If the WG agrees, and with the WG chairs and Area Directors > help a new port number can be temporarily assigned by the IANA. The > same approach was followed by DPRIVE WG for DNS-over-(D)TLS drafts to > get a new port, after the drafts were adopted by the WG and > implemented (see > https://www.ietf.org/mail-archive/web/dns-privacy/current/msg00981.html > and > https://www.ietf.org/mail-archive/web/dns-privacy/current/msg00922.html). > > -Tiru > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------E152522A0FD2C7131F5981BC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Sounds good to me.

-- Flemming

On 10/27/17 4:34 AM, Konda, Tirumaleswar Reddy wrote:

Hi all,

The DOTS signal channel draft is currently using the default port 5684 (used by (D)TLS secured CoAP), based on the discussions in the interim WG meeting to handle scenarios where DOTS gateway and IOT gateway could be co-located and for network devices to enforce policies (e.g. QoS) for DOTS signal channel differently, DOTS signal channel needs a different port.

If there are no objections from the WG, I plan to update the draft to use a new port assigned by the IANA from the port number registry.

Further, If the WG agrees, and with the WG chairs and Area Directors help a new port number can be temporarily assigned by the IANA. The same approach was followed by DPRIVE WG for DNS-over-(D)TLS drafts to get a new port, after the drafts were adopted by the WG and implemented (see https://www.ietf.org/mail-archive/web/dns-privacy/current/msg00981.html and https://www.ietf.org/mail-archive/web/dns-privacy/current/msg00922.html).

-Tiru



_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--------------E152522A0FD2C7131F5981BC-- From nobody Fri Oct 27 10:58:04 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546AB13F43F for ; Fri, 27 Oct 2017 10:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 16rYqi1G5C9g for ; Fri, 27 Oct 2017 10:58:01 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0134.outbound.protection.outlook.com [104.47.36.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B906713A65C for ; Fri, 27 Oct 2017 10:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gvC97jAUgQg+hkvIFG1ohK2UJUKUOT2FqWiQULUAXnI=; b=kebxn7u4AG8juSmBP3GzXUXr2WgoqDCby3yU70edQ6pF4Bm6AIWtWYPCxegodAiIsTkPjA9b0sWDrl62pB+GqC0vyYucaKLSuDE+MGUo1e+HAz2aaPxeg2YF82lqtQd0rYwoB+zjw7lnrQ3AE2iwbIc2bTrOogylG43FWqjLteM= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Fri, 27 Oct 2017 17:57:58 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0178.007; Fri, 27 Oct 2017 17:57:58 +0000 From: "Mortensen, Andrew" To: Flemming Andreasen CC: "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] Default port for DOTS signal channel Thread-Index: AdNO9p/vkseJmoMGQQ25Q8ucMqlEeAAPF6EAAAaIEIA= Date: Fri, 27 Oct 2017 17:57:58 +0000 Message-ID: References: <896e0fcb-7360-5f15-8208-89353c07bdbb@cisco.com> In-Reply-To: <896e0fcb-7360-5f15-8208-89353c07bdbb@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; x-originating-ip: [216.130.192.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1987; 6:0QufjY30/Dir0OVF10wGnBPMixFdskijv11Lwie6VcpgZTml3P5gjs42ffR/VgOft/V5xFv2+7M+pYOyJXM2NW7xMnRPPtMtDHp8mtB5HUo998GWkBI4wMhS++kyxZFWu1shVRqBhaDlh/pfOYk1fC7S6LJnsLSBwmh+HZZxvtgJ+4Gn6RjLx606+fVOj2p/lJPVJfZsdukHgIvW1M11Zjxetqw9Da6rZfdA9HLzrgrPlpdD2giIjbXXOy5RoLbFG76n5eC+OQ5GgftdvBN/mcqi+OsndSoot+EHBE8ryAHuwpnyL2JuQr1s4eRZkruf2nM5kiigDL5kIeyWambaSpDRvn+TiTiAfLS7Co335z0=; 5:DyZVovj7CZB79uOhhVz0Ex/g1lGFh3RVtnpDVGKtAb8kiJ9EB9F8NrqkQBji4+Jrv5j+8Hw4gbIRfDLyuzR1ObxLIAs80N35N70TW4adDKXg/PZm/xntEJnq+EsrLE3j0fc378dQGeGbxFxouusBfmmcA1tbR0zBCkoogfIBYtE=; 24:xkQvbru0Bue1uPPtODrjLMkgDZC93c/U5BNbmR/fAmDZI1F9QCYCl0Ugvd6gvzzghXunKCtomo3a5qjvg+HTsnaipx9+bAi8FtuZzmN1dMo=; 7:HvftXl6oC8KbhiESk0JKEk+phBtV1lBuId0dXMB4q/lu9VZAaX2nGUYWpj6Na4PXaExRbFSuK+ENjyZ1ek9WUOUjWCzS2NfRyiL0u1OoF/Uus5KI65zT0xRuWDcPFfNIFD3u8NtHk178k6Bs37cnioRSajcNP6A5cgywJzIULGlyWrJDG+g7DGxloRAoAwJAbTtDW3ll9IpCvfOJ2PTtbbK144xOQQsO08ozOtiUbFoRl0dnrJhHWSzsJDCQ6pTc x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 02c26b66-ad6d-4606-1f3a-08d51d644210 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:BN3PR01MB1987; x-ms-traffictypediagnostic: BN3PR01MB1987: x-exchange-antispam-report-test: UriScan:(189930954265078)(95692535739014); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(3231020)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR01MB1987; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR01MB1987; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(189002)(199003)(24454002)(53754006)(36756003)(189998001)(68736007)(606006)(101416001)(54906003)(6436002)(2900100001)(7736002)(97736004)(6916009)(14454004)(2950100002)(478600001)(6486002)(5660300001)(966005)(6506006)(53546010)(106356001)(77096006)(105586002)(229853002)(83716003)(25786009)(4326008)(6246003)(2906002)(66066001)(86362001)(3280700002)(3660700001)(54356999)(50986999)(102836003)(82746002)(76176999)(33656002)(81156014)(3846002)(8676002)(6116002)(81166006)(6306002)(54896002)(316002)(8936002)(6512007)(99286003)(236005)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1987; H:BN3PR01MB1987.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A5960274A2E74FE1AB49EE80801ED3AEarbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 02c26b66-ad6d-4606-1f3a-08d51d644210 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 17:57:58.2581 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1987 Archived-At: Subject: Re: [Dots] Default port for DOTS signal channel X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 17:58:03 -0000 --_000_A5960274A2E74FE1AB49EE80801ED3AEarbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBPY3QgMjcsIDIwMTcsIGF0IDEwOjUwIEFNLCBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRy ZWFzQGNpc2NvLmNvbTxtYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tPj4gd3JvdGU6DQoNClNvdW5k cyBnb29kIHRvIG1lLg0KDQpMaWtld2lzZS4gSeKAmW0gc3RpbGwgaW4gZmF2b3Igb2YgdXNpbmcg NDY0NiwgaWYgd2UgY2FuIGdldCBpdC4NCg0KYW5kcmV3DQoNCg0KDQpPbiAxMC8yNy8xNyA0OjM0 IEFNLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IHdyb3RlOg0KSGkgYWxsLA0KDQpUaGUgRE9U UyBzaWduYWwgY2hhbm5lbCBkcmFmdCBpcyBjdXJyZW50bHkgdXNpbmcgdGhlIGRlZmF1bHQgcG9y dCA1Njg0ICh1c2VkIGJ5IChEKVRMUyBzZWN1cmVkIENvQVApLCBiYXNlZCBvbiB0aGUgZGlzY3Vz c2lvbnMgaW4gdGhlIGludGVyaW0gV0cgbWVldGluZyB0byBoYW5kbGUgc2NlbmFyaW9zIHdoZXJl IERPVFMgZ2F0ZXdheSBhbmQgSU9UIGdhdGV3YXkgY291bGQgYmUgY28tbG9jYXRlZCBhbmQgZm9y IG5ldHdvcmsgZGV2aWNlcyB0byBlbmZvcmNlIHBvbGljaWVzIChlLmcuIFFvUykgZm9yIERPVFMg c2lnbmFsIGNoYW5uZWwgZGlmZmVyZW50bHksIERPVFMgc2lnbmFsIGNoYW5uZWwgbmVlZHMgYSBk aWZmZXJlbnQgcG9ydC4NCg0KSWYgdGhlcmUgYXJlIG5vIG9iamVjdGlvbnMgZnJvbSB0aGUgV0cs IEkgcGxhbiB0byB1cGRhdGUgdGhlIGRyYWZ0IHRvIHVzZSBhIG5ldyBwb3J0IGFzc2lnbmVkIGJ5 IHRoZSBJQU5BIGZyb20gdGhlIHBvcnQgbnVtYmVyIHJlZ2lzdHJ5Lg0KDQpGdXJ0aGVyLCBJZiB0 aGUgV0cgYWdyZWVzLCBhbmQgd2l0aCB0aGUgV0cgY2hhaXJzIGFuZCBBcmVhIERpcmVjdG9ycyBo ZWxwIGEgbmV3IHBvcnQgbnVtYmVyIGNhbiBiZSB0ZW1wb3JhcmlseSBhc3NpZ25lZCBieSB0aGUg SUFOQS4gVGhlIHNhbWUgYXBwcm9hY2ggd2FzIGZvbGxvd2VkIGJ5IERQUklWRSBXRyBmb3IgRE5T LW92ZXItKEQpVExTIGRyYWZ0cyB0byBnZXQgYSBuZXcgcG9ydCwgYWZ0ZXIgdGhlIGRyYWZ0cyB3 ZXJlIGFkb3B0ZWQgYnkgdGhlIFdHIGFuZCBpbXBsZW1lbnRlZCAoc2VlIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG5zLXByaXZhY3kvY3VycmVudC9tc2cwMDk4MS5odG1s IGFuZCBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Rucy1wcml2YWN5L2N1 cnJlbnQvbXNnMDA5MjIuaHRtbCkuDQoNCi1UaXJ1DQoNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRvdHMgbWFpbGluZyBsaXN0DQpEb3Rz QGlldGYub3JnPG1haWx0bzpEb3RzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kb3RzDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkRvdHMgbWFpbGluZyBsaXN0DQpEb3RzQGlldGYub3JnPG1haWx0bzpE b3RzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3Rz DQoNCg== --_000_A5960274A2E74FE1AB49EE80801ED3AEarbornet_ Content-Type: text/html; charset="utf-8" Content-ID: <4F74690EC75CBE429CE1632EB2C50806@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBPY3Qg MjcsIDIwMTcsIGF0IDEwOjUwIEFNLCBGbGVtbWluZyBBbmRyZWFzZW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpmYW5kcmVhc0BjaXNjby5jb20iIGNsYXNzPSIiPmZhbmRyZWFzQGNpc2NvLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+U291bmRzDQogZ29vZCB0byBt ZS48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+TGlrZXdpc2Uu IEnigJltIHN0aWxsIGluIGZhdm9yIG9mIHVzaW5nIDQ2NDYsIGlmIHdlIGNhbiBnZXQgaXQuPC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5hbmRyZXc8L2Rpdj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1 NSwgMjU1KTsiPg0KT24gMTAvMjcvMTcgNDozNCBBTSwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRk eSB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNp dGU9Im1pZDpETTVQUjE2TUIxNzg4MkRGOEZBODVEQkMzOTlDQzg4MkFFQTVBMEBETTVQUjE2TUIx Nzg4Lm5hbXByZDE2LnByb2Qub3V0bG9vay5jb20iIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3Jk U2VjdGlvbjE7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K SGkgYWxsLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClRoZSBET1RTIHNpZ25h bCBjaGFubmVsIGRyYWZ0IGlzIGN1cnJlbnRseSB1c2luZyB0aGUgZGVmYXVsdCBwb3J0IDU2ODQg KHVzZWQgYnkgKEQpVExTIHNlY3VyZWQgQ29BUCksIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucyBp biB0aGUgaW50ZXJpbSBXRyBtZWV0aW5nIHRvIGhhbmRsZSBzY2VuYXJpb3Mgd2hlcmUgRE9UUyBn YXRld2F5IGFuZCBJT1QgZ2F0ZXdheSBjb3VsZCBiZSBjby1sb2NhdGVkIGFuZCBmb3IgbmV0d29y ayBkZXZpY2VzIHRvIGVuZm9yY2UNCiBwb2xpY2llcyAoZS5nLiBRb1MpIGZvciBET1RTIHNpZ25h bCBjaGFubmVsIGRpZmZlcmVudGx5LCBET1RTIHNpZ25hbCBjaGFubmVsIG5lZWRzIGEgZGlmZmVy ZW50IHBvcnQuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSWYgdGhlcmUgYXJl IG5vIG9iamVjdGlvbnMgZnJvbSB0aGUgV0csIEkgcGxhbiB0byB1cGRhdGUgdGhlIGRyYWZ0IHRv IHVzZSBhIG5ldyBwb3J0IGFzc2lnbmVkIGJ5IHRoZSBJQU5BIGZyb20gdGhlIHBvcnQgbnVtYmVy IHJlZ2lzdHJ5LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkZ1cnRoZXIsIElm IHRoZSBXRyBhZ3JlZXMsIGFuZCB3aXRoIHRoZSBXRyBjaGFpcnMgYW5kIEFyZWEgRGlyZWN0b3Jz IGhlbHAgYSBuZXcgcG9ydCBudW1iZXIgY2FuIGJlIHRlbXBvcmFyaWx5IGFzc2lnbmVkIGJ5IHRo ZSBJQU5BLiBUaGUgc2FtZSBhcHByb2FjaCB3YXMgZm9sbG93ZWQgYnkgRFBSSVZFIFdHIGZvciBE TlMtb3Zlci0oRClUTFMgZHJhZnRzIHRvIGdldCBhIG5ldyBwb3J0LCBhZnRlciB0aGUgZHJhZnRz IHdlcmUgYWRvcHRlZCBieSB0aGUNCiBXRyBhbmQgaW1wbGVtZW50ZWQgKHNlZTxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Rucy1wcml2YWN5L2N1cnJlbnQvbXNnMDA5ODEu aHRtbCIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBzdHlsZT0iY29sb3I6IHJnYigxNDksIDc5LCAx MTQpOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG5zLXByaXZhY3kvY3VycmVudC9tc2cwMDk4MS5odG1s PC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hbmQ8 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kbnMtcHJpdmFjeS9jdXJyZW50 L21zZzAwOTIyLmh0bWwiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgc3R5bGU9ImNvbG9yOiByZ2Io MTQ5LCA3OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Rucy1wcml2YWN5L2N1cnJlbnQvbXNn MDA5MjIuaHRtbDwvYT4pLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCi1UaXJ1 PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGZpZWxkc2V0IGNsYXNzPSJtaW1l QXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNldD48YnIgY2xhc3M9IiI+DQo8cHJlIHdyYXA9IiIg Y2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkRvdHMgbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBo cmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiByZ2IoMTQ5LCA3OSwgMTE0 KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5Eb3RzQGlldGYub3JnPC9hPg0KPGEgY2xh c3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kb3RzIiBzdHlsZT0iY29sb3I6IHJnYigxNDksIDc5LCAxMTQpOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG90czwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyBm bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Eb3RzDQog bWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+ DQo8YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiByZ2IoMTQ5LCA3 OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 IiBjbGFzcz0iIj5Eb3RzQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIg Y2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHMiIHN0eWxlPSJjb2xvcjogcmdiKDE0OSwgNzksIDExNCk7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dy b3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A5960274A2E74FE1AB49EE80801ED3AEarbornet_-- From nobody Mon Oct 30 00:28:16 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73EE13FFDF for ; Mon, 30 Oct 2017 00:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 ujpVXAF490q7 for ; Mon, 30 Oct 2017 00:28:09 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 A72FD13FEED for ; Mon, 30 Oct 2017 00:25:46 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509348345; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=N oXkmCkqontf6dVs/wHbdpdr+IQI9HHqEykMcFqiOE s=; b=SzvZZs3JuOoAN5zq3no6wP9i389K3ViEPj4/dJzc9OWm r4ubIVuXil1aizyzL1Rex4UkYiSIUcDx9GleP14UPM1jIcjw4e XvwacH0jRmDmUJYQ9L41VR2QNZDqYRjF9FEEQfp5SNzVWqXumn yuSCae7QSU1HN7ox0bYXXu7yo88= Received: from MIVEXAPP1N03.corpzone.internalzone.com (mivexapp1n03.corpzone.internalzone.com [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 5e78_2a62_4b83d2a8_be72_41bf_a05e_a2abfdaf88e5; Mon, 30 Oct 2017 02:25:44 -0500 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 03:25:38 -0400 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 03:25:37 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 30 Oct 2017 03:25:36 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 03:25:36 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 07:25:35 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 07:25:35 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Full Pipe Scenario Thread-Index: AdNOmftpS0b6T9g6S+iNSHMqb5xZmAAPOwUAABDy9AAAAZhggA== Date: Mon, 30 Oct 2017 07:25:34 +0000 Message-ID: References: <017001d34e9a$000d7b50$002871f0$@jpshallow.com> <025801d34f1a$b3c62e50$1b528af0$@jpshallow.com> In-Reply-To: <025801d34f1a$b3c62e50$1b528af0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:Nz9RRLctmBAb68s9bRHLvUaH4RdSA77HcjI9/AoXzeTgZbVgvrs4zY2xOJ+Q5wLE+FRXC06bL9fEZIRnJFFhXkgbgqwKTQ7ZBhYk50Wk65F0+bJuITDI9GtGcGkv94vzYFggfnleiKkh87vA5onj7JDVEkRFXlIKKSg3NvQrkYSIhgyU/I1uCey93d04vn8O1PJOTV+rsVJn6oiS3BMDlFkdkdVSZzoFhJ7t2iciUlqe+Ajfv75faj28nDwvN1GAQ4e7JjToGsHHOyEmGLO7Pop/I7EBSUXx5VrQpxmNPCJC9RB9g50HJzga2s1nKYcKJTbqxYJFwgtJC+5IkFBMvkFf4jN63ByZiyrgZ3Qv5Bo=; 5:/LcwmczcTdEYSdtnZDe2jL0v5ZHaQ1Y4BeXU2mYvOv1pjv2R2YG4GYr5E8w0wsRjZuOoJTc+AQrcEslaRFmLqkco4Oc75yXbpRhHicq7luyjB6mx+iguqoZy4rBnTfFzlRmCxdO5YLGoRyukunNheT2R1WUs9+amgRVSGYB1q+c=; 24:6g24TrdGooyO4saUGcm16mBLd0szO39khR2Zb2FpK1StT8z8Cvpko1EKTLd9l8HvSLzkCaoFUMmTyV+O0JZXd05dq+pkVRR/UNu4q8e1Cz0=; 7:pesUw54iYsXnvEAA+uGyq+2bezxKcvJvgHh/PGE378SVpb9gOA044BHsTogGlgHbsgJDxTGLdTKcfz6onC0HvsLGACuap3rz7i0RvwcpKXGdzVmBtWYj6R9MuQewjGXhPEUaX1HumWcSyufQ8y73DAgsJU9yIe/e6q7NtfUzwx4ENPnn0lX8zKlUkCF2zhl5lQ/E+5tyATlb7Xp/p+ZYW39mZdixCJY/O6v6+kiNokR0UV4OJrM+vhPXjX4xw975 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6e46f881-44a1-4529-cee3-08d51f67693d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3231020)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(32952001)(57704003)(189002)(199003)(86362001)(25786009)(189998001)(2501003)(68736007)(81166006)(8936002)(81156014)(8676002)(14454004)(6116002)(790700001)(102836003)(3846002)(97736004)(80792005)(101416001)(50986999)(76176999)(54356999)(19609705001)(74316002)(6506006)(55016002)(99286003)(2950100002)(478600001)(606006)(2900100001)(2906002)(966005)(316002)(3280700002)(7736002)(72206003)(3660700001)(77096006)(106356001)(110136005)(105586002)(66066001)(229853002)(7696004)(6246003)(236005)(5660300001)(53546010)(6436002)(9686003)(53936002)(33656002)(54896002)(6306002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17887D7FCB251EE4BC08B037EA590DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6e46f881-44a1-4529-cee3-08d51f67693d X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 07:25:34.9762 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6146> : inlines <6150> : streams <1768829> : uri <2524714> Archived-At: Subject: Re: [Dots] Full Pipe Scenario X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 07:28:13 -0000 --_000_DM5PR16MB17887D7FCB251EE4BC08B037EA590DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Jon, I have modified the proposed text as follows: In case of a volumetric DDoS attack saturating the incoming link to the DOT= S client, all traffic from the DOTS server to the DOTS client will likely b= e dropped, although the DOTS server receives heartbeat requests and DOTS me= ssages from the DOTS client. In this scenario, the DOTS agents MUST behave differently to handle message= transmission and DOTS session liveliness during link saturation : * The DOTS client MUST NOT consider the DOTS session terminated even after = maximum "missing-hb-allowed" threshold is reached. DOTS client SHOULD conti= nue to use the current DOTS session, and send heartbeat requests over the c= urrent DOTS session, so the DOTS server knows the DOTS client has not disco= nnected the DOTS session. After the maximum "missing-hb-allowed" threshold = is reached, the DOTS client SHOULD try (D)TLS session resumption. The DOTS = client SHOULD send mitigation requests over the current DOTS session, and i= n parallel, try (D)TLS session resumption or 0-RTT mode in DTLS 1.3 to pigg= yback the mitigation request in the ClientHello message. Once the link is = no longer statured, if traffic from the DOTS server reaches the DOTS client= over the current DOTS session, the DOTS client can stop (D)TLS session res= umption or if (D)TLS session resumption is successful then disconnect the c= urrent DOTS session. * If the DOTS server does not receive any traffic from the DOTS client, the= n the DOTS server sends heartbeat requests to the DOTS client and if "trigg= er-mitigation" is set to "false", then trigger DDoS mitigation after maximu= m "missing-hb-allowed" threshold is reached. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, October 27, 2017 5:27 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Full Pipe Scenario Hi Tiru, I propose then that we add to the end of the first paragraph of [5.6 Heartb= eat Mechanism] something similar to Orig: "To provide a metric of signal health and distinguish an 'idle' signa= l channel from a 'disconnected' or 'defunct' session, the DOTS agent sends a heartbeat over the signal channel to maintain its half of the channel. The DOTS agent similarly expects a heartbeat from its peer DOTS agent, and may consider a session terminated in the extended absence of a peer agent heartbeat." New: "With the attack scenario of the pipe going from the DOTS server to th= e DOTS client running full, the DOTS server will be seeing the heartbeat re= quests from the DOTS client, but no responses from the DOTS server initiate= d heartbeats. The DOTS server SHOULT NOT consider the session terminated a= fter "missing-hb-allowed" has been exceeded, but SHOULD continue with the s= ession and SHOULD continue sending heartbeats on the assumption that it is = a pipe full scenario and there potentially could be new mitigation requests= from the DOTS client. Any "trigger-mitigation" set to "false" MUST still = be triggered when "missing-hb-allowed" has been exceeded. Similarly, the DOTS client will be seeing nothing coming from the DOTS serv= er. After "missing-hb-allowed" has been exceeded, the DOTS client SHOULD t= ry (D)TLS session resumption or use 0-RTT mode in (D)TLS 1.3 to piggyback a= new mitigation request in the ClientHello, but MUST continue to send heart= beats using the "missing-hb-allowed" failing session so that the DOTS serve= r knows there still is communication. If the DOTS client has a new mitigat= ion request, the DOTS client SHOULD "blindly" send the new mitigation reque= st over the "failing" session in addition to the session resumption. Only = when traffic starts to arrive again from the DOTS server should the "failin= g" session be dropped and a new session established. Orig: " While the communication between the DOTS agents is quiescent, the DOTS client will probe the DOTS server to ensure it has maintained cryptographic state and vice versa. Such probes can also keep alive firewall and/or NAT bindings. This probing reduces the frequency of establishing a new handshake when a DOTS signal needs to be conveyed to the DOTS server." From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 October 2017 07:07 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Full Pipe Scenario Heartbeat mechanism is triggered only when the communication b/w the DOTS a= gents is idle (see https://tools.ietf.org/html/draft-ietf-dots-signal-chann= el-05#section-5.6). In this case, the DOTS client does not receive any mitigation response from= the DOTS server, and the DOTS client knows the inbound pipe is saturated, = but the DOTS client does not know if the DOTS session is disconnected. To h= andle both the problems, and maximize reachability, the DOTS client can con= tinue to use the same DOTS session even if no response is received for the = heartbeat but at the same time try (D)TLS session resumption or use 0-RTT m= ode in (D)TLS 1.3 to piggyback the mitigation request in the ClientHello. When the inbound pipe is no longer saturated, but the DOTS client does not = receive any heartbeat responses from the DOTS server then it should conside= r the session is defunct after missing-hb-allowed number of times. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, October 27, 2017 2:06 AM To: dots@ietf.org Subject: [Dots] Full Pipe Scenario Hi, DOTS Client (C) --------- Pipe -------- DOTS Server (S) We have been testing DOTS server and DOTS client signal channel interaction= with a full inbound pipe scenario where all traffic from DOTS server to DO= TS client is dropped, but traffic from DOTS client is getting through to th= e DOTS server. The outbound pipe may be lossy, but testing was done with very little loss = outbound. If the outbound pipe is running full, then the DOTS Client environment has = to control this traffic as the DOTS Server is very unlikely to be able to d= o anything here - so this scenario ignored! With this full inbound pipe (direction S to C), we are seeing the following * DOTS server sees the Heartbeat requests from the DOTS client * DOTS server sees any mitigation requests from the DOTS client * DOTS server thinks the signal channel is dead as there are no respo= nses to the DOTS server's Heartbeats * DOTS client thinks the signal channel is dead as there are no respo= nses to the DOTS client's Heartbeats * DOTS client is unable to establish a new signal channel with the se= rver (this may be down to the fact that we internally have not (yet) got se= ssion resumption working over DTLS) and so cannot send mitigation requests = over this channel If the DOTS server is seeing and noting the DOTS client Heartbeat requests,= it can determine the session is still alive and keep it going, even if its= own Heartbeats are failing (perhaps just mark the session as 'Heartbeat Fa= iling' after the missing heartbeat counter has expired). Should we be doin= g this noting of DOTS Client heartbeats? [TR] Yes, it s -The DOTS server can safely assume there is a pipe full scenario (or networ= k routing issue) if it continues to see the DOTS client heartbeats. If the DOTS server is still keeping the session going, and receives a DOTS = client mitigation request it can be acted on, even though there is a full p= ipe. Is this a good thing? Should the DOTS client continue to send Heartbeats after the DOTS client ha= s determined the session has 'Heartbeat Failed' - so that that the DOTS ser= ver is kept "warm" in case a mitigation request has to blindly be sent. If the DOTS client closes the session after Heartbeat failure, fails to est= ablish a new session, then there is no mechanism to send a mitigation reque= st - the DOTS client may have discovered a new IP or subnet under attack. - I appreciate that we have a trigger-mitigation flag which may help here. - If the new session gets going, then the "Heartbeat Failure" session shoul= d be closed down. Keeping the Heartbeats going, even after the determination that Heartbeats = are failing has benefits in supporting additional mitigation requests, but = potentially conflicts with the DOTS requirements specification of consideri= ng a DOTS signal channel as no longer active after receipt of heartbeat res= ponses. I know SIG-003 is the subject of another debate - do we need heart= beats at all. SIG-003 Channel Health Monitoring: Peer DOTS agents MUST regularly send heartbeats to each other after mutual authentication in order to keep the DOTS signal channel active. A signal channel MUST be considered active until a DOTS agent explicitly ends the session, or either DOTS agent fails to receive heartbeats from the other after a mutually agreed upon timeout period has elapsed. Regards Jon --_000_DM5PR16MB17887D7FCB251EE4BC08B037EA590DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Jon, I have modified the proposed text as follows:

           &= nbsp;           &nbs= p;            &= nbsp;      

In case of a volumetric DDoS attack saturating the incoming link to= the DOTS client, all traffic from the DOTS server to the DOTS client will = likely be dropped, although the DOTS server receives heartbeat requests and DOTS messages from the DOTS client.=

In this scenario, the DOTS agents MUST behave differently to handle= message transmission and DOTS session liveliness during link saturation :<= o:p>

 

* The DOTS client MUST NOT consider the DOTS session terminated eve= n after maximum "missing-hb-allowed" threshold is reached. DOTS c= lient SHOULD continue to use the current DOTS session, and send heartbeat requests over the current DOTS session, so the= DOTS server knows the DOTS client has not disconnected the DOTS session. A= fter the maximum "missing-hb-allowed" threshold is reached, the D= OTS client SHOULD try (D)TLS session resumption. The DOTS client SHOULD send mitigation requests over the current DOTS sess= ion, and in parallel, try (D)TLS session resumption or 0-RTT mode in DTLS 1= .3 to piggyback the mitigation request in the ClientHello message.  On= ce the link is no longer statured, if traffic from the DOTS server reaches the DOTS client over the current DOTS= session, the DOTS client can stop (D)TLS session resumption or if (D)TLS s= ession resumption is successful then disconnect the current DOTS session.

 

* If the DOTS server does not receive any traffic from the DOTS cli= ent, then the DOTS server sends heartbeat requests to the DOTS client and i= f “trigger-mitigation” is set to “false”, then trigger DDoS mitigation after maximum "missing-hb-allowed" = threshold is reached.

&nbs= p;

-Tiru

 

From:<= /span> Jon Shallow [<= a href=3D"mailto:supjps-ietf@jpshallow.com">mailto:supjps-ietf@jpshallow.com]
Sent: Friday, October 27, 2017 5:27 PM
To: Konda, Tirumaleswar Reddy <Tirum= aleswarReddy_Konda@McAfee.com>; dots@ietf.org=
Subject: RE: [Dots] Full Pipe Scenario

 

Hi Tiru= ,

&n= bsp;

I propo= se then that we add to the end of the first paragraph of [5.6 Heartbeat Mec= hanism] something similar to

&n= bsp;

Orig: &= #8220;To provide a metric of signal health and distinguish an 'idle' signal=

 &= nbsp; channel from a 'disconnected' or 'defunct' session, the DOTS agent

 &= nbsp; sends a heartbeat over the signal channel to maintain its half of the=

 &= nbsp; channel.  The DOTS agent similarly expects a heartbeat from its = peer

 &= nbsp; DOTS agent, and may consider a session terminated in the extended

 &= nbsp; absence of a peer agent heartbeat.”

&n= bsp;

New: &#= 8220;With the attack scenario of the pipe going from the DOTS server to the= DOTS client running full, the DOTS server will be seeing the heartbeat req= uests from the DOTS client, but no responses from the DOTS server initiated heartbeats.  The DOTS server SHOULT NO= T consider the session terminated after "missing-hb-allowed" has = been exceeded, but SHOULD continue with the session and SHOULD continue sen= ding heartbeats on the assumption that it is a pipe full scenario and there potentially could be new mitigation requests = from the DOTS client.  Any “trigger-mitigation” set to = 220;false” MUST still be triggered when "missing-hb-allowed"= ; has been exceeded.

&n= bsp;

Similar= ly, the DOTS client will be seeing nothing coming from the DOTS server.&nbs= p; After "missing-hb-allowed" has been exceeded, the DOTS client = SHOULD try (D)TLS session resumption or use 0-RTT mode in (D)T= LS 1.3 to piggyback a new mitigation request in the ClientHello, but MUST continue to send heartbe= ats using the "missing-hb-allowed" failing session so that the DOTS server knows there still is communication.  = If the DOTS client has a new mitigation request, the DOTS client SHOULD = 220;blindly” send the new mitigation request over the “failing&= #8221; session in addition to the session resumption.  Only when traffic starts to arrive again from the DOTS server should the “fail= ing” session be dropped and a new session established.

&n= bsp;

Orig: &= #8220;   While the communication between the DOTS agents is quies= cent, the

 &= nbsp; DOTS client will probe the DOTS server to ensure it has maintained

 &= nbsp; cryptographic state and vice versa.  Such probes can also keep a= live

 &= nbsp; firewall and/or NAT bindings.  This probing reduces the frequenc= y of

 &= nbsp; establishing a new handshake when a DOTS signal needs to be conveyed<= o:p>

 &= nbsp; to the DOTS server.“

&n= bsp;

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 October 2017 07:07
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Full Pipe Scenario

 

Heartbeat= mechanism is triggered only when the communication b/w the DOTS agents is = idle (see https://tools.= ietf.org/html/draft-ietf-dots-signal-channel-05#section-5.6).  

In this c= ase, the DOTS client does not receive any mitigation response from the DOTS= server, and the DOTS client knows the inbound pipe is saturated, but the D= OTS client does not know if the DOTS session is disconnected. To handle both the problems, and maximize reachab= ility, the DOTS client can continue to use the same DOTS session even if no= response is received for the heartbeat but at the same time try (D)TLS ses= sion resumption or use 0-RTT mode in (D)TLS 1.3 to piggyback the mitigation request in the ClientHello.

When the = inbound pipe is no longer saturated, but the DOTS client does not receive a= ny heartbeat responses from the DOTS server then it should consider the ses= sion is defunct

after mis= sing-hb-allowed number of times.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, October 27, 2017 2:06 AM
To: dots@ietf.org
Subject: [Dots] Full Pipe Scenario

 

Hi,

 

DOTS Client (C) –-------- &n= bsp;Pipe –------- DOTS Server (S)

 

We have been testing DOTS serve= r and DOTS client signal channel interaction with a full inbound pipe scena= rio where all traffic from DOTS server to DOTS client is dropped, but traff= ic from DOTS client is getting through to the DOTS server.

 

The outbound pipe may be lossy,= but testing was done with very little loss outbound.

 

If the outbound pipe is running= full, then the DOTS Client environment has to control this traffic as the = DOTS Server is very unlikely to be able to do anything here – so this= scenario ignored!

 

With this full inbound pipe (di= rection S to C), we are seeing the following

 

· &n= bsp;     DOTS server sees the Heartbeat requests from th= e DOTS client

· &n= bsp;     DOTS server sees any mitigation requests from t= he DOTS client

· &n= bsp;     DOTS server thinks the signal channel is dead a= s there are no responses to the DOTS server’s Heartbeats

· &n= bsp;     DOTS client thinks the signal channel is dead a= s there are no responses to the DOTS client’s Heartbeats

· &n= bsp;     DOTS client is unable to establish a new signal= channel with the server (this may be down to the fact that we internally h= ave not (yet) got session resumption working over DTLS) and so cannot send = mitigation requests over  this channel

 

If the DOTS server is seeing an= d noting the DOTS client Heartbeat requests, it can determine the session i= s still alive and keep it going, even if its own Heartbeats are failing (pe= rhaps just mark the session as ‘Heartbeat Failing’ after the missing heartbeat counter has expired).  Sho= uld we be doing this noting of DOTS Client heartbeats?

 

[TR] Yes, it s

 

-The DOTS server can safely ass= ume there is a pipe full scenario (or network routing issue) if it continue= s to see the DOTS client heartbeats.

 

If the DOTS server is still kee= ping the session going, and receives a DOTS client mitigation request it ca= n be acted on, even though there is a full pipe.  Is this a good thing= ?

 

Should the DOTS client continue= to send Heartbeats after the DOTS client has determined the session has &#= 8216;Heartbeat Failed’ – so that that the DOTS server is kept &= #8220;warm” in case a mitigation request has to blindly be sent.=

 

If the DOTS client closes the s= ession after Heartbeat failure, fails to establish a new session, then ther= e is no mechanism to send a mitigation request – the DOTS client may = have discovered a new IP or subnet under attack.

- I appreciate that we have a t= rigger-mitigation flag which may help here.

- If the new session gets going= , then the “Heartbeat Failure” session should be closed down.

 

Keeping the Heartbeats going, e= ven after the determination that Heartbeats are failing has benefits in sup= porting additional mitigation requests, but potentially conflicts with the = DOTS requirements specification of considering a DOTS signal channel as no longer active after receipt of heartbeat respo= nses.  I know SIG-003 is the subject of another debate – do we n= eed heartbeats at all.

 

   SIG-003  Chan= nel Health Monitoring: Peer DOTS agents MUST regularly

      = send heartbeats to each other after mutual authentication in order

      = to keep the DOTS signal channel active.  A signal channel MUST be=

      = considered active until a DOTS agent explicitly ends the session,

      = or either DOTS agent fails to receive heartbeats from the other<= /span>

      = after a mutually agreed upon timeout period has elapsed.<= /p>

 

Regards

 

Jon

--_000_DM5PR16MB17887D7FCB251EE4BC08B037EA590DM5PR16MB1788namp_-- From nobody Mon Oct 30 00:42:34 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0027313FF2C for ; Mon, 30 Oct 2017 00:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7Qgc3GBR-Ou for ; Mon, 30 Oct 2017 00:42:23 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 E963313F6CB for ; Mon, 30 Oct 2017 00:42:22 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e94iC-0004eb-FN; Mon, 30 Oct 2017 07:42:20 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <017001d34e9a$000d7b50$002871f0$@jpshallow.com> <025801d34f1a$b3c62e50$1b528af0$@jpshallow.com> In-Reply-To: Date: Mon, 30 Oct 2017 07:42:20 -0000 Message-ID: <03a501d35152$9e53da60$dafb8f20$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A6_01D35152.9E55FD40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH90TIJaa97fyn3L1JI2IzhS7RCgwIy5zD8AU2qFv0BXjgw4qKADGAg Content-Language: en-gb Archived-At: Subject: Re: [Dots] Full Pipe Scenario X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 07:42:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03A6_01D35152.9E55FD40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, This looks good to me. Thanks. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 30 October 2017 07:26 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Full Pipe Scenario Thanks Jon, I have modified the proposed text as follows: In case of a volumetric DDoS attack saturating the incoming link to the DOTS client, all traffic from the DOTS server to the DOTS client will likely be dropped, although the DOTS server receives heartbeat requests and DOTS messages from the DOTS client. In this scenario, the DOTS agents MUST behave differently to handle message transmission and DOTS session liveliness during link saturation : * The DOTS client MUST NOT consider the DOTS session terminated even after maximum "missing-hb-allowed" threshold is reached. DOTS client SHOULD continue to use the current DOTS session, and send heartbeat requests over the current DOTS session, so the DOTS server knows the DOTS client has not disconnected the DOTS session. After the maximum "missing-hb-allowed" threshold is reached, the DOTS client SHOULD try (D)TLS session resumption. The DOTS client SHOULD send mitigation requests over the current DOTS session, and in parallel, try (D)TLS session resumption or 0-RTT mode in DTLS 1.3 to piggyback the mitigation request in the ClientHello message. Once the link is no longer statured, if traffic from the DOTS server reaches the DOTS client over the current DOTS session, the DOTS client can stop (D)TLS session resumption or if (D)TLS session resumption is successful then disconnect the current DOTS session. * If the DOTS server does not receive any traffic from the DOTS client, then the DOTS server sends heartbeat requests to the DOTS client and if "trigger-mitigation" is set to "false", then trigger DDoS mitigation after maximum "missing-hb-allowed" threshold is reached. -Tiru From: Jon Shallow [ mailto:supjps-ietf@jpshallow.com] Sent: Friday, October 27, 2017 5:27 PM To: Konda, Tirumaleswar Reddy < TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org Subject: RE: [Dots] Full Pipe Scenario Hi Tiru, I propose then that we add to the end of the first paragraph of [5.6 Heartbeat Mechanism] something similar to Orig: "To provide a metric of signal health and distinguish an 'idle' signal channel from a 'disconnected' or 'defunct' session, the DOTS agent sends a heartbeat over the signal channel to maintain its half of the channel. The DOTS agent similarly expects a heartbeat from its peer DOTS agent, and may consider a session terminated in the extended absence of a peer agent heartbeat." New: "With the attack scenario of the pipe going from the DOTS server to the DOTS client running full, the DOTS server will be seeing the heartbeat requests from the DOTS client, but no responses from the DOTS server initiated heartbeats. The DOTS server SHOULT NOT consider the session terminated after "missing-hb-allowed" has been exceeded, but SHOULD continue with the session and SHOULD continue sending heartbeats on the assumption that it is a pipe full scenario and there potentially could be new mitigation requests from the DOTS client. Any "trigger-mitigation" set to "false" MUST still be triggered when "missing-hb-allowed" has been exceeded. Similarly, the DOTS client will be seeing nothing coming from the DOTS server. After "missing-hb-allowed" has been exceeded, the DOTS client SHOULD try (D)TLS session resumption or use 0-RTT mode in (D)TLS 1.3 to piggyback a new mitigation request in the ClientHello, but MUST continue to send heartbeats using the "missing-hb-allowed" failing session so that the DOTS server knows there still is communication. If the DOTS client has a new mitigation request, the DOTS client SHOULD "blindly" send the new mitigation request over the "failing" session in addition to the session resumption. Only when traffic starts to arrive again from the DOTS server should the "failing" session be dropped and a new session established. Orig: " While the communication between the DOTS agents is quiescent, the DOTS client will probe the DOTS server to ensure it has maintained cryptographic state and vice versa. Such probes can also keep alive firewall and/or NAT bindings. This probing reduces the frequency of establishing a new handshake when a DOTS signal needs to be conveyed to the DOTS server." From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 27 October 2017 07:07 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Full Pipe Scenario Heartbeat mechanism is triggered only when the communication b/w the DOTS agents is idle (see https://tools.ietf.org/html/draft-ietf-dots-signal-channel-05#section-5.6). In this case, the DOTS client does not receive any mitigation response from the DOTS server, and the DOTS client knows the inbound pipe is saturated, but the DOTS client does not know if the DOTS session is disconnected. To handle both the problems, and maximize reachability, the DOTS client can continue to use the same DOTS session even if no response is received for the heartbeat but at the same time try (D)TLS session resumption or use 0-RTT mode in (D)TLS 1.3 to piggyback the mitigation request in the ClientHello. When the inbound pipe is no longer saturated, but the DOTS client does not receive any heartbeat responses from the DOTS server then it should consider the session is defunct after missing-hb-allowed number of times. -Tiru From: Dots [ mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, October 27, 2017 2:06 AM To: dots@ietf.org Subject: [Dots] Full Pipe Scenario Hi, DOTS Client (C) --------- Pipe -------- DOTS Server (S) We have been testing DOTS server and DOTS client signal channel interaction with a full inbound pipe scenario where all traffic from DOTS server to DOTS client is dropped, but traffic from DOTS client is getting through to the DOTS server. The outbound pipe may be lossy, but testing was done with very little loss outbound. If the outbound pipe is running full, then the DOTS Client environment has to control this traffic as the DOTS Server is very unlikely to be able to do anything here - so this scenario ignored! With this full inbound pipe (direction S to C), we are seeing the following . DOTS server sees the Heartbeat requests from the DOTS client . DOTS server sees any mitigation requests from the DOTS client . DOTS server thinks the signal channel is dead as there are no responses to the DOTS server's Heartbeats . DOTS client thinks the signal channel is dead as there are no responses to the DOTS client's Heartbeats . DOTS client is unable to establish a new signal channel with the server (this may be down to the fact that we internally have not (yet) got session resumption working over DTLS) and so cannot send mitigation requests over this channel If the DOTS server is seeing and noting the DOTS client Heartbeat requests, it can determine the session is still alive and keep it going, even if its own Heartbeats are failing (perhaps just mark the session as 'Heartbeat Failing' after the missing heartbeat counter has expired). Should we be doing this noting of DOTS Client heartbeats? [TR] Yes, it s -The DOTS server can safely assume there is a pipe full scenario (or network routing issue) if it continues to see the DOTS client heartbeats. If the DOTS server is still keeping the session going, and receives a DOTS client mitigation request it can be acted on, even though there is a full pipe. Is this a good thing? Should the DOTS client continue to send Heartbeats after the DOTS client has determined the session has 'Heartbeat Failed' - so that that the DOTS server is kept "warm" in case a mitigation request has to blindly be sent. If the DOTS client closes the session after Heartbeat failure, fails to establish a new session, then there is no mechanism to send a mitigation request - the DOTS client may have discovered a new IP or subnet under attack. - I appreciate that we have a trigger-mitigation flag which may help here. - If the new session gets going, then the "Heartbeat Failure" session should be closed down. Keeping the Heartbeats going, even after the determination that Heartbeats are failing has benefits in supporting additional mitigation requests, but potentially conflicts with the DOTS requirements specification of considering a DOTS signal channel as no longer active after receipt of heartbeat responses. I know SIG-003 is the subject of another debate - do we need heartbeats at all. SIG-003 Channel Health Monitoring: Peer DOTS agents MUST regularly send heartbeats to each other after mutual authentication in order to keep the DOTS signal channel active. A signal channel MUST be considered active until a DOTS agent explicitly ends the session, or either DOTS agent fails to receive heartbeats from the other after a mutually agreed upon timeout period has elapsed. Regards Jon ------=_NextPart_000_03A6_01D35152.9E55FD40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

This looks good to = me.  Thanks.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 30 October 2017 = 07:26
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Full Pipe Scenario

 

Thanks Jon, I have = modified the proposed text as follows:

   &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   

In = case of a volumetric DDoS attack saturating the incoming link to the = DOTS client, all traffic from the DOTS server to the DOTS client will = likely be dropped, although the DOTS server receives heartbeat requests = and DOTS messages from the DOTS client.

In this scenario, = the DOTS agents MUST behave differently to handle message transmission = and DOTS session liveliness during link saturation = :

 

* The DOTS client = MUST NOT consider the DOTS session terminated even after maximum = "missing-hb-allowed" threshold is reached. DOTS client SHOULD = continue to use the current DOTS session, and send heartbeat requests = over the current DOTS session, so the DOTS server knows the DOTS client = has not disconnected the DOTS session. After the maximum = "missing-hb-allowed" threshold is reached, the DOTS client = SHOULD try (D)TLS session resumption. The DOTS client SHOULD send = mitigation requests over the current DOTS session, and in parallel, try = (D)TLS session resumption or 0-RTT mode in DTLS 1.3 to piggyback the = mitigation request in the ClientHello message.  Once the link is no = longer statured, if traffic from the DOTS server reaches the DOTS client = over the current DOTS session, the DOTS client can stop (D)TLS session = resumption or if (D)TLS session resumption is successful then disconnect = the current DOTS session.

 

* If the DOTS = server does not receive any traffic from the DOTS client, then the DOTS = server sends heartbeat requests to the DOTS client and if = “trigger-mitigation” is set to “false”, then = trigger DDoS mitigation after maximum "missing-hb-allowed" = threshold is reached.

 

-Tiru

 

From: Jon Shallow = [mailto:supjps-ietf@jpshallow.com] =
Sent: Friday, October 27, 2017 5:27 PM
To: Konda, = Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: = RE: [Dots] Full Pipe Scenario

 

Hi = Tiru,

 

I propose then that we = add to the end of the first paragraph of [5.6 Heartbeat Mechanism] = something similar to

 

Orig: “To provide = a metric of signal health and distinguish an 'idle' = signal

   channel from a 'disconnected' or = 'defunct' session, the DOTS agent

   sends a = heartbeat over the signal channel to maintain its half of = the

   channel.  The DOTS agent = similarly expects a heartbeat from its peer

   DOTS agent, = and may consider a session terminated in the = extended

   absence of a peer agent = heartbeat.”

 

New: “With the = attack scenario of the pipe going from the DOTS server to the DOTS = client running full, the DOTS server will be seeing the heartbeat = requests from the DOTS client, but no responses from the DOTS server = initiated heartbeats.  The DOTS server SHOULT NOT consider the = session terminated after "missing-hb-allowed" has been = exceeded, but SHOULD continue with the session and SHOULD continue = sending heartbeats on the assumption that it is a pipe full scenario and = there potentially could be new mitigation requests from the DOTS = client.  Any “trigger-mitigation” set to = “false” MUST still be triggered when = "missing-hb-allowed" has been = exceeded.

 

Similarly, the DOTS = client will be seeing nothing coming from the DOTS server.  After = "missing-hb-allowed" has been exceeded, the DOTS client SHOULD = try (D)TLS session resumption or use 0-RTT mode in (D)TLS 1.3 to = piggyback a new mitigation request in the ClientHello, but MUST continue to send heartbeats using the = "missing-hb-allowed" failing session so that the DOTS server = knows there still is communication.  If the DOTS client has a new = mitigation request, the DOTS client SHOULD “blindly” send = the new mitigation request over the “failing” session in = addition to the session resumption.  Only when traffic starts to = arrive again from the DOTS server should the “failing” = session be dropped and a new session = established.

 

Orig: = “   While the communication between the DOTS agents is = quiescent, the

   DOTS client will probe the DOTS = server to ensure it has maintained

   = cryptographic state and vice versa.  Such probes can also keep = alive

   firewall and/or NAT bindings.  = This probing reduces the frequency of

   = establishing a new handshake when a DOTS signal needs to be = conveyed

   to the DOTS = server.“

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 27 October 2017 07:07
To: Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] Full Pipe = Scenario

 

Heartbeat mechanism is = triggered only when the communication b/w the DOTS agents is idle (see = https://tools.ietf.org/html/draft-ie= tf-dots-signal-channel-05#section-5.6). =  

In this case, the DOTS client does = not receive any mitigation response from the DOTS server, and the DOTS = client knows the inbound pipe is saturated, but the DOTS client does not = know if the DOTS session is disconnected. To handle both the problems, = and maximize reachability, the DOTS client can continue to use the same = DOTS session even if no response is received for the heartbeat but at = the same time try (D)TLS session resumption or use 0-RTT mode in (D)TLS = 1.3 to piggyback the mitigation request in the ClientHello. =

When the inbound pipe is no longer = saturated, but the DOTS client does not receive any heartbeat responses = from the DOTS server then it should consider the session is defunct =

after missing-hb-allowed number of = times.

 

-Tiru

 

 

Hi,

 

DOTS Client (C) –-------- =  Pipe –------- DOTS Server (S)

 

We have been testing DOTS server and DOTS client = signal channel interaction with a full inbound pipe scenario where all = traffic from DOTS server to DOTS client is dropped, but traffic from = DOTS client is getting through to the DOTS server.

 

The outbound = pipe may be lossy, but testing was done with very little loss = outbound.

 

If the outbound pipe is running full, then the DOTS = Client environment has to control this traffic as the DOTS Server is = very unlikely to be able to do anything here – so this scenario = ignored!

 

With this full inbound pipe (direction S to C), we are = seeing the following

 

·       DOTS server = sees the Heartbeat requests from the DOTS client

·       DOTS server = sees any mitigation requests from the DOTS client

·       DOTS server = thinks the signal channel is dead as there are no responses to the DOTS = server’s Heartbeats

·       DOTS client = thinks the signal channel is dead as there are no responses to the DOTS = client’s Heartbeats

·       DOTS client = is unable to establish a new signal channel with the server (this may be = down to the fact that we internally have not (yet) got session = resumption working over DTLS) and so cannot send mitigation requests = over  this channel

 

If the DOTS = server is seeing and noting the DOTS client Heartbeat requests, it can = determine the session is still alive and keep it going, even if its own = Heartbeats are failing (perhaps just mark the session as = ‘Heartbeat Failing’ after the missing heartbeat counter has = expired).  Should we be doing this noting of DOTS Client = heartbeats?

 

[TR] Yes, it s

 

-The DOTS = server can safely assume there is a pipe full scenario (or network = routing issue) if it continues to see the DOTS client = heartbeats.

 

If the DOTS server is still keeping the session going, = and receives a DOTS client mitigation request it can be acted on, even = though there is a full pipe.  Is this a good = thing?

 

Should the DOTS client continue to send Heartbeats = after the DOTS client has determined the session has ‘Heartbeat = Failed’ – so that that the DOTS server is kept = “warm” in case a mitigation request has to blindly be = sent.

 

If the DOTS client closes the session after Heartbeat = failure, fails to establish a new session, then there is no mechanism to = send a mitigation request – the DOTS client may have discovered a = new IP or subnet under attack.

- I = appreciate that we have a trigger-mitigation flag which may help = here.

- If the new session gets = going, then the “Heartbeat Failure” session should be closed = down.

 

Keeping the Heartbeats going, even after the = determination that Heartbeats are failing has benefits in supporting = additional mitigation requests, but potentially conflicts with the DOTS = requirements specification of considering a DOTS signal channel as no = longer active after receipt of heartbeat responses.  I know SIG-003 = is the subject of another debate – do we need heartbeats at = all.

 

   SIG-003  Channel Health Monitoring: = Peer DOTS agents MUST regularly

      send heartbeats to each = other after mutual authentication in order

      to keep the DOTS signal = channel active.  A signal channel MUST be

      considered active until = a DOTS agent explicitly ends the session,

      or either DOTS agent = fails to receive heartbeats from the other

      after a mutually agreed = upon timeout period has elapsed.

 

Regards

 

Jon

------=_NextPart_000_03A6_01D35152.9E55FD40-- From nobody Mon Oct 30 00:51:15 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A69F13FFC1 for ; Mon, 30 Oct 2017 00:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 u2UiY7b2RK0U for ; Mon, 30 Oct 2017 00:51:12 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 1E2C413FFAF for ; Mon, 30 Oct 2017 00:51:11 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509349871; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=7 z1SAEvhP7a7xG8JjYDH08wGnt1/fkn5tzwGhCfUOm w=; b=CpBBw6Wam4kuxGdELPaXErGkNdOyUzQLeDfvZXLaahDt bfzwFfue/i9Nv452KEFsiSShZkLELYhmTRYaya4GkN6MQgRFg6 jMiKOO6y+oQo6gZizWzLF5np/PcoZrFroEZ0PSCN04lWLYJUd7 PbP/ceV/QR/IvIy34wIdhkvqzhw= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 5e78_306a_e1c55cbd_af68_4e38_8cf6_f147fdf981e3; Mon, 30 Oct 2017 02:51:10 -0500 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 03:51:09 -0400 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 03:51:08 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 30 Oct 2017 03:51:08 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 03:51:07 -0400 Received: from BN6PR16MB1777.namprd16.prod.outlook.com (10.172.28.141) by BN6PR16MB1777.namprd16.prod.outlook.com (10.172.28.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 07:51:06 +0000 Received: from BN6PR16MB1777.namprd16.prod.outlook.com ([10.172.28.141]) by BN6PR16MB1777.namprd16.prod.outlook.com ([10.172.28.141]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 07:51:06 +0000 From: "Konda, Tirumaleswar Reddy" To: "Mortensen, Andrew" , Flemming Andreasen CC: "dots@ietf.org" Thread-Topic: [Dots] Default port for DOTS signal channel Thread-Index: AdNO9p/vkseJmoMGQQ25Q8ucMqlEeAAPF6EAAAaIEIAAgaRsMA== Date: Mon, 30 Oct 2017 07:51:05 +0000 Message-ID: References: <896e0fcb-7360-5f15-8208-89353c07bdbb@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1777; 6:ct6S9nwOYivEuoaAqiFn/DoOC1b/dFBc29Vlj88RcUfNMN5sNgFr5UL+B4qHDMhio7DEG55MsjedG95+ehMO+UM8Kop7fhhuSVSEXaKAm5HwSh9KTXjLThWJLf+fXtevimGaWnqZKFVdKW6Qe+Kw9rED+zU3CqCTIbO4t04VtKAyg4u9Kc7cLYFh/0BHTLhR2NPS9hWONtvZOARsLE5hpRrwNyc92VDPn4Gou/iBb1Rr/094IKvU37ONd5lAdgmLpW+bMRa+WlysousGnC4FxfDUbghkIruR2hY4yOwTXCpnrGpG+FsT0Zrj1eRlFMKzTSwbTR1KXb6DerKoEsU2c3HW67uvfMyJ/cjx63iu7bk=; 5:pAMVI5v5WLuI+3g/D4LHwqSonA7/qpi5Xhw9uOOj/viiJb4Dvj+vRSn8bk6fmcizUvSj0qoIkuJqc5AfDm5ze6Qtfde+L4A+V3ycbPWCnYUYC8BYtsyUcg+NP6EQGQQ5stSmEdQ2cF71uvDBnNs2/7yxLag03XURY5pQgjryYQI=; 24:sn+flS1En0CYXEh3mE+++J5o+W2LBetp4iVnGu7yKMNVmAn5LkFkWow5VllIul9m89Y0vwKXHZbVLBAUue7qWIWwjw1r4r9DqdckZrieyh8=; 7:QjwPqTlRFll3uf9Pc8kH3HD+oD5XWDNJYS0ieOPLmQkfBxJw8gVw8qiVSaYHGRQdZQI+/qJiA1LB5n/t+OC2ePDsAf3r0vMenR5nTCRb4qpkaWI/4wKzs1DzlH1TJfZiYGCUVP08+zYDacklxVgz0nnSomIK4yRUbdpPMsgMnQH36Zvays5Mml3MzrBw9n5IyAPrmoi9ti2Il97CUbTlX4UoM/MSVC2NSGvq4zueZDcg2egi9ZB4rwut84nSihEh x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cae359cb-34a2-4266-7bc9-08d51f6af9e6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:BN6PR16MB1777; x-ms-traffictypediagnostic: BN6PR16MB1777: x-exchange-antispam-report-test: UriScan:(95692535739014)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231020)(10201501046)(100000703101)(100105400095)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR16MB1777; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR16MB1777; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(53754006)(199003)(32952001)(189002)(24454002)(53936002)(2906002)(86362001)(4326008)(7736002)(8936002)(33656002)(72206003)(101416001)(55016002)(50986999)(76176999)(6246003)(102836003)(74316002)(54356999)(8676002)(25786009)(478600001)(3280700002)(81156014)(81166006)(3846002)(966005)(3660700001)(68736007)(99286003)(6116002)(77096006)(6436002)(6506006)(790700001)(236005)(2950100002)(110136005)(7696004)(229853002)(19609705001)(66066001)(53546010)(2900100001)(606006)(189998001)(80792005)(97736004)(5660300001)(9686003)(105586002)(54896002)(6306002)(316002)(106356001)(14454004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1777; H:BN6PR16MB1777.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1777D02187C45330A077A0BCEA590BN6PR16MB1777namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cae359cb-34a2-4266-7bc9-08d51f6af9e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 07:51:06.0075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1777 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6146> : inlines <6150> : streams <1768830> : uri <2524726> Archived-At: Subject: Re: [Dots] Default port for DOTS signal channel X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 07:51:14 -0000 --_000_BN6PR16MB1777D02187C45330A077A0BCEA590BN6PR16MB1777namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEZsZW1taW5nIGFuZCBBbmRyZXcgZm9yIHRoZSBmZWVkYmFjaywgd2lsbCBhZGRyZXNz IHRoaXMgaXNzdWUgaW4gdGhlIG5leHQgcmV2aXNpb24uDQoNCi1UaXJ1DQoNCkZyb206IE1vcnRl bnNlbiwgQW5kcmV3IFttYWlsdG86YW1vcnRlbnNlbkBhcmJvci5uZXRdDQpTZW50OiBGcmlkYXks IE9jdG9iZXIgMjcsIDIwMTcgMTE6MjggUE0NClRvOiBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRy ZWFzQGNpc2NvLmNvbT4NCkNjOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsgZG90c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtE b3RzXSBEZWZhdWx0IHBvcnQgZm9yIERPVFMgc2lnbmFsIGNoYW5uZWwNCg0KDQpPbiBPY3QgMjcs IDIwMTcsIGF0IDEwOjUwIEFNLCBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2NvLmNv bTxtYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tPj4gd3JvdGU6DQoNClNvdW5kcyBnb29kIHRvIG1l Lg0KDQpMaWtld2lzZS4gSeKAmW0gc3RpbGwgaW4gZmF2b3Igb2YgdXNpbmcgNDY0NiwgaWYgd2Ug Y2FuIGdldCBpdC4NCg0KYW5kcmV3DQoNCg0KDQoNCk9uIDEwLzI3LzE3IDQ6MzQgQU0sIEtvbmRh LCBUaXJ1bWFsZXN3YXIgUmVkZHkgd3JvdGU6DQpIaSBhbGwsDQoNClRoZSBET1RTIHNpZ25hbCBj aGFubmVsIGRyYWZ0IGlzIGN1cnJlbnRseSB1c2luZyB0aGUgZGVmYXVsdCBwb3J0IDU2ODQgKHVz ZWQgYnkgKEQpVExTIHNlY3VyZWQgQ29BUCksIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucyBpbiB0 aGUgaW50ZXJpbSBXRyBtZWV0aW5nIHRvIGhhbmRsZSBzY2VuYXJpb3Mgd2hlcmUgRE9UUyBnYXRl d2F5IGFuZCBJT1QgZ2F0ZXdheSBjb3VsZCBiZSBjby1sb2NhdGVkIGFuZCBmb3IgbmV0d29yayBk ZXZpY2VzIHRvIGVuZm9yY2UgcG9saWNpZXMgKGUuZy4gUW9TKSBmb3IgRE9UUyBzaWduYWwgY2hh bm5lbCBkaWZmZXJlbnRseSwgRE9UUyBzaWduYWwgY2hhbm5lbCBuZWVkcyBhIGRpZmZlcmVudCBw b3J0Lg0KDQpJZiB0aGVyZSBhcmUgbm8gb2JqZWN0aW9ucyBmcm9tIHRoZSBXRywgSSBwbGFuIHRv IHVwZGF0ZSB0aGUgZHJhZnQgdG8gdXNlIGEgbmV3IHBvcnQgYXNzaWduZWQgYnkgdGhlIElBTkEg ZnJvbSB0aGUgcG9ydCBudW1iZXIgcmVnaXN0cnkuDQoNCkZ1cnRoZXIsIElmIHRoZSBXRyBhZ3Jl ZXMsIGFuZCB3aXRoIHRoZSBXRyBjaGFpcnMgYW5kIEFyZWEgRGlyZWN0b3JzIGhlbHAgYSBuZXcg cG9ydCBudW1iZXIgY2FuIGJlIHRlbXBvcmFyaWx5IGFzc2lnbmVkIGJ5IHRoZSBJQU5BLiBUaGUg c2FtZSBhcHByb2FjaCB3YXMgZm9sbG93ZWQgYnkgRFBSSVZFIFdHIGZvciBETlMtb3Zlci0oRClU TFMgZHJhZnRzIHRvIGdldCBhIG5ldyBwb3J0LCBhZnRlciB0aGUgZHJhZnRzIHdlcmUgYWRvcHRl ZCBieSB0aGUgV0cgYW5kIGltcGxlbWVudGVkIChzZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9kbnMtcHJpdmFjeS9jdXJyZW50L21zZzAwOTgxLmh0bWwgYW5kIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG5zLXByaXZhY3kvY3VycmVudC9tc2cw MDkyMi5odG1sKS4NCg0KLVRpcnUNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRvdHMgbWFpbGluZyBsaXN0DQoNCkRvdHNAaWV0 Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG90cw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg0K --_000_BN6PR16MB1777D02187C45330A077A0BCEA590BN6PR16MB1777namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlRoYW5rcyBGbGVtbWluZyBhbmQgQW5kcmV3IGZvciB0aGUgZmVlZGJhY2ssIHdpbGwgYWRkcmVz cyB0aGlzIGlzc3VlIGluIHRoZSBuZXh0IHJldmlzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tVGlydTxh IG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PG86cD48L286cD48L2E+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBNb3J0ZW5zZW4sIEFuZHJldyBbbWFpbHRvOmFtb3J0ZW5zZW5AYXJib3Iu bmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAyNywgMjAxNyAxMToyOCBQ TTxicj4NCjxiPlRvOjwvYj4gRmxlbW1pbmcgQW5kcmVhc2VuICZsdDtmYW5kcmVhc0BjaXNjby5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDtUaXJ1 bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tJmd0OzsgZG90c0BpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW0RvdHNdIERlZmF1bHQgcG9ydCBmb3IgRE9UUyBzaWduYWwgY2hh bm5lbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IE9jdCAyNywgMjAxNywgYXQgMTA6NTAgQU0sIEZsZW1taW5nIEFuZHJlYXNlbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbSI+ZmFuZHJlYXNAY2lzY28uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7YmFja2dyb3VuZDp3aGl0ZSI+U291bmRzIGdvb2QgdG8gbWUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5MaWtld2lzZS4gSeKAmW0gc3RpbGwgaW4gZmF2b3Igb2YgdXNpbmcgNDY0NiwgaWYgd2Ug Y2FuIGdldCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+YW5kcmV3PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMTAvMjcvMTcg NDozNCBBTSwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3Rl eHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0 bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRo ZSBET1RTIHNpZ25hbCBjaGFubmVsIGRyYWZ0IGlzIGN1cnJlbnRseSB1c2luZyB0aGUgZGVmYXVs dCBwb3J0IDU2ODQgKHVzZWQgYnkgKEQpVExTIHNlY3VyZWQgQ29BUCksIGJhc2VkIG9uIHRoZSBk aXNjdXNzaW9ucyBpbiB0aGUgaW50ZXJpbSBXRyBtZWV0aW5nDQogdG8gaGFuZGxlIHNjZW5hcmlv cyB3aGVyZSBET1RTIGdhdGV3YXkgYW5kIElPVCBnYXRld2F5IGNvdWxkIGJlIGNvLWxvY2F0ZWQg YW5kIGZvciBuZXR3b3JrIGRldmljZXMgdG8gZW5mb3JjZSBwb2xpY2llcyAoZS5nLiBRb1MpIGZv ciBET1RTIHNpZ25hbCBjaGFubmVsIGRpZmZlcmVudGx5LCBET1RTIHNpZ25hbCBjaGFubmVsIG5l ZWRzIGEgZGlmZmVyZW50IHBvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+SWYgdGhlcmUgYXJlIG5vIG9iamVjdGlvbnMgZnJvbSB0aGUgV0csIEkgcGxhbiB0byB1cGRh dGUgdGhlIGRyYWZ0IHRvIHVzZSBhIG5ldyBwb3J0IGFzc2lnbmVkIGJ5IHRoZSBJQU5BIGZyb20g dGhlIHBvcnQgbnVtYmVyIHJlZ2lzdHJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZ1cnRoZXIsIElmIHRoZSBXRyBhZ3JlZXMsIGFuZCB3aXRoIHRoZSBXRyBjaGFpcnMg YW5kIEFyZWEgRGlyZWN0b3JzIGhlbHAgYSBuZXcgcG9ydCBudW1iZXIgY2FuIGJlIHRlbXBvcmFy aWx5IGFzc2lnbmVkIGJ5IHRoZSBJQU5BLiBUaGUgc2FtZSBhcHByb2FjaA0KIHdhcyBmb2xsb3dl ZCBieSBEUFJJVkUgV0cgZm9yIEROUy1vdmVyLShEKVRMUyBkcmFmdHMgdG8gZ2V0IGEgbmV3IHBv cnQsIGFmdGVyIHRoZSBkcmFmdHMgd2VyZSBhZG9wdGVkIGJ5IHRoZSBXRyBhbmQgaW1wbGVtZW50 ZWQgKHNlZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Rucy1wcml2YWN5 L2N1cnJlbnQvbXNnMDA5ODEuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG5zLXByaXZhY3kvY3VycmVudC9tc2cw MDk4MS5odG1sPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+YW5kPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG5z LXByaXZhY3kvY3VycmVudC9tc2cwMDkyMi5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3 MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kbnMtcHJpdmFjeS9jdXJy ZW50L21zZzAwOTIyLmh0bWw8L3NwYW4+PC9hPikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5Eb3RzIG1haWxpbmcgbGlz dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVm PSJtYWlsdG86RG90c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPkRvdHNA aWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHMiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RvdHM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8c3Bh biBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPkRvdHMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 RG90c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTU0RjcyO2JhY2tncm91bmQ6 d2hpdGUiPkRvdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwv c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk1NEY3MjtiYWNrZ3JvdW5kOndoaXRlIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_BN6PR16MB1777D02187C45330A077A0BCEA590BN6PR16MB1777namp_-- From nobody Mon Oct 30 11:58:14 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABBBA1CD for ; Mon, 30 Oct 2017 11:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 rvtU_phc0RGq for ; Mon, 30 Oct 2017 11:58:11 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0114.outbound.protection.outlook.com [104.47.32.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0370D13F938 for ; Mon, 30 Oct 2017 11:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MQiR4L9P/OiZmYh7wA1ix9ClfzH8LFB3sX5AkjKH/8k=; b=ewPcj1sxuBi/6S4lYvLzGA8V5wrMD9Fy3np+AXc0dNENniQhdeQh+7bo129WY4HYjHUWGl2pV2dIp4DVrL44oJjYQKkbLO21IgoGaZ78egTLm8LzbtHTgcQRyv4j1YzHXIEYznbUjxIPgniewdQOj6jppZTIltyzWrk1QIeS39E= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1988.prod.exchangelabs.com (10.166.71.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 18:58:08 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 18:58:08 +0000 From: "Mortensen, Andrew" To: Flemming Andreasen CC: Dave Dolson , "mohamed.boucadair@orange.com" , "Konda, Tirumaleswar Reddy" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AQHTTmDYYVl2kLz7RkacOc3XVqREO6L2Wo0AgAAK6gCABl/SgA== Date: Mon, 30 Oct 2017 18:58:08 +0000 Message-ID: <5509420C-6912-4607-B163-5C25660E943F@arbor.net> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; x-originating-ip: [216.130.192.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1988; 6:gMNdBHK09Lny10svAyG5oIYeGOfViZKnkADsaljdYvGPf3lhbOvklKXyXzq7ZROdMew9doq8mweewl0CvmDK/TYA/kYxvtLzKhSyTSX4cfr7DKXrpuZDAB3dNYlkKzm/XAZVvMYZysNj0Te3roRb25QOYFJINzm1OVwwpTKYxpgsoUNafXzz8gHioe5cO8K7jqn9QfnVB6fTRaP8LQVKo68Ng43gJGFTnW0grd8wDHSMPDIkur2UTn8rO2NYD9LsD+x5+NQFsVCevTjQPXrj3VlPjIviq/wpzcbvBp3EVkdgGCryLUlbQPRQDWH4wTY3dCONosT9SLy1Lmc4cJN12BFiJxEUi2djbKkl3InJmbc=; 5:Zc4ehY0vpVe6JtE9Qghq/ZaRgk4lD5z5g7duV1BMT3xnTkq8Ata4fYEHiMhB1OGUeIDccb9dz7ZHaCiJh++RqLSN79P7a8t9LzctIMPKvtn0sCf86EDoOzlIJ06TsCw7D3Qf7jAvghrKs+pUDgOjXbFWyU8Oo/xfiM45J7yRIKU=; 24:TPTWZz2mU0Tk6J5gZVASuUtKwKKspDY0lmNQqE//LiOqsUa3DS7X53W5zPsUihq2tQcSElRZHmw6nafbaDHA0dDc2CFyWPKdcukGoVcljew=; 7:ODjSPQJkHE0VeQNXacbeGSX0FTTTkCUKTkutsewOsEqMRg6gSGpRRI1nqChRJbb5tYcAnN4qHpaVYu/ELbuCxK7COHsccThug4HDcMuWA1bB5vPDtbvNJNg2YeVs+ZC3LqP3vw1/DId3tkRwgUG6POMN8s0Zwae/GztfjXSSMUaApYYt0JTmBaLbwllhtRI9Pb6KuwmQ1YxcNCWn5jE5SrtySXm+kARBQQ0zI9L3c4WlP3j6CX6Fmf1dq+ihEUPQ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d1ad5855-cb17-434c-dd30-08d51fc8290b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:BN3PR01MB1988; x-ms-traffictypediagnostic: BN3PR01MB1988: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(95692535739014); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(3231020)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR01MB1988; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR01MB1988; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(57704003)(24454002)(189002)(199003)(81156014)(6486002)(53936002)(54906003)(54356999)(50986999)(6512007)(76176999)(189998001)(316002)(4326008)(93886005)(6246003)(2906002)(101416001)(3846002)(106356001)(478600001)(36756003)(105586002)(3280700002)(6116002)(102836003)(82746002)(3660700001)(86362001)(66066001)(6506006)(33656002)(25786009)(99286003)(2900100001)(83716003)(97736004)(68736007)(6436002)(229853002)(81166006)(8936002)(8676002)(14454004)(305945005)(7736002)(5660300001)(77096006)(6916009)(53546010)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1988; H:BN3PR01MB1987.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <9A6D06E6FF996C4FB38820F3293E2E93@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: d1ad5855-cb17-434c-dd30-08d51fc8290b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 18:58:08.3013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1988 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 18:58:13 -0000 > On Oct 26, 2017, at 1:37 PM, Flemming Andreasen wrot= e: >=20 > On 10/26/17 12:58 PM, Mortensen, Andrew wrote: > ... >> Do we need to recast the requirement to capture the peace-time aspect? F= or example, should a DOTS server be able to tell a client to stop heartbeat= s, or slow the heartbeat rate? >>=20 > That seems useful to me, however we may need to couple that with the clie= nt unilaterally increasing the rate when it's under attack to ensure bi-dir= ectional communication is still possible. Below is the SIG-003 proposed text for -07: SIG-003 Channel Health Monitoring: DOTS agents MUST support exchange of heartbeat messages over the signal channel to monitor channel health. Peer DOTS agents SHOULD regularly send heartbeats to each other while a mitigation request is active. The heartbeat interval during active mitigation is not specified, but SHOULD be frequent enough to maintain any on-path NAT bindings during mitigation. To support scenarios in which loss of heartbeat is used to trigger mitigation, and to keep the channel active, DOTS clients MAY solicit heartbeat exchanges after successful mutual authentication. When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to delay or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load. Following mutual authentication, a signal channel MUST be considered active until a DOTS agent explicitly ends the session, or either DOTS agent fails to receive heartbeats from the other after a mutually agreed upon timeout period has elapsed. andrew= From nobody Mon Oct 30 12:24:22 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DA513F602 for ; Mon, 30 Oct 2017 12:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urDrpzXVILsb for ; Mon, 30 Oct 2017 12:24:19 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 60359139059 for ; Mon, 30 Oct 2017 12:24:19 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e9FfU-00051H-HS; Mon, 30 Oct 2017 19:24:16 +0000 From: "Jon Shallow" To: "'Mortensen, Andrew'" , , "Konda, Tirumaleswar Reddy" References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> <5509420C-6912-4607-B163-5C25660E943F@arbor.net> In-Reply-To: <5509420C-6912-4607-B163-5C25660E943F@arbor.net> Date: Mon, 30 Oct 2017 19:24:16 -0000 Message-ID: <044601d351b4$ad35be60$07a13b20$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJn30ed00iE7qe0YFlJWgjFssA0bwJbZnRbAi+AMAsBWj2rLgHxtxAfAZp3c/4B7rP4RQJLUNJSAgrZIB0B9qWiOgIN6gJtAxyC0ecBPo33/AJGq47LAbjtPROg8vwUwA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 19:24:21 -0000 Hi Andrew, As per the discussion ' [Dots] Full Pipe Scenario' about handling situations with a full pipe dropping all traffic between the DOTS server and DOTS client where the heartbeat request can still be seen by the DOTS server, the DOTS Signal draft has been updated by Tiru with (3 paragraphs):- "In case of a volumetric DDoS attack saturating the incoming link to the DOTS client, all traffic from the DOTS server to the DOTS client will likely be dropped, although the DOTS server receives heartbeat requests and DOTS messages from the DOTS client. In this scenario, the DOTS agents MUST behave differently to handle message transmission and DOTS session liveliness during link saturation : * The DOTS client MUST NOT consider the DOTS session terminated even after maximum "missing-hb-allowed" threshold is reached. DOTS client SHOULD continue to use the current DOTS session, and send heartbeat requests over the current DOTS session, so the DOTS server knows the DOTS client has not disconnected the DOTS session. After the maximum "missing-hb-allowed" threshold is reached, the DOTS client SHOULD try (D)TLS session resumption. The DOTS client SHOULD send mitigation requests over the current DOTS session, and in parallel, try (D)TLS session resumption or 0-RTT mode in DTLS 1.3 to piggyback the mitigation request in the ClientHello message. Once the link is no longer statured, if traffic from the DOTS server reaches the DOTS client over the current DOTS session, the DOTS client can stop (D)TLS session resumption or if (D)TLS session resumption is successful then disconnect the current DOTS session. * If the DOTS server does not receive any traffic from the DOTS client, then the DOTS server sends heartbeat requests to the DOTS client and if "trigger-mitigation" is set to "false", then trigger DDoS mitigation after maximum "missing-hb-allowed" threshold is reached." This is in partial conflict with your suggestion (last half of final paragraph) of :- " Following mutual authentication, a signal channel MUST be considered active until a DOTS agent explicitly ends the session, or either DOTS agent fails to receive heartbeats from the other after a mutually agreed upon timeout period has elapsed." I'm not sure of the best way to reword this conflict. Regards Jon -----Original Message----- From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Mortensen, Andrew Sent: 30 October 2017 18:58 To: Flemming Andreasen Cc: Jon Shallow; Konda, Tirumaleswar Reddy; mohamed.boucadair@orange.com; dots@ietf.org; Dave Dolson Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) > On Oct 26, 2017, at 1:37 PM, Flemming Andreasen wrote: > > On 10/26/17 12:58 PM, Mortensen, Andrew wrote: > ... >> Do we need to recast the requirement to capture the peace-time aspect? For example, should a DOTS server be able to tell a client to stop heartbeats, or slow the heartbeat rate? >> > That seems useful to me, however we may need to couple that with the client unilaterally increasing the rate when it's under attack to ensure bi-directional communication is still possible. Below is the SIG-003 proposed text for -07: SIG-003 Channel Health Monitoring: DOTS agents MUST support exchange of heartbeat messages over the signal channel to monitor channel health. Peer DOTS agents SHOULD regularly send heartbeats to each other while a mitigation request is active. The heartbeat interval during active mitigation is not specified, but SHOULD be frequent enough to maintain any on-path NAT bindings during mitigation. To support scenarios in which loss of heartbeat is used to trigger mitigation, and to keep the channel active, DOTS clients MAY solicit heartbeat exchanges after successful mutual authentication. When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to delay or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load. Following mutual authentication, a signal channel MUST be considered active until a DOTS agent explicitly ends the session, or either DOTS agent fails to receive heartbeats from the other after a mutually agreed upon timeout period has elapsed. andrew _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Mon Oct 30 14:21:10 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E8013FB9E for ; Mon, 30 Oct 2017 14:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 gc9WymtR5Ehe for ; Mon, 30 Oct 2017 14:21:07 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0116.outbound.protection.outlook.com [104.47.40.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD10E13FB94 for ; Mon, 30 Oct 2017 14:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rkvCYPjHQH919U/LBxhm/+xQzMsVv1dup6l1O9CUUqo=; b=Fh4owu3Kd/+y5j7IuaeSgRgfoB7NRrwW8tTu1N7nHTe5JBoqF/e/buIXHVfP8P55/Nr9573tUYKQnhIdmTSfMyL4IpvA3vD6R0efqUjWfrYGS45fovy54bRrNumqbNL6SGDeqYteHI8+DA5aW5rQc6xOoyQcJdh/HxVDPuFCmcg= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1985.prod.exchangelabs.com (10.166.71.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 21:21:05 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 21:21:05 +0000 From: "Mortensen, Andrew" To: Jon Shallow CC: "dots@ietf.org" , "Konda, Tirumaleswar Reddy" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AQHTTmDYYVl2kLz7RkacOc3XVqREO6L2Wo0AgAAK6gCABl/SgIAAB08AgAAgogA= Date: Mon, 30 Oct 2017 21:21:05 +0000 Message-ID: <45176714-7846-48DE-90C5-F59ECB3A1A36@arbor.net> References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> <5509420C-6912-4607-B163-5C25660E943F@arbor.net> <044601d351b4$ad35be60$07a13b20$@jpshallow.com> In-Reply-To: <044601d351b4$ad35be60$07a13b20$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; x-originating-ip: [216.130.192.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1985; 6:DueTRhINt17hxfI3m0YeqEF5oLDljkOrEvg+9hyummb0CSHeUyuH64KIv2q3CNu1izkpo8kwvRB4zuZ5kcnstYEBTRm+aWVczr+t0LL0rSmoQxPDu2h8s9nv30q7m2upCSGwutDZUH5S/sCymZF/WO/EREi8SKL+otxSs23AlLG8VL//Z5NwoNnzOU+bO9idWZ10sBXIXaxd2tiG0wHDvz/WMMDxfOnOxG2asENw2kdW9QY5mJKrgJ79AdqDDVp1TuYi0BioS4Y66zoFeaBWtrwW6z5JldZPZCVJSBB8BF13dPK1I6aV0UzIJUk2+R4oOUXQucFq8DF1wLqE8aNmDzHPfsW4X7nPtBaJLU8aOPw=; 5:lu1vB1r+cUq2q8lAAry+KcVnjbDuC7szdpBFG4+cOIoX1NkcwA9Pb4v0+S8DeXe9vz1V1bCDB4DR0lO8nSv2FHTL7gBA03vMttXqDmtKoj7KA7zNZRjcr9l1Jr2KvZerzasgBzoZfL7fI9kemAtZ+C5JhjdyI0OOqvBATvuAbRY=; 24:FlOKn7hfMUbr/Z+/xC2rtIP09RxFY3EESL48Q0EJb583KQg9dhGEAogSA0CUz81fJPphmZODV8hTSHYigYhQxZvaboT9/ZZnA4rbCFspSKY=; 7:dLGl9hYwZmJAjZZkoUcmK+GgBqfDPcwOE4gCjVqvRGGeK+4r7+zaZcNJbJUm9oKdYW9S6uyYWppbq2xI8Nv+O7AKLQlAggM4CTnStLbkhkQ6nK2IUEdZJlTPCNevKoOiGBj8GHW+lq1+REgKtaYn3YZWr+eEYXOoVBiI5yGOOxlsYv0Ye+YQnj2kYJajc+oRQn3wSrvzXzPmAAkGheSiV9Qi6ztmi5l+jypdEupLClsam1obITe8cJYhR5RLp+3I x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fc304446-5ec0-4e6e-6c1f-08d51fdc212b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:BN3PR01MB1985; x-ms-traffictypediagnostic: BN3PR01MB1985: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3231020)(93006095)(93001095)(3002001)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR01MB1985; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR01MB1985; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(199003)(24454002)(189002)(6246003)(2900100001)(99286003)(101416001)(54356999)(8676002)(5660300001)(229853002)(305945005)(76176999)(6436002)(50986999)(6506006)(77096006)(8936002)(105586002)(6916009)(14454004)(6486002)(2950100002)(81156014)(36756003)(82746002)(81166006)(106356001)(189998001)(2906002)(33656002)(102836003)(3846002)(6116002)(93886005)(478600001)(316002)(54906003)(86362001)(3660700001)(83716003)(53546010)(3280700002)(68736007)(4326008)(97736004)(66066001)(6512007)(7736002)(53936002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1985; H:BN3PR01MB1987.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7F646F8EF39730439FB8E5D109F65F65@prod.exchangelabs.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: fc304446-5ec0-4e6e-6c1f-08d51fdc212b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 21:21:05.0053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1985 Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:21:09 -0000 DQo+IE9uIE9jdCAzMCwgMjAxNywgYXQgMzoyNCBQTSwgSm9uIFNoYWxsb3cgPHN1cGpwcy1pZXRm QGpwc2hhbGxvdy5jb20+IHdyb3RlOg0KPiANCj4g4oCmc25pcOKApg0KPiANCj4gKiBJZiB0aGUg RE9UUyBzZXJ2ZXIgZG9lcyBub3QgcmVjZWl2ZSBhbnkgdHJhZmZpYyBmcm9tIHRoZSBET1RTIGNs aWVudCwgdGhlbg0KPiB0aGUgRE9UUyBzZXJ2ZXIgc2VuZHMgaGVhcnRiZWF0IHJlcXVlc3RzIHRv IHRoZSBET1RTIGNsaWVudCBhbmQgaWYNCj4gInRyaWdnZXItbWl0aWdhdGlvbiIgaXMgc2V0IHRv ICJmYWxzZSIsIHRoZW4gdHJpZ2dlciBERG9TIG1pdGlnYXRpb24gYWZ0ZXINCj4gbWF4aW11bSAi bWlzc2luZy1oYi1hbGxvd2VkIiB0aHJlc2hvbGQgaXMgcmVhY2hlZC4iDQo+IA0KPiBUaGlzIGlz IGluIHBhcnRpYWwgY29uZmxpY3Qgd2l0aCB5b3VyIHN1Z2dlc3Rpb24gKGxhc3QgaGFsZiBvZiBm aW5hbA0KPiBwYXJhZ3JhcGgpIG9mICA6LQ0KPiANCj4gIiAgICAgRm9sbG93aW5nIG11dHVhbCBh dXRoZW50aWNhdGlvbiwgYSBzaWduYWwgY2hhbm5lbCBNVVNUIGJlDQo+ICAgICAgY29uc2lkZXJl ZCBhY3RpdmUgdW50aWwgYSBET1RTIGFnZW50IGV4cGxpY2l0bHkgZW5kcyB0aGUgc2Vzc2lvbiwN Cj4gICAgICBvciBlaXRoZXIgRE9UUyBhZ2VudCBmYWlscyB0byByZWNlaXZlIGhlYXJ0YmVhdHMg ZnJvbSB0aGUgb3RoZXINCj4gICAgICBhZnRlciBhIG11dHVhbGx5IGFncmVlZCB1cG9uIHRpbWVv dXQgcGVyaW9kIGhhcyBlbGFwc2VkLiINCj4gDQo+IEknbSBub3Qgc3VyZSBvZiB0aGUgYmVzdCB3 YXkgdG8gcmV3b3JkIHRoaXMgY29uZmxpY3QuICANCg0KVGhhbmtzIEpvbi4gSSBhZ3JlZSB0aGVz ZSBuZWVkIHRvIGJlIHJlY29uY2lsZWQuIFdl4oCZbGwgYWxzbyBuZWVkIHRvIHJlY29uc2lkZXIg U2VjdGlvbiA1LjYgb2YgdGhlIHNpZ25hbCBjaGFubmVsIGRyYWZ0IGdpdmVuIHRoZSBhZGRlZCB0 ZXh0IG9uIHNpZ25hbGluZyBvdmVyIGEgc2F0dXJhdGVkIGluLWJvdW5kIGxpbms6DQoNCjUuNi4g IEhlYXJ0YmVhdCBNZWNoYW5pc20NCg0KICAgVG8gcHJvdmlkZSBhIG1ldHJpYyBvZiBzaWduYWwg aGVhbHRoIGFuZCBkaXN0aW5ndWlzaCBhbiAnaWRsZScgc2lnbmFsDQogICBjaGFubmVsIGZyb20g YSAnZGlzY29ubmVjdGVkJyBvciAnZGVmdW5jdCcgc2Vzc2lvbiwgdGhlIERPVFMgYWdlbnQNCiAg IHNlbmRzIGEgaGVhcnRiZWF0IG92ZXIgdGhlIHNpZ25hbCBjaGFubmVsIHRvIG1haW50YWluIGl0 cyBoYWxmIG9mIHRoZQ0KICAgY2hhbm5lbC4gIFRoZSBET1RTIGFnZW50IHNpbWlsYXJseSBleHBl Y3RzIGEgaGVhcnRiZWF0IGZyb20gaXRzIHBlZXINCiAgIERPVFMgYWdlbnQsIGFuZCBtYXkgY29u c2lkZXIgYSBzZXNzaW9uIHRlcm1pbmF0ZWQgaW4gdGhlIGV4dGVuZGVkDQogICBhYnNlbmNlIG9m IGEgcGVlciBhZ2VudCBoZWFydGJlYXQuDQoNClRoYXQgc2VlbXMgbW9yZSBjbG9zZWx5IGFsaWdu ZWQgd2l0aCB0aGUgcGhyYXNpbmcgaW4gU0lHLTAwMyB0aGFuIHRoZSBhZGRpdGlvbnMgY292ZXJp bmcgaGVhcnRiZWF0cyBkdXJpbmcgdm9sdW1ldHJpYyBpbmJvdW5kIGF0dGFjay4gSW4gdGhlIGF0 dGVtcHQgdG8gYWNjb3VudCBmb3IgaGVhcnRiZWF0IGxvc3MgZHVyaW5nIGEgdm9sdW1ldHJpYyBh dHRhY2ssIHRoZSBuZXcgYWRkaXRpb25zIGRvbuKAmXQgc2VlbSB0byBiZSBhY2NvdW50aW5nIGZv ciBob3cgdG8gZGVjaWRlIHdoZW4gYSBjbGllbnQtaW5pdGlhdGVkIG1pdGlnYXRpb24gaXMgb3Jw aGFuZWQsIGUuZy4sIGR1ZSB0byBET1RTIGNsaWVudCByZWJvb3QuDQoNClRvIHRyeSB0byBtYWtl IHJvb20gZm9yIGEgcmVzb2x1dGlvbiBpbiB0aGUgc2lnbmFsIGNoYW5uZWwgZHJhZnQsIGhlcmXi gJlzIGEgc3RhYiBhdCByZXdvcmRpbmcgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIFNJRy0wMDM6DQoN CiAgRm9sbG93aW5nIG11dHVhbCBhdXRoZW50aWNhdGlvbiwgYSBzaWduYWwgY2hhbm5lbCBNVVNU IGJlIGNvbnNpZGVyZWQgYWN0aXZlDQogIHVudGlsIGEgRE9UUyBhZ2VudCBleHBsaWNpdGx5IGVu ZHMgdGhlIHNlc3Npb24sIG9yIGVpdGhlciBET1RTIGFnZW50IGZhaWxzIHRvDQogIHJlY2VpdmUg aGVhcnRiZWF0cyBmcm9tIHRoZSBvdGhlciBhZnRlciBhIG11dHVhbGx5IGFncmVlZCB1cG9uIHRp bWVvdXQgcGVyaW9kDQogIGhhcyBlbGFwc2VkLiBCZWNhdXNlIGhlYXJ0YmVhdCBsb3NzIGlzIG11 Y2ggbW9yZSBsaWtlbHkgZHVyaW5nIHZvbHVtZXRyaWMNCiAgYXR0YWNrLCBET1RTIGFnZW50cyBT SE9VTEQgYXZvaWQgc2lnbmFsIGNoYW5uZWwgdGVybWluYXRpb24gd2hlbiBtaXRpZ2F0aW9uDQog IGlzIGFjdGl2ZSBhbmQgaGVhcnRiZWF0cyBhcmUgbm90IHJlY2VpdmVkIGJ5IGVpdGhlciBET1RT IGFnZW50IGZvciBhbiBleHRlbmRlZA0KICBwZXJpb2QuIEluIHN1Y2ggY2lyY3Vtc3RhbmNlcywg RE9UUyBjbGllbnRzIE1BWSBhdHRlbXB0IHRvIHJlZXN0YWJsaXNoIHRoZQ0KICBzaWduYWwgY2hh bm5lbC4gRE9UUyBzZXJ2ZXJzIFNIT1VMRCBtb25pdG9yIHRoZSBhdHRhY2ssIHVzaW5nIGZlZWRi YWNrIGZyb20NCiAgdGhlIG1pdGlnYXRvciBhbmQgb3RoZXIgYXZhaWxhYmxlIHNvdXJjZXMsIGFu ZCBNQVkgdXNlIHRoZSBhYnNlbmNlIG9mIGF0dGFjaw0KICB0cmFmZmljIGFuZCBsYWNrIG9mIGNs aWVudCBoZWFydGJlYXRzIGFzIGFuIGluZGljYXRpb24gdGhlIHNpZ25hbCBjaGFubmVsIGlzDQog IGRlZnVuY3QuDQoNCkkgd2lsbCBwcm9jZWVkIHdpdGggcHVibGlzaGluZyAtMDcgY29udGFpbmlu ZyBzb21ldGhpbmcgdmVyeSBzaW1pbGFyIHRvIHRoZSBhYm92ZSB3aGlsZSB3ZSBjb250aW51ZSB0 aGlzIGRpc2N1c3Npb24uDQoNCmFuZHJldw0KDQo= From nobody Mon Oct 30 15:03:06 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FEC13374A; Mon, 30 Oct 2017 15:02:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940097917.28306.15862783172549473695@ietfa.amsl.com> Date: Mon, 30 Oct 2017 15:02:59 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-requirements-07.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:02:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-07.txt Pages : 21 Date : 2017-10-30 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack response against DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-07 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 15:05:30 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2AB13FC24 for ; Mon, 30 Oct 2017 15:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 WiWFXfxZe1Gp for ; Mon, 30 Oct 2017 15:05:26 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0107.outbound.protection.outlook.com [104.47.38.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B172213FBED for ; Mon, 30 Oct 2017 15:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aCALS8RxUBQVJ0877DB0z1vfhw+UbPyYPQKm74zZ3Pw=; b=fsZ/tcP5SFYiIs/50wSBehnxIXAi/7qo4jLFMCaQcCnvkMtfKq3KBM7MUTxKhfJ/UljGMUpcK3RCN5ctiGZwMj0p3tvVicP4hPX4LcDPzi3cl9uELuI88HP3chOkG3ArcrBvmOpiVDHHO6x8ETuDxqH6jVhiVG9YgO1NnM0wukQ= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 22:05:24 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 22:05:24 +0000 From: "Mortensen, Andrew" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-07.txt Thread-Index: AQHTUcreO5NwBCTVAEqX8fk17WZeiqL88seA Date: Mon, 30 Oct 2017 22:05:23 +0000 Message-ID: <751A35FD-0941-4E67-A5C1-B674C78B1F5D@arbor.net> References: <150940097917.28306.15862783172549473695@ietfa.amsl.com> In-Reply-To: <150940097917.28306.15862783172549473695@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=amortensen@arbor.net; x-originating-ip: [216.130.192.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1987; 6:nu3uPvOsMJ6f2MjiinTLVPJwK9Q3I5z3d6+c7KS4qK79DNPk3sl9z+ceUVTeKuXE7Oj0hRpVsuQreZ8yzCgPvq7O5NwGnyjV6JUkvoBYPy8GDILip4uG/bZ/GJJ9sqbyTGhphQVka2JACQpDycYJrfupA2Yp9l5IPfDSY6qP8S7nrF/TEX9gDTKIkPHmjpRHapPa+o91Ww+KVilK2uh1StQMHfGrFVlhzuY4GRmorc2JOjv453gt4G4hdlV013HNWp0Mi7+To5mvQzXpb1JfRG0MFp3nsHAtWs5xdZA+VZcBuZBZ8yZpwxvY+esOsCPNgtmiNpPJIiRoSF6oGWJth6zDaWGzK7h5qD1ppDM1W58=; 5:W5/CXmzobKEvuUQFYMyOTj7j4wqs7LVV4+WuOYMLSPgo47SRtlEx1quPQlmXQ/p6hwNVLtZWIVzYp7KmoKBbpPbsIgngzTMYiejE6mwRwYEClgkeEXkLFDdICMWFD7X/RAZo6ObLBi6koxzrLVoGUeMury+f78hWSKIrGlhM8cY=; 24:a0oe/ge0OUxG+YibKmm+/TcsxQFQZ9H+JloojNFZw7xMvkp5IO8uFCxTg8bEbEwxgN0KgwBVKkVAh7gNk++cifvuPutRRDndKZWcVX/er6M=; 7:TSFyxvGLtBAsp5MFYThUcOfPE584GFjjiYHUbtZzULHFd9MCSfGgTQugJeid6qqgT6NvcqHIeY6GeshciAxL+yOEgDOTV6srHHBkrbOHnHu24+icCqb64RzjFSrn1O/zKTXNpE3hkKBanVOrujPq+QtXPLd8/MdwDNJJizP7bbj+XG4Pf9rowvQPC53WVi1XVp2GX20p9wlKUz6m3rRlLOmPuaw4RefcZ/+se3aUzdelRbJV8gtxJ+zB1cr8hUbm x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 127d2b20-887b-404b-8003-08d51fe251f8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:BN3PR01MB1987; x-ms-traffictypediagnostic: BN3PR01MB1987: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231020)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR01MB1987; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR01MB1987; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(24454002)(377424004)(199003)(189002)(2900100001)(86362001)(230783001)(236005)(6512007)(25786009)(53546010)(81166006)(478600001)(14454004)(966005)(606006)(189998001)(6306002)(99286003)(54896002)(7736002)(82746002)(8676002)(36756003)(1730700003)(81156014)(50986999)(76176999)(54356999)(101416001)(8936002)(33656002)(2351001)(102836003)(66066001)(2950100002)(6916009)(6436002)(6506006)(5660300001)(5640700003)(97736004)(105586002)(6486002)(106356001)(229853002)(83716003)(68736007)(77096006)(53936002)(3280700002)(316002)(4001150100001)(2906002)(6116002)(3846002)(6246003)(2501003)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1987; H:BN3PR01MB1987.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_751A35FD09414E67A5C1B674C78B1F5Darbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 127d2b20-887b-404b-8003-08d51fe251f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 22:05:23.9072 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1987 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-07.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:05:29 -0000 --_000_751A35FD09414E67A5C1B674C78B1F5Darbornet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The latest revision of the requirements draft attempts to incorporate most,= if not all, current feedback on the -06 revision of the draft. We are hopi= ng to go to WGLC as soon as possible, so please review and open new issues = on the GitHub tracker: andrew On Oct 30, 2017, at 6:02 PM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial of Service (DDoS) Open Threat S= ignaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-07.txt Pages : 21 Date : 2017-10-30 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack response against DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-07 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-requirements-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_751A35FD09414E67A5C1B674C78B1F5Darbornet_ Content-Type: text/html; charset="us-ascii" Content-ID: <759F816F28228545A116BF80B3AC664B@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable
The latest revision of the requirements draft attempts to i= ncorporate most, if not all, current feedback on the -06 revision of the dr= aft. We are hoping to go to WGLC as soon as possible, so please review and = open new issues on the GitHub tracker:

<https://github.com/dotswg/dots-requirements/issues>

andrew




On Oct 30, 2017, at 6:02 PM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.=

       Title     &nb= sp;     : Distributed Denial of Service (DDoS) Ope= n Threat Signaling Requirements
       Authors     &= nbsp;   : Andrew Mortensen
            &nb= sp;            = Robert Moskowitz
            &nb= sp;            = Tirumaleswar Reddy
Filename &n= bsp;      : draft-ietf-dots-requirements-07.t= xt
Pages  = ;         : 21
Date  =           : 2017-10-30
Abstract:
  This document defines the requirements for the Distributed Deni= al of
  Service (DDoS) Open Threat Signaling (DOTS) protocols coordinat= ing
  attack response against DDoS attacks.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dots-requirements-07
https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-requirements-07


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

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

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--_000_751A35FD09414E67A5C1B674C78B1F5Darbornet_-- From nobody Mon Oct 30 23:57:51 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7954A11B05 for ; Mon, 30 Oct 2017 23:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6CFQuq2bSsp for ; Mon, 30 Oct 2017 23:57:47 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 0294413F40C for ; Mon, 30 Oct 2017 23:57:46 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 0F6A325F68D; Tue, 31 Oct 2017 15:57:45 +0900 (JST) Received: from SR2-nishizuka.lv4.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 91F8E75900A; Tue, 31 Oct 2017 15:57:44 +0900 (JST) To: "Konda, Tirumaleswar Reddy" , "dots@ietf.org" References: <150908884672.22115.5536801606930175694@ietfa.amsl.com> From: kaname nishizuka Message-ID: Date: Tue, 31 Oct 2017 15:57:44 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-06.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 06:57:49 -0000 Hi Tiru, I've read through -06 version and noticed some things. 1. CBOR mapping notation of "alt-server", "alt-server-record", "addr", "ttl" are missing on Fig.21 and 10.2.2. 2. session-id in DELETE request has been removed from -06 version. I'm afraid it is already mentioned. Was there a discussion on this? I'm happy if you gave me a pointer. thank you, Kaname On 2017/10/27 16:31, Konda, Tirumaleswar Reddy wrote: > This revision https://tools.ietf.org/html/draft-ietf-dots-signal-channel-06 and https://tools.ietf.org/html/draft-ietf-dots-data-channel-06 addresses various comments from Jon, > especially related to the usage of 'client-identifier'. > > -Tiru > >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Friday, October 27, 2017 12:51 PM >> To: i-d-announce@ietf.org >> Cc: dots@ietf.org >> Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-06.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. >> >> Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) >> Signal Channel >> Authors : Tirumaleswar Reddy >> Mohamed Boucadair >> Prashanth Patil >> Andrew Mortensen >> Nik Teague >> Filename : draft-ietf-dots-signal-channel-06.txt >> Pages : 58 >> Date : 2017-10-27 >> >> Abstract: >> This document specifies the DOTS signal channel, a protocol for >> signaling the need for protection against Distributed Denial-of- >> Service (DDoS) attacks to a server capable of enabling network >> traffic mitigation on behalf of the requesting client. A companion >> document defines the DOTS data channel, a separate reliable >> communication layer for DOTS management and configuration. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dots-signal-channel-06 >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-06 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-06 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Oct 31 01:10:40 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36A213F721 for ; Tue, 31 Oct 2017 01:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57p6N502pDj0 for ; Tue, 31 Oct 2017 01:10:36 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A13513F6DD for ; Tue, 31 Oct 2017 01:10:36 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 9ABE0608CA; Tue, 31 Oct 2017 09:10:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 78D3A160071; Tue, 31 Oct 2017 09:10:34 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0361.001; Tue, 31 Oct 2017 09:10:34 +0100 From: To: "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-07.txt Thread-Index: AQHTUcrfdpYI1fNFeEmevJ/K45ZlmKL84gSAgAC3/rA= Date: Tue, 31 Oct 2017 08:10:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A063069@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <150940097917.28306.15862783172549473695@ietfa.amsl.com> <751A35FD-0941-4E67-A5C1-B674C78B1F5D@arbor.net> In-Reply-To: <751A35FD-0941-4E67-A5C1-B674C78B1F5D@arbor.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A063069OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-07.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 08:10:39 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A063069OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Andrew, Thank you for addressing all my comments. This version is stable and, as such, it is ready for a WGLC. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Mortensen, Andrew Envoy=E9 : lundi 30 octobre 2017 23:05 =C0 : dots@ietf.org Objet : Re: [Dots] I-D Action: draft-ietf-dots-requirements-07.txt The latest revision of the requirements draft attempts to incorporate most,= if not all, current feedback on the -06 revision of the draft. We are hopi= ng to go to WGLC as soon as possible, so please review and open new issues = on the GitHub tracker: andrew On Oct 30, 2017, at 6:02 PM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial of Service (DDoS) Open Threat S= ignaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-07.txt Pages : 21 Date : 2017-10-30 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack response against DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-07 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-requirements-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_787AE7BB302AE849A7480A190F8B93300A063069OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Andrew,

 

Thank you for addressing all my= comments.

 

This version is stable and, as = such, it is ready for a WGLC.

 

Cheers,

Med

 

De : Dots= [mailto:dots-bounces@ietf.org] De la part de Mortensen, Andrew
Envoy=E9 : lundi 30 octobre 2017 23:05
=C0 : dots@ietf.org
Objet : Re: [Dots] I-D Action: draft-ietf-dots-requirements-07.= txt

 

The latest revision of the requirements draft attemp= ts to incorporate most, if not all, current feedback on the -06 revision of= the draft. We are hoping to go to WGLC as soon as possible, so please revi= ew and open new issues on the GitHub tracker:

 

 

andrew

 

 

 

 

On Oct 30, 2017, at 6:02 PM, internet-drafts@ietf.org wrote:

 


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.=

       Title     &nb= sp;     : Distributed Denial of Service (DDoS) Ope= n Threat Signaling Requirements
       Authors     &= nbsp;   : Andrew Mortensen
            &nb= sp;            = Robert Moskowitz
            &nb= sp;            = Tirumaleswar Reddy
Filename        : draft-ietf-dots-requir= ements-07.txt
Pages           : 21
Date            : 20= 17-10-30

Abstract:
  This document defines the requirements for the Distributed Deni= al of
  Service (DDoS) Open Threat Signaling (DOTS) protocols coordinat= ing
  attack response against DDoS attacks.


The IETF datatracker status page for this draft is:
= https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/

There are also htmlized versions available at:
htt= ps://tools.ietf.org/html/draft-ietf-dots-requirements-07
https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-0= 7

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-requirements-07


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

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

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org= /mailman/listinfo/dots

 

--_000_787AE7BB302AE849A7480A190F8B93300A063069OPEXCLILMA3corp_-- From nobody Tue Oct 31 01:46:50 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2AB13F6EB for ; Tue, 31 Oct 2017 01:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 YIMHsaKDijmU for ; Tue, 31 Oct 2017 01:46:47 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 C163713F666 for ; Tue, 31 Oct 2017 01:46:46 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509439605; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=O Cqne1lnc43UwgzpMnj8dHHAE9C0MbFy5TEJw057K6 4=; b=DrGBOyMV8QAZ6hoxp8iNLhM2znerJkZuC/cYUaO9dNFT xnunYfwFQrAfA1Ke3C5ECwUdpmtEyszHOIZp2spn+kBMIXwKde MUnQ0DN6n+e2Uyvp7cAk7EuIft1/bEd5LfUTF3gWfTr5xuJviO i0OKmRFDeS/dslm8+EZQg7ToKKY= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 53b2_332a_ceb44f31_98df_48d2_b22d_92063b2e696d; Tue, 31 Oct 2017 03:46:45 -0500 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 31 Oct 2017 04:46:42 -0400 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 31 Oct 2017 04:46:41 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 31 Oct 2017 04:46:41 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 31 Oct 2017 04:46:26 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 31 Oct 2017 08:46:24 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0178.012; Tue, 31 Oct 2017 08:46:24 +0000 From: "Konda, Tirumaleswar Reddy" To: kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-06.txt Thread-Index: AQHTTvQ6bTPRuNDyK0ynhxISfWBDCKL3TS5AgAZAAwCAAB2MsA== Date: Tue, 31 Oct 2017 08:46:24 +0000 Message-ID: References: <150908884672.22115.5536801606930175694@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 20:NIz+H1ebVNWl4QJbDcsQSPA7zKrKw4WHoe4W4eGp4g0Fot7xvRwHQbKpZTyHvXl8O6liaSr16gtkbzWUNscYGHH1OCLVpJ7yRlslv+kfstkx9zS04VaDKLA1YZ+mXYIBNWEHx+gzRrL9D8mWESo53ElVhETqil2hQJ0rSgX6ab4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 38c8b597-7ad2-4ccc-812e-08d5203bde4a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(3231020)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(32952001)(377424004)(24454002)(13464003)(189002)(99286003)(97736004)(3280700002)(102836003)(2501003)(9686003)(3660700001)(3846002)(6246003)(2906002)(68736007)(53546010)(81166006)(81156014)(6116002)(6506006)(6306002)(72206003)(478600001)(76176999)(54356999)(77096006)(229853002)(25786009)(966005)(4001150100001)(80792005)(50986999)(189998001)(6436002)(86362001)(55016002)(305945005)(2950100002)(101416001)(110136005)(33656002)(53936002)(8676002)(66066001)(5660300001)(105586002)(106356001)(2900100001)(7696004)(8936002)(230783001)(316002)(7736002)(14454004)(74316002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 38c8b597-7ad2-4ccc-812e-08d5203bde4a X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 08:46:24.6127 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6147> : inlines <6152> : streams <1768930> : uri <2525377> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-06.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 08:46:49 -0000 VGhhbmtzIGthbmFtZSBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBrYW5hbWUgbmlzaGl6dWthIFttYWlsdG86 a2FuYW1lQG50dHY2LmpwXQ0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMxLCAyMDE3IDEyOjI4 IFBNDQo+IFRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9L b25kYUBNY0FmZWUuY29tPjsNCj4gZG90c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0RvdHNd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0wNi50eHQNCj4gDQo+ IEhpIFRpcnUsDQo+IA0KPiBJJ3ZlIHJlYWQgdGhyb3VnaCAtMDYgdmVyc2lvbiBhbmQgbm90aWNl ZCBzb21lIHRoaW5ncy4NCj4gDQo+IDEuIENCT1IgbWFwcGluZyBub3RhdGlvbiBvZiAiYWx0LXNl cnZlciIsICJhbHQtc2VydmVyLXJlY29yZCIsICJhZGRyIiwgInR0bCINCj4gYXJlIG1pc3Npbmcg b24gRmlnLjIxIGFuZCAxMC4yLjIuDQoNCkZpeGVkLg0KDQo+IA0KPiAyLiBzZXNzaW9uLWlkIGlu IERFTEVURSByZXF1ZXN0IGhhcyBiZWVuIHJlbW92ZWQgZnJvbSAtMDYgdmVyc2lvbi4NCj4gSSdt IGFmcmFpZCBpdCBpcyBhbHJlYWR5IG1lbnRpb25lZC4gV2FzIHRoZXJlIGEgZGlzY3Vzc2lvbiBv biB0aGlzPw0KDQpZZXMsIGl0IHdhcyByZW1vdmVkIGJlY2F1c2UgREVMRVRFIHdvdWxkIGRlbGV0 ZSB0aGUgY3VycmVudCBjb25maWd1cmF0aW9uIGFuZCB0aGUgRE9UUyBzZXJ2ZXIgcmVzZXRzIHRo ZSBET1RTIHNpZ25hbCBjaGFubmVsIHNlc3Npb24gY29uZmlndXJhdGlvbg0KYmFjayB0byB0aGUg ZGVmYXVsdCB2YWx1ZXMuIA0KDQotVGlydQ0KDQo+IEknbSBoYXBweSBpZiB5b3UgZ2F2ZSBtZSBh IHBvaW50ZXIuDQo+IA0KPiB0aGFuayB5b3UsDQo+IEthbmFtZQ0KPiANCj4gDQo+IA0KPiANCj4g T24gMjAxNy8xMC8yNyAxNjozMSwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSB3cm90ZToNCj4g PiBUaGlzIHJldmlzaW9uDQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtZG90cy1zaWduYWwtY2hhbm5lbC0wNiBhbmQNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMDYgYWRkcmVzc2VzIHZhcmlvdXMNCj4g Y29tbWVudHMgZnJvbSBKb24sIGVzcGVjaWFsbHkgcmVsYXRlZCB0byB0aGUgdXNhZ2Ugb2YgJ2Ns aWVudC1pZGVudGlmaWVyJy4NCj4gPg0KPiA+IC1UaXJ1DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0LQ0KPiA+PiBkcmFmdHNAaWV0Zi5vcmcNCj4gPj4g U2VudDogRnJpZGF5LCBPY3RvYmVyIDI3LCAyMDE3IDEyOjUxIFBNDQo+ID4+IFRvOiBpLWQtYW5u b3VuY2VAaWV0Zi5vcmcNCj4gPj4gQ2M6IGRvdHNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogW0Rv dHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0wNi50eHQNCj4g Pj4NCj4gPj4NCj4gPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9yaWVzLg0KPiA+PiBUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBERG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZyBXRyBvZiB0 aGUNCj4gSUVURi4NCj4gPj4NCj4gPj4gICAgICAgICAgVGl0bGUgICAgICAgICAgIDogRGlzdHJp YnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQgU2lnbmFsaW5nDQo+IChET1RTKQ0K PiA+PiBTaWduYWwgQ2hhbm5lbA0KPiA+PiAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBUaXJ1 bWFsZXN3YXIgUmVkZHkNCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgTW9oYW1lZCBC b3VjYWRhaXINCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgUHJhc2hhbnRoIFBhdGls DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuZHJldyBNb3J0ZW5zZW4NCj4gPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgTmlrIFRlYWd1ZQ0KPiA+PiAJRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTA2LnR4dA0KPiA+PiAJUGFnZXMg ICAgICAgICAgIDogNTgNCj4gPj4gCURhdGUgICAgICAgICAgICA6IDIwMTctMTAtMjcNCj4gPj4N Cj4gPj4gQWJzdHJhY3Q6DQo+ID4+ICAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgRE9U UyBzaWduYWwgY2hhbm5lbCwgYSBwcm90b2NvbCBmb3INCj4gPj4gICAgIHNpZ25hbGluZyB0aGUg bmVlZCBmb3IgcHJvdGVjdGlvbiBhZ2FpbnN0IERpc3RyaWJ1dGVkIERlbmlhbC1vZi0NCj4gPj4g ICAgIFNlcnZpY2UgKEREb1MpIGF0dGFja3MgdG8gYSBzZXJ2ZXIgY2FwYWJsZSBvZiBlbmFibGlu ZyBuZXR3b3JrDQo+ID4+ICAgICB0cmFmZmljIG1pdGlnYXRpb24gb24gYmVoYWxmIG9mIHRoZSBy ZXF1ZXN0aW5nIGNsaWVudC4gIEEgY29tcGFuaW9uDQo+ID4+ICAgICBkb2N1bWVudCBkZWZpbmVz IHRoZSBET1RTIGRhdGEgY2hhbm5lbCwgYSBzZXBhcmF0ZSByZWxpYWJsZQ0KPiA+PiAgICAgY29t bXVuaWNhdGlvbiBsYXllciBmb3IgRE9UUyBtYW5hZ2VtZW50IGFuZCBjb25maWd1cmF0aW9uLg0K PiA+Pg0KPiA+Pg0KPiA+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhp cyBkcmFmdCBpczoNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLw0KPiA+Pg0KPiA+PiBUaGVyZSBhcmUgYWxzbyBodG1s aXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+ID4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMDYNCj4gPj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwt DQo+ID4+IDA2DQo+ID4+DQo+ID4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDoNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0wNg0KPiA+Pg0KPiA+Pg0KPiA+PiBQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv Zg0KPiA+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5vcmcuDQo+ID4+DQo+ID4+IEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPj4gZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gRG90cyBtYWlsaW5nIGxpc3QN Cj4gPj4gRG90c0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RvdHMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gRG90c0BpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQo= From nobody Tue Oct 31 01:59:16 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B393F13A41F for ; Tue, 31 Oct 2017 01:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 vfYtlJq1HqHd for ; Tue, 31 Oct 2017 01:59:13 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 CBCA013F6E2 for ; Tue, 31 Oct 2017 01:59:12 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1509440351; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=apdMvLqgNvuONzYl8bV9f3vATfTNRchzvdMdJz ygi+k=; b=QNG/Ygd+iqbHqqKhKBunHCldSAczvMACLOPspBPR uhVKozsTB383TACs1clrDF+fq/jzfHU7xYLNi0+bz/1EK8UD9f zPR8v63GEWdd5JnsGU2PcAidYeTir/k12ENws1fbH/+LLwvDSU sYKs6UJ9a2JUfkoGy48vPFvGfigVg+Y= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 53b2_5230_2ae594c1_e60d_44c3_9438_447b4d0bd62b; Tue, 31 Oct 2017 03:59:11 -0500 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 31 Oct 2017 04:59:01 -0400 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 31 Oct 2017 04:59:00 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 31 Oct 2017 04:59:00 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 31 Oct 2017 04:58:51 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 31 Oct 2017 08:58:41 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0178.012; Tue, 31 Oct 2017 08:58:41 +0000 From: "Konda, Tirumaleswar Reddy" To: "Mortensen, Andrew" , Jon Shallow CC: "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AQHTTmDj2RAQrm+kS0aEpR2RXflMS6L2Wo6AgAAK6QCABl/TAIAAB00AgAAgpICAAL/IEA== Date: Tue, 31 Oct 2017 08:58:40 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> <5509420C-6912-4607-B163-5C25660E943F@arbor.net> <044601d351b4$ad35be60$07a13b20$@jpshallow.com> <45176714-7846-48DE-90C5-F59ECB3A1A36@arbor.net> In-Reply-To: <45176714-7846-48DE-90C5-F59ECB3A1A36@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 20:6pWWqWeLRJImJnAhWv8ILBUnZJU1wCW7hN15aDx6yGbTzieFsigTiYPoIp6ZVz/Mt3Mzy2zyZVvO42GfM0RSWl+0PWTcy6ubnEd5z5N69ZkamOXbgQMwgIBomoaOTBHU/oi3CCurQVOK9n/ZI6dBzZbBxYHX4rsww0JTS/M8cXU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 238d2261-4a1e-41a6-7382-08d5203d952f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(3231020)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 04772EA191 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(13464003)(24454002)(189002)(199003)(32952001)(101416001)(33656002)(53936002)(110136005)(55016002)(189998001)(6436002)(86362001)(2950100002)(305945005)(316002)(7736002)(7696004)(8936002)(74316002)(14454004)(66066001)(5660300001)(8676002)(106356001)(2900100001)(105586002)(2906002)(6246003)(3846002)(68736007)(81156014)(81166006)(6116002)(53546010)(3660700001)(99286003)(93886005)(102836003)(4326008)(9686003)(3280700002)(97736004)(25786009)(229853002)(50986999)(80792005)(6506006)(478600001)(72206003)(76176999)(54356999)(77096006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 238d2261-4a1e-41a6-7382-08d5203d952f X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 08:58:40.8430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6147> : inlines <6152> : streams <1768931> : uri <2525381> Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 08:59:15 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNb3J0ZW5zZW4sIEFuZHJldyBb bWFpbHRvOmFtb3J0ZW5zZW5AYXJib3IubmV0XQ0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMx LCAyMDE3IDI6NTEgQU0NCj4gVG86IEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0ZkBqcHNoYWxsb3cu Y29tPg0KPiBDYzogZG90c0BpZXRmLm9yZzsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA8 VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCj4gU3ViamVjdDogUmU6IFtEb3Rz XSBET1RTICYgTkFUICh3YXMgUkU6IERPVFMgUmVxdWlyZW1lbnRzIHJldmlldyAoLTA2KSkNCj4g DQo+IA0KPiA+IE9uIE9jdCAzMCwgMjAxNywgYXQgMzoyNCBQTSwgSm9uIFNoYWxsb3cgPHN1cGpw cy1pZXRmQGpwc2hhbGxvdy5jb20+DQo+IHdyb3RlOg0KPiA+DQo+ID4g4oCmc25pcOKApg0KPiA+ DQo+ID4gKiBJZiB0aGUgRE9UUyBzZXJ2ZXIgZG9lcyBub3QgcmVjZWl2ZSBhbnkgdHJhZmZpYyBm cm9tIHRoZSBET1RTDQo+ID4gY2xpZW50LCB0aGVuIHRoZSBET1RTIHNlcnZlciBzZW5kcyBoZWFy dGJlYXQgcmVxdWVzdHMgdG8gdGhlIERPVFMNCj4gPiBjbGllbnQgYW5kIGlmICJ0cmlnZ2VyLW1p dGlnYXRpb24iIGlzIHNldCB0byAiZmFsc2UiLCB0aGVuIHRyaWdnZXINCj4gPiBERG9TIG1pdGln YXRpb24gYWZ0ZXIgbWF4aW11bSAibWlzc2luZy1oYi1hbGxvd2VkIiB0aHJlc2hvbGQgaXMNCj4g cmVhY2hlZC4iDQo+ID4NCj4gPiBUaGlzIGlzIGluIHBhcnRpYWwgY29uZmxpY3Qgd2l0aCB5b3Vy IHN1Z2dlc3Rpb24gKGxhc3QgaGFsZiBvZiBmaW5hbA0KPiA+IHBhcmFncmFwaCkgb2YgIDotDQo+ ID4NCj4gPiAiICAgICBGb2xsb3dpbmcgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCBhIHNpZ25hbCBj aGFubmVsIE1VU1QgYmUNCj4gPiAgICAgIGNvbnNpZGVyZWQgYWN0aXZlIHVudGlsIGEgRE9UUyBh Z2VudCBleHBsaWNpdGx5IGVuZHMgdGhlIHNlc3Npb24sDQo+ID4gICAgICBvciBlaXRoZXIgRE9U UyBhZ2VudCBmYWlscyB0byByZWNlaXZlIGhlYXJ0YmVhdHMgZnJvbSB0aGUgb3RoZXINCj4gPiAg ICAgIGFmdGVyIGEgbXV0dWFsbHkgYWdyZWVkIHVwb24gdGltZW91dCBwZXJpb2QgaGFzIGVsYXBz ZWQuIg0KPiA+DQo+ID4gSSdtIG5vdCBzdXJlIG9mIHRoZSBiZXN0IHdheSB0byByZXdvcmQgdGhp cyBjb25mbGljdC4NCj4gDQo+IFRoYW5rcyBKb24uIEkgYWdyZWUgdGhlc2UgbmVlZCB0byBiZSBy ZWNvbmNpbGVkLiBXZeKAmWxsIGFsc28gbmVlZCB0bw0KPiByZWNvbnNpZGVyIFNlY3Rpb24gNS42 IG9mIHRoZSBzaWduYWwgY2hhbm5lbCBkcmFmdCBnaXZlbiB0aGUgYWRkZWQgdGV4dCBvbg0KPiBz aWduYWxpbmcgb3ZlciBhIHNhdHVyYXRlZCBpbi1ib3VuZCBsaW5rOg0KPiANCj4gNS42LiAgSGVh cnRiZWF0IE1lY2hhbmlzbQ0KPiANCj4gICAgVG8gcHJvdmlkZSBhIG1ldHJpYyBvZiBzaWduYWwg aGVhbHRoIGFuZCBkaXN0aW5ndWlzaCBhbiAnaWRsZScgc2lnbmFsDQo+ICAgIGNoYW5uZWwgZnJv bSBhICdkaXNjb25uZWN0ZWQnIG9yICdkZWZ1bmN0JyBzZXNzaW9uLCB0aGUgRE9UUyBhZ2VudA0K PiAgICBzZW5kcyBhIGhlYXJ0YmVhdCBvdmVyIHRoZSBzaWduYWwgY2hhbm5lbCB0byBtYWludGFp biBpdHMgaGFsZiBvZiB0aGUNCj4gICAgY2hhbm5lbC4gIFRoZSBET1RTIGFnZW50IHNpbWlsYXJs eSBleHBlY3RzIGEgaGVhcnRiZWF0IGZyb20gaXRzIHBlZXINCj4gICAgRE9UUyBhZ2VudCwgYW5k IG1heSBjb25zaWRlciBhIHNlc3Npb24gdGVybWluYXRlZCBpbiB0aGUgZXh0ZW5kZWQNCj4gICAg YWJzZW5jZSBvZiBhIHBlZXIgYWdlbnQgaGVhcnRiZWF0Lg0KPiANCj4gVGhhdCBzZWVtcyBtb3Jl IGNsb3NlbHkgYWxpZ25lZCB3aXRoIHRoZSBwaHJhc2luZyBpbiBTSUctMDAzIHRoYW4gdGhlDQo+ IGFkZGl0aW9ucyBjb3ZlcmluZyBoZWFydGJlYXRzIGR1cmluZyB2b2x1bWV0cmljIGluYm91bmQg YXR0YWNrLiBJbiB0aGUNCj4gYXR0ZW1wdCB0byBhY2NvdW50IGZvciBoZWFydGJlYXQgbG9zcyBk dXJpbmcgYSB2b2x1bWV0cmljIGF0dGFjaywgdGhlIG5ldw0KPiBhZGRpdGlvbnMgZG9u4oCZdCBz ZWVtIHRvIGJlIGFjY291bnRpbmcgZm9yIGhvdyB0byBkZWNpZGUgd2hlbiBhIGNsaWVudC0NCj4g aW5pdGlhdGVkIG1pdGlnYXRpb24gaXMgb3JwaGFuZWQsIGUuZy4sIGR1ZSB0byBET1RTIGNsaWVu dCByZWJvb3QuDQoNCk5vLCB0aGUgdXBkYXRlZCB0ZXh0IGhhbmRsZXMgdGhlIGFib3ZlIHNjZW5h cmlvLiBJbiBjYXNlIG9mIHNhdHVyYXRlZCBpbmNvbWluZyBsaW5rIHRvIHRoZSBET1RTIGNsaWVu dCwgSWYgdGhlIERPVFMgc2VydmVyIGRvZXMgbm90IHJlY2VpdmUgYW55IHRyYWZmaWMgZnJvbSB0 aGUgcGVlciBET1RTIGNsaWVudCwgdGhlbiB0aGUgRE9UUyBzZXJ2ZXIgc2VuZHMgaGVhcnRiZWF0 IHJlcXVlc3RzIHRvIHRoZSBET1RTIGNsaWVudCBhbmQgaWYg4oCcdHJpZ2dlci1taXRpZ2F0aW9u 4oCdIGlzIHNldCB0byDigJxmYWxzZeKAnSwgdGhlbiB0cmlnZ2VyIEREb1MgbWl0aWdhdGlvbiBh ZnRlciBtYXhpbXVtICJtaXNzaW5nLWhiLWFsbG93ZWQiIHRocmVzaG9sZCBpcyByZWFjaGVkLiAN Cg0KLVRpcnUNCg0KPiANCj4gVG8gdHJ5IHRvIG1ha2Ugcm9vbSBmb3IgYSByZXNvbHV0aW9uIGlu IHRoZSBzaWduYWwgY2hhbm5lbCBkcmFmdCwgaGVyZeKAmXMgYSBzdGFiDQo+IGF0IHJld29yZGlu ZyB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgU0lHLTAwMzoNCj4gDQo+ICAgRm9sbG93aW5nIG11dHVh bCBhdXRoZW50aWNhdGlvbiwgYSBzaWduYWwgY2hhbm5lbCBNVVNUIGJlIGNvbnNpZGVyZWQNCj4g YWN0aXZlDQo+ICAgdW50aWwgYSBET1RTIGFnZW50IGV4cGxpY2l0bHkgZW5kcyB0aGUgc2Vzc2lv biwgb3IgZWl0aGVyIERPVFMgYWdlbnQgZmFpbHMgdG8NCj4gICByZWNlaXZlIGhlYXJ0YmVhdHMg ZnJvbSB0aGUgb3RoZXIgYWZ0ZXIgYSBtdXR1YWxseSBhZ3JlZWQgdXBvbiB0aW1lb3V0DQo+IHBl cmlvZA0KPiAgIGhhcyBlbGFwc2VkLiBCZWNhdXNlIGhlYXJ0YmVhdCBsb3NzIGlzIG11Y2ggbW9y ZSBsaWtlbHkgZHVyaW5nIHZvbHVtZXRyaWMNCj4gICBhdHRhY2ssIERPVFMgYWdlbnRzIFNIT1VM RCBhdm9pZCBzaWduYWwgY2hhbm5lbCB0ZXJtaW5hdGlvbiB3aGVuDQo+IG1pdGlnYXRpb24NCj4g ICBpcyBhY3RpdmUgYW5kIGhlYXJ0YmVhdHMgYXJlIG5vdCByZWNlaXZlZCBieSBlaXRoZXIgRE9U UyBhZ2VudCBmb3IgYW4NCj4gZXh0ZW5kZWQNCj4gICBwZXJpb2QuIEluIHN1Y2ggY2lyY3Vtc3Rh bmNlcywgRE9UUyBjbGllbnRzIE1BWSBhdHRlbXB0IHRvIHJlZXN0YWJsaXNoIHRoZQ0KPiAgIHNp Z25hbCBjaGFubmVsLiBET1RTIHNlcnZlcnMgU0hPVUxEIG1vbml0b3IgdGhlIGF0dGFjaywgdXNp bmcgZmVlZGJhY2sNCj4gZnJvbQ0KPiAgIHRoZSBtaXRpZ2F0b3IgYW5kIG90aGVyIGF2YWlsYWJs ZSBzb3VyY2VzLCBhbmQgTUFZIHVzZSB0aGUgYWJzZW5jZSBvZg0KPiBhdHRhY2sNCj4gICB0cmFm ZmljIGFuZCBsYWNrIG9mIGNsaWVudCBoZWFydGJlYXRzIGFzIGFuIGluZGljYXRpb24gdGhlIHNp Z25hbCBjaGFubmVsIGlzDQo+ICAgZGVmdW5jdC4NCj4gDQo+IEkgd2lsbCBwcm9jZWVkIHdpdGgg cHVibGlzaGluZyAtMDcgY29udGFpbmluZyBzb21ldGhpbmcgdmVyeSBzaW1pbGFyIHRvIHRoZQ0K PiBhYm92ZSB3aGlsZSB3ZSBjb250aW51ZSB0aGlzIGRpc2N1c3Npb24uDQo+IA0KPiBhbmRyZXcN Cg0K From nobody Tue Oct 31 11:21:05 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F0C13FA22 for ; Tue, 31 Oct 2017 11:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 RP40cas5pRmY for ; Tue, 31 Oct 2017 11:20:59 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F65213F9C1 for ; Tue, 31 Oct 2017 11:20:59 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v9VIKv89019809 for ; Tue, 31 Oct 2017 14:20:57 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu v9VIKv89019809 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1509474057; bh=TzCLHuDXdtz/fOLPSiWsAlA8WqwkWJD3TmO5tzwMvek=; h=From:To:Subject:Date:From; b=YqLcXSDpVLhhudvuRY9QgbLnS3aXhQ6KimYBCEfe8+c8WF8Wg34ESrYESyqqCrgoJ Z6AFdTESLNmteneQ8ZajehPJMtDdfg2FTMX3a2jlzFRl7kLqBk5jr7eojnEAnTVwHS t+oz2ieGllHU7r3pG6gWPP523I6u+swyHrtbWumU= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v9VIKv1e016901 for ; Tue, 31 Oct 2017 14:20:57 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Tue, 31 Oct 2017 14:20:57 -0400 From: Roman Danyliw To: "'dots@ietf.org'" Thread-Topic: Draft IETF 100 Agenda Thread-Index: AdNSdON/4P4sA8quRW2O8bv7spw0xg== Date: Tue, 31 Oct 2017 18:20:57 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104FF864B@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Draft IETF 100 Agenda X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:21:01 -0000 Hello WG! A draft of the IETF 100 DOTS WG agenda can be found at: https://datatracker.ietf.org/meeting/100/materials/agenda-100-dots/ Regards, Roman and Tobias From nobody Tue Oct 31 18:29:12 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF66D13F586 for ; Tue, 31 Oct 2017 18:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 XscbgyJqSPLA for ; Tue, 31 Oct 2017 18:29:09 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4E213F62B for ; Tue, 31 Oct 2017 18:29:08 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id r129so861166lff.8 for ; Tue, 31 Oct 2017 18:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AMolFrNprweHlTblm+ymKO7pcebp+fbai4NdO4Ihe84=; b=S8DdptK/+2IBK1QbIo0CJJFQZWsSR/qgMJ2yLZXxUG8obWMOb6nrsv6kAivMMjjRV1 4scEk9sPPB4chHRQlg3jvyWvE2LOHgTfEm8cV/FW9p3zG9zx59Do3ALWhFVmT8DAAZXZ i8lKvKZa8tGarvlRbxKQ9pcadLYLzQM/Os8OOuug2d6KZ4raorDFCZTwGrUDUfVcfh7/ r6O2YLSfl+7B89+8YHZ9s06hi45nfq2UccH7cAHmfS8OI8u6BZ7Y5/kHPUNKYNNq8Yj/ jzvSmG61qJIW1KrgFmCRwm/HsQQcFfWF4W7eZK8AV6ndYHSWbSm788eVlke7d/4sUIgc BW5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AMolFrNprweHlTblm+ymKO7pcebp+fbai4NdO4Ihe84=; b=s7dk9kT2kUfBgknWcGMuq8rrZFpg14cwFU6YrEuzXO8jlQlvYlOMWPta1Fkpnjd9iO SW6agkzjtH76HG8/Ov8o2o/yCjgOs0pq5X0amAuvsX6RZNZg7HZnaqdKn47X2IcDzi4O uSxRwzPqNbs+Hb2QeAp/JF53aoAbIMwktG6s/1fczgrWJQFGruk65hr0TBMKLTIcmfXR wQV6XIV6vHLqaU3YSSNIiMm8sdf4SMpXxrv7f4nSPYuXIrImoHVjtmtWMCrVwBHDRjol 5ZTQQJpNRmxt8mxgAFzk9hoNEGucCmiCUd8J9Mf7Nxa6XKNQdbZaiY6au36DaijlN4Ca x6ng== X-Gm-Message-State: AMCzsaXDbJ2o0iemsnCPL+zNmFh1D6spwg73BOJFaRuuSF4UCqkiyIMG m1nR+0EWj4ZpDru71bopgGyiRHm8m3/HCYCnwNE= X-Google-Smtp-Source: ABhQp+Qo4+dJHGM3QMRSQUvmUdvCzzs0sGzhJZBPIS3i2HgnM9rgDiUfAVtuoUZcCgn4lWg/Ppl49CnJJgph1OVkMJA= X-Received: by 10.25.17.22 with SMTP id g22mr1467624lfi.183.1509499746547; Tue, 31 Oct 2017 18:29:06 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.68.29 with HTTP; Tue, 31 Oct 2017 18:29:06 -0700 (PDT) In-Reply-To: <97BBC935-0E42-47B4-8678-02354E7454B7@arbor.net> References: <150888203847.25249.11590483174597116578@ietfa.amsl.com> <97BBC935-0E42-47B4-8678-02354E7454B7@arbor.net> From: Daniel Migault Date: Tue, 31 Oct 2017 21:29:06 -0400 X-Google-Sender-Auth: XVIjl1cYuN5N9-0atBw3RPaDWRk Message-ID: To: Roland Dobbins Cc: dots@ietf.org Content-Type: multipart/alternative; boundary="001a114076242e7d79055ce1ccad" Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-use-cases-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 01:29:11 -0000 --001a114076242e7d79055ce1ccad Content-Type: text/plain; charset="UTF-8" Hi, Thanks Roland for posting 08. I have a few comments Use case from section 3.1.1 to 3.1.4 seems to me very similar, thus I am wondering if it would not make sense to have them in one section. Nit: When an attack is detected, an automated or manual DOTS mitigation request is be generated. I believe "be" should be removed. section 3.1.{5, 6, 7, 8}, 3.2.{1, 2, 3} all mention the DOTS communication model is the one of Section 3.1.1 or Section 3.1.2. I am thus wondering if it would not help to have this model described as a model from which the use cases are derived. Yours, Daniel On Tue, Oct 24, 2017 at 5:59 PM, Roland Dobbins wrote: > On 25 Oct 2017, at 4:53, internet-drafts@ietf.org wrote: > > Filename : draft-ietf-dots-use-cases-08.txt >> > > Comments and suggestions welcome; in particular, the WG's consensus on the > Home Network use-case in Section 3.2.2 and the relative value it adds as > compared to the other use cases would be greatly appreciated. > > We'd like to rev the draft at least one more time prior to the pre-meeting > cutoff, so please don't be shy! > > ;> > > ----------------------------------- > Roland Dobbins > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --001a114076242e7d79055ce1ccad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

Thanks Roland for posting 08. I have a few = comments

Use case from section=C2=A0 3.1.1 to 3.1.4 seems t= o me very similar, thus I am wondering if it would not make sense to have them in one section.

Nit:

When an attack is detected, an automated or= manual DOTS mitigation request is be generated. I believe "be" should be removed.


section 3.1.{5, 6, 7, 8}, 3.2.{1, 2, 3}=C2=A0 all mention = the DOTS communication model is the one of Section 3.1.1 or Section 3.1.2. I am thus wondering if it would not help to have this model described as a model from which the use cases are derived.

Yours,
=
Daniel

On Tue, Oct 24, 2017 at 5:59 PM, Roland Dob= bins <rdobbins@arbor.net> wrote:
On 25 Oct 2017, at 4:53, internet-drafts@ietf.org wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dots-use-cases-08.txt

Comments and suggestions welcome; in particular, the WG's consensus on = the Home Network use-case in Section 3.2.2 and the relative value it adds a= s compared to the other use cases would be greatly appreciated.

We'd like to rev the draft at least one more time prior to the pre-meet= ing cutoff, so please don't be shy!

;>

-----------------------------------
Roland Dobbins <= rdobbins@arbor.net>


_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--001a114076242e7d79055ce1ccad--