From nobody Sun Apr 6 23:47:41 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4216B1A028A for ; Sun, 6 Apr 2014 23:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.24 X-Spam-Level: X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 CW7H078-KBLC for ; Sun, 6 Apr 2014 23:47:35 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id AC8611A0682 for ; Sun, 6 Apr 2014 23:47:34 -0700 (PDT) X-AuditID: c1b4fb32-b7fe98e0000034f3-a7-534249ff1158 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 19.B4.13555.FF942435; Mon, 7 Apr 2014 08:47:28 +0200 (CEST) Received: from [131.160.126.81] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.174.1; Mon, 7 Apr 2014 08:47:27 +0200 Message-ID: <534249FF.9010008@ericsson.com> Date: Mon, 7 Apr 2014 09:47:27 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIJMWRmVeSWpSXmKPExsUyM+JvjS6Dl1OwwdQ13Bb/1h1lcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt89jUwFfUwVW29FNjBeYuxi5OSQEDCReLy8gRXCFpO4cG89 WxcjF4eQwElGiaknbjFCOKsZJWZdvczUxcjBwSugLfFhjz5IA4uAisTkS49ZQGw2AQuJLbfu g9miAlES3ZMesYPYvAKCEidnPgGLiwAtWHfrOSvIGGEBDYmtCwNATAkBcYmexiCQCmYBPYkp V1sYIWx5ie1v5zCD2EJAS5c/a2GZwMg/C8nQWUhaZiFpWcDIvIpRsji1uDg33chALzc9t0Qv tSgzubg4P0+vOHUTIzDYDm75bbSD8eQe+0OM0hwsSuK811lrgoQE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUweib6Hn4aKbq38rP64f/m8b86rLtmPLkXnhmycZuz9M+Ik+t0m/9rPquJUr1u Uc+4IOS1ici7TQefP+idc+ZeovyCZqZdn11M3vBVmqZfvsC3SHrlZX2LWZl+n18kxid0h7lt iJa9faO0M1jod1hEl2qLqVd29uUktsBLJREWux97nip3rzyoxFKckWioxVxUnAgA3YzbsAQC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/wZA3rFxjGjakgclVmhZ6pvRCvws Subject: [bfcpbis] Progressing 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 06:47:39 -0000 Hi, the call for comments on 4582bis and 4583bis is over. I have not seen any response to the comments Charles sent a couple of weeks ago. Additionally, Christer has also sent some comments. What is the time plan to progress these drafts? Thanks, Gonzalo From nobody Mon Apr 7 03:03:04 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F871A0386 for ; Mon, 7 Apr 2014 03:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjB-aHwwISDa for ; Mon, 7 Apr 2014 03:02:58 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id F022D1A06E5 for ; Mon, 7 Apr 2014 03:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=793; q=dns/txt; s=iport; t=1396864973; x=1398074573; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MxcwXDM+WgBbUFZnnYLZiRhViXTScLFsoKvxhcPOiik=; b=BC8zbTR3s8sIsSU8Z15aiR5JJKg38eRZDF7xzA5fRD8i1cPItMDGOqO+ Qn7mLCvnlLQ4WiIiOiTy8lciw+9mnn0sw4rF2ak4CMp9AHIQmhbKou3TO DmD18/1idYyp3x/tFK3asgMW7Stxarm3C4f2xXybxKXQR0JbEaElhPhW7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAC53QlOtJssV/2dsb2JhbABZgwY7vTqGZlGBIhZ0giUBAQEEAQEBGhs2CgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGHdQ3LNhMEjnEHhDgBA5hbhlGLboMyOw X-IronPort-AV: E=Sophos;i="4.97,809,1389744000"; d="scan'208";a="9731113" Received: from aer-core-4.cisco.com ([173.38.203.21]) by aer-iport-4.cisco.com with ESMTP; 07 Apr 2014 10:02:51 +0000 Received: from [10.61.85.7] (ams3-vpn-dhcp5384.cisco.com [10.61.85.7]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s37A2mAA008524; Mon, 7 Apr 2014 10:02:48 GMT Message-ID: <534277C8.1010003@cisco.com> Date: Mon, 07 Apr 2014 12:02:48 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Gonzalo Camarillo References: <534249FF.9010008@ericsson.com> In-Reply-To: <534249FF.9010008@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/s5oXx5UWMuR51HFdqMtyPGUNbuQ Cc: bfcpbis@ietf.org Subject: Re: [bfcpbis] Progressing 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 10:03:03 -0000 Comments from Charles was fine and is fixed, will respond to list. I'm currently trying to figure out how to cope with Christer's input and issues, will respond to list for that as well. The time plan should be fixing immediately, so any delay is very much unfortunate :( I agree. -- Tom On 04/07/2014 08:47 AM, Gonzalo Camarillo wrote: > Hi, > the call for comments on 4582bis and 4583bis is over. I have not seen > any response to the comments Charles sent a couple of weeks ago. > Additionally, Christer has also sent some comments. > > What is the time plan to progress these drafts? > > Thanks, > > Gonzalo > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > From nobody Mon Apr 7 03:05:10 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7931A06E8 for ; Mon, 7 Apr 2014 03:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.851 X-Spam-Level: X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utggcIk86rHX for ; Mon, 7 Apr 2014 03:05:05 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D358B1A06EA for ; Mon, 7 Apr 2014 03:05:04 -0700 (PDT) X-AuditID: c1b4fb2d-b7f328e0000012ab-06-5342784a1f94 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CF.C4.04779.A4872435; Mon, 7 Apr 2014 12:04:58 +0200 (CEST) Received: from [131.160.126.81] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.174.1; Mon, 7 Apr 2014 12:04:58 +0200 Message-ID: <53427849.4000704@ericsson.com> Date: Mon, 7 Apr 2014 13:04:57 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tom Kristensen References: <534249FF.9010008@ericsson.com> <534277C8.1010003@cisco.com> In-Reply-To: <534277C8.1010003@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RterwinY4O4PY4t/644yWVw58ovN gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4e2QtS8E69ortn0IbGB+zdjFyckgImEi8 7TjLDmGLSVy4t56ti5GLQ0jgMKPE0eOPmSGc1YwSd3+uAKviFdCWuPd1Mlg3i4CKxIKPnWA2 m4CFxJZb91lAbFGBKInuSY+g6gUlTs58AhYXEVCX6Nv7HSzODLTt6pFJjCC2sICZRPf7vUwg tpCAh0TX7P1g9ZwCmhJ/v94FquEAuk5coqcxCKJVT2LK1RZGCFteYvvbOcwQrdoSy5+1sExg FJqFZPMsJC2zkLQsYGRexciem5iZk15uuIkRGKgHt/zW3cF46pzIIUZpDhYlcd4Pb52DhATS E0tSs1NTC1KL4otKc1KLDzEycXBKNTC6bDGK+bxe4ND/krmfN/M/EmFeX/Rk9+FpnIvvF55t Nl1moc/z79HOyQ5/FkVLbnF6UVmrUxq7XSPheWLNtOX+XS37pMx1XC9Y+c3f6ttk+aomKmtm tkPdnpMM6Y2mdmtKT4RKsC2v57zMxrJ25+Hpf1Q1LeUZ3F4nTUjZ97pg9oSXn3fytFxXYinO SDTUYi4qTgQAjNEtQyICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/pS4agx9ybcNAxpct2Mwuw-nXhIQ Cc: bfcpbis@ietf.org Subject: Re: [bfcpbis] Progressing 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 10:05:09 -0000 Thanks for the quick response, Tom. Cheers, Gonzalo On 07/04/2014 1:02 PM, Tom Kristensen wrote: > Comments from Charles was fine and is fixed, will respond to list. > > I'm currently trying to figure out how to cope with Christer's input and > issues, will respond to list for that as well. > > The time plan should be fixing immediately, so any delay is very much > unfortunate :( I agree. > > -- Tom > > On 04/07/2014 08:47 AM, Gonzalo Camarillo wrote: >> Hi, >> the call for comments on 4582bis and 4583bis is over. I have not seen >> any response to the comments Charles sent a couple of weeks ago. >> Additionally, Christer has also sent some comments. >> >> What is the time plan to progress these drafts? >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> > From nobody Wed Apr 16 09:21:08 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73C31A0243 for ; Wed, 16 Apr 2014 09:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=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 jR7FLAHz1yKW for ; Wed, 16 Apr 2014 09:21:00 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8A53E1A0249 for ; Wed, 16 Apr 2014 09:20:59 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q108so11372002qgd.38 for ; Wed, 16 Apr 2014 09:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XYg7JNvqfptcj19n78yg/zPIcxv/f4C0NLJJoa2HgpI=; b=SjwcYYZCcpLGRzVv1fszlErFFLTnacdG5aUeB3WcgCsb6tGaE4N+MgBTTTot3BGjwx PZJd135JF86GbnIwI8aqoEyUMu3UV5b4phMZv39yBte0BTR3lIVt3iRhDzee6GY5iDkr WTa8y8Ru4DNBtmQg/Obo6canlBEhn+j28ehZ4/rxs4V7s0nhHKei1Lu8S8rD8X0dflGA euDesLRN2fhtuhIUV3IMio/hnGkl90g0lBI5ti/up53s9n4cWtASO3jO/OYUKI1jMttG tbpPAbvDilGDYX3dAoa3Ctp90CyHcUrB34O6xoCLlDC/VhaTEfm33saAHt3Sl7yGmfiO TwaQ== MIME-Version: 1.0 X-Received: by 10.224.67.131 with SMTP id r3mr4302146qai.75.1397665256091; Wed, 16 Apr 2014 09:20:56 -0700 (PDT) Received: by 10.229.2.66 with HTTP; Wed, 16 Apr 2014 09:20:55 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B13A243@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se> <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> <52DDCE70.1090707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se> <52DE7FE6.3000203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D193AE1@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B13A243@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Wed, 16 Apr 2014 18:20:55 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=001a11c3cefc1adf3704f72b4de0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/sdQ6PUvQer0ppA9XBKpKoRJoEsg Cc: Tom Kristensen , "bfcpbis@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:21:05 -0000 --001a11c3cefc1adf3704f72b4de0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fixed. Adopted Christer's initial text suggestion for this issue. Will appear in the upcoming version of the draft. -- Tom On 26 February 2014 18:17, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > (As WG cochair) > > I would rather not have a new draft on the table immediately before the > face to face meeting. > > I would suggest you briefly list it in the identified changes in your > presentation to the WG, and then produce the new draft immediately > following the face to face meeting. > > Keith > > ------------------------------ > *From:* bfcpbis [mailto:bfcpbis-bounces@ietf.org] *On Behalf Of *Tom > Kristensen > *Sent:* 26 February 2014 13:41 > *To:* Christer Holmberg > *Cc:* bfcpbis@ietf.org; Paul Kyzivat; Tom Kristensen > *Subject:* Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection > goes down and is re-established? > > Right. An internal short-circuit there... > I'll fix the wording as soon as the submission gate has opened, it is the > active TCP endpoint that is responsible for re-establishing. > > And yes this is the TCP layer and should not rely on roles on the TLS > level. > > -- Tom > > > On 16 February 2014 18:22, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi Tom, >> >> >> >> You say that, if the *TCP connection* is lost, then the TLS client is >> responsible for re-establishing it. Isn=E2=80=99t it the *active TCP end= point*that is responsible for re-establishing the *TCP >> connection*? >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *L=C3=A4hett=C3=A4j=C3=A4:* Tom Kristensen [mailto:2mkristensen@gmail.co= m] >> *L=C3=A4hetetty:* 14. helmikuuta 2014 18:22 >> *Vastaanottaja:* Christer Holmberg >> *Kopio:* bfcpbis@ietf.org; Paul Kyzivat; Tom Kristensen >> >> *Aihe:* Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection >> goes down and is re-established? >> >> >> >> FYI. The text included in the next version will be (Section 7, 3rd and >> 4th paragraphs): >> >> >> >> ---- >> >> Which party, the client or the floor control server, acts as the TLS/ >> >> DTLS server depends on how the underlying TLS/DTLS connection is >> >> established. For a TCP/TLS connection established using an SDP >> >> offer/answer exchange [7], the answerer (which may be the client or >> >> the floor control server) always acts as the TLS server. If the TCP >> >> connection is lost, the active endpoint, i.e., the current TLS >> >> client, is responsible for re-establishing the TCP connection. >> >> Unless a new TLS session is negotiated, subsequent SDP offers and >> >> answers will not impact the previously negotiated TLS roles. >> >> >> >> For a UDP/DTLS connection established using the an SDP offer/answer >> >> exchange, either party can be the DTLS server depending on the setup >> >> attributes exchanged; examples can be found in [22]. >> >> ---- >> >> >> >> I do hope that defines it correctly. >> >> >> >> -- Tom >> >> >> >> >> >> On 23 January 2014 11:48, Tom Kristensen <2mkristensen@gmail.com> wrote: >> >> Thanks Christer, not only did you discover the issue - you also provided >> the fix (and text for it). That solves what is currently missing in the >> draft and in RFC 4582. >> >> >> >> I will add your text, or at least a very similar version, to the upcomin= g >> version of the draft. >> >> >> >> -- Tom >> >> >> >> On 21 January 2014 15:10, Paul Kyzivat wrote: >> >> On 1/20/14 8:44 PM, Christer Holmberg wrote: >> >> Hi, >> >> Some initial text proposal: >> >> "If the TCP connection is lost, the "active" endpoint is responsible for >> re-establishing the TCP connection. >> >> Unless a new TLS session is negotiated, subsequent SDP Offers and Answer= s >> will not impact the previously negotiated TLS roles." >> >> >> Is the passive endpoint expected to listen for the connection attempt at >> all times, or when it has noticed that the old connection is lost, or on= ly >> when >> there has been a new O/A? (It is kind of a waste to maintain a listener >> when you have an active connection and aren't expecting more. >> And it is asking for trouble, since you might get a new connection when >> you think the old one is still functional.) >> >> >> If a TCP connection has been established, I think it is enough to listen >> for the connection when it has noticed that the old connection is lost. = I >> assume both endpoints would detect that more or less at the same time, o= r? >> >> If a TCP connection has NOT been established, one would listen only when >> there has been a O/A used to negotiate the TCP connection. >> >> >> >> WFM. >> >> >> >> I realize this is old stuff, but I'm surprised that it didn't follow >> comedia about all of this, including who is active. >> >> >> I am not sure I understand. Comedia IS used to indicate who is active. >> However, comedia is NOT used to indicate who is TLS client/server. >> >> >> >> OK. >> >> >> >> Regards, >> >> Christer >> >> >> >> -----Alkuper=C3=A4inen viesti----- >> L=C3=A4hett=C3=A4j=C3=A4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puol= esta Christer >> Holmberg >> L=C3=A4hetetty: 16. tammikuuta 2014 21:36 >> Vastaanottaja: Tom Kristensen >> Kopio: bfcpbis@ietf.org >> Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes >> down and is re-established? >> >> >> Hi Tom, >> >> I realize the following comes late in the process, and I apologize >> if it has been discussed, but it is related to something which just >> has recently popped up in 3GPP, and it's not addressed in the draft. >> >> >> Not too late, since we are still not finished! Anyway, the TCP/TLS >> connection reuse is not altered while extending BFCP to support >> unreliable transport. Any fixes now must be backwards compatible in >> some way. >> >> That said and based on what I have seen from different vendors, most >> of them still use TCP (without TLS) :) >> >> So, at least if we are changing anything to solve these issues, we >> should add an informational note indicating this is a change where >> legacy, pure RFC 4582 implementations might differ in behaviour... >> >> >> I am not suggesting to change anything - I am suggesting to specify >> something which is currently unspecified :) >> >> By the way: How these issues was solved in 3GPP are along the lines of >> what you propose below? >> >> >> We have had some discussions in 3GPP, and there are some text suggestion= s >> for the upcoming meeting next week. >> >> However, the discussions so far have been mostly about Q2. Q1 came up on >> a mailing list just this week, and whill be discussed at the 3GPP meetin= g >> next week. >> >> Section 7 says the following: >> >> "For a TCP/TLS connection established using an SDP >> >> offer/answer exchange [7], the answerer (which may be the client or >> >> the floor control server) always acts as the TLS server." >> >> Q1: >> >> Assume the TCP/TLS connection, for whatever reason, goes down. >> >> Now, I assume that whoever endpoint is "active" will most likely try >> to re-establish the TCP connection. >> >> But, if the "active" endpoint doesn't send an Offer (i.e. it simply >> tries to re-establish the TCP connection based on the previously >> negotiated SDP information), who will act as TLS server? There is no >> Answerer. >> >> One alternative would be to mandate the sending of an Offer when the >> TCP/TLS connection is re-established. Then it would be clear who is >> Offerer, and who is Answerer. >> >> Another alternative would be to say that whoever was previously >> Answerer will act as TLS server. >> >> >> I'm not too fond of yet another re-INVITE being mandated, so if we >> will fix this issue mandating the previous answerer to be the TLS >> server would be my preference. >> >> >> Assuming that, then my follow-up question is: >> >> When you say "previous answerer", do you refer to the answerer in the >> latest Offer/Answer transaction, OR the answerer in the last Offer/Answe= r >> transaction that established/re-established the TCP/TLS connection (thos= e >> Offer/Answer transactions may, or may not, be the same). >> >> Q2: >> >> Assume there is an Offer/Answer transaction during the session. Now, >> the TCP/TLS connection is not affected by that, but the TLS roles >> may change (if whoever was Offerer in the previous O/A transaction is no= w >> Answerer). >> >> I think some wording would be needed about that also. >> >> One alternative is to say that the TLS roles may change, but that >> doesn't affect the TCP/TLS connection. >> >> >> A healthy TCP/TLS connection shouldn't be affected at all, should it? >> >> >> Correct. The question is whether such Offer/Answer can affect the TCP/TL= S >> roles - even if the TCP/TLS connection itself if not affected. That coul= d >> have impact on the case in Q1, where the TCP/TLC connection goes down, a= nd >> it needs to be determined who is TLS server. >> >> However, any potential connection re-establishment will need to >> monitor who was the last answerer to do the TLS initiation correctly. >> >> Hopefully I did understand the issue here, and added my 2 zlotys or >> pence or whatever, >> >> >> I think you did understand the issue :) >> >> Regards, >> >> Christer >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> >> >> >> >> >> -- >> # Cisco | http://www.cisco.com/telepresence/ >> ## tomkrist@cisco.com | http://www.tandberg.com >> ### | http://folk.uio.no/tomkri/ >> >> >> >> >> >> -- >> # Cisco | http://www.cisco.com/telepresence/ >> ## tomkrist@cisco.com | http://www.tandberg.com >> ### | http://folk.uio.no/tomkri/ >> > > > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a11c3cefc1adf3704f72b4de0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fixed. Adopted Christer's initial text suggestion for = this issue. Will appear in the upcoming version of the draft.

-- Tom


On 26 February 2014 18:17, DRAGE, Keith (Keith) <keith.drage@= alcatel-lucent.com> wrote:
(As WG cochair)
=C2=A0
I would rather not have a new draft on the table immediately before the f= ace to face meeting.
=C2=A0
I would suggest you briefly list it in the identified changes in your pre= sentation to the WG, and then produce the new draft immediately following t= he face to face meeting.
=C2=A0
Keith

From: bfcpbis [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Tom Kristensen
Sent: 26 February 2014 13:41
To: Christer Holmberg
Cc: bfcpbis@ie= tf.org; Paul Kyzivat; Tom Kristensen
Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connectio= n goes down and is re-established?

Right. An internal short-circuit there...
I'll fix the wording as soon as the submission gate has opened, it= is the active TCP endpoint that is responsible for re-establishing.=C2=A0<= /div>

And yes this is the TCP layer and should not rely on roles on the TLS = level.

-- Tom


On 16 February 2014 18:22, Christer Holmberg <chr= ister.holmberg@ericsson.com> wrote:

Hi Tom,

=C2=A0

You say that, if= the TCP connection is lost, then the TLS client is responsible for re-es= tablishing it. Isn=E2=80=99t it the active TCP endpoint that is responsible for re-establishing the T= CP connection?

=C2=A0

Regards,<= u>

=C2=A0

Christer<= u>

=C2=A0

L=C3=A4hett=C3=A4j=C3=A4: = Tom Kristensen [mailto:2mkristensen@gmail.com]
L=C3=A4hetetty: 14. helmikuuta 2014 18:22
Vastaanottaja: Christer Holmberg
Kopio: bfcpbis= @ietf.org; Paul Kyzivat; Tom Kristensen


Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection g= oes down and is re-established?

=C2=A0

FYI. The text included in the next version will be (= Section 7, 3rd and 4th paragraphs):

=C2=A0

----

=C2=A0Which party, the client or the floor control s= erver, acts as the TLS/

=C2=A0 =C2=A0DTLS server depends on how the underlyi= ng TLS/DTLS connection is

=C2=A0 =C2=A0established. =C2=A0For a TCP/TLS connec= tion established using an SDP

=C2=A0 =C2=A0offer/answer exchange [7], the answerer= (which may be the client or

=C2=A0 =C2=A0the floor control server) always acts a= s the TLS server. =C2=A0If the TCP

=C2=A0 =C2=A0connection is lost, the active endpoint= , i.e., the current TLS

=C2=A0 =C2=A0client, is responsible for re-establish= ing the TCP connection.

=C2=A0 =C2=A0Unless a new TLS session is negotiated,= subsequent SDP offers and

=C2=A0 =C2=A0answers will not impact the previously = negotiated TLS roles.

=C2=A0

=C2=A0 =C2=A0For a UDP/DTLS connection established u= sing the an SDP offer/answer

=C2=A0 =C2=A0exchange, either party can be the DTLS = server depending on the setup

=C2=A0 =C2=A0attributes exchanged; examples can be f= ound in [22].

----

=C2=A0

I do hope that defines it correctly.

=C2=A0

-- Tom

=C2=A0

=C2=A0

On 23 January 2014 11:48, Tom Kristensen <2mkristensen@gmail.com= > wrote:

Thanks Christer, not only did you discover the issue= - you also provided the fix (and text for it). That solves what is current= ly missing in the draft and in RFC 4582.

=C2=A0

I will add your text, or at least a very similar ver= sion, to the upcoming version of the draft.

=C2=A0

-- Tom

=C2=A0

On 21 January 2014 15:10, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 1/20/14 8:44 PM, Christer Holmberg wrote:<= u>

Hi,

Some initial text proposal:

"If the TCP connection is lost, the "active" endpoint is res= ponsible for re-establishing the TCP connection.

Unless a new TLS session is negotiated, subsequent SDP Offers and Answers w= ill not impact the previously negotiated TLS roles."


Is the passive endpoint expected to listen for the connection attempt at al= l times, or when it has noticed that the old connection is lost, or only wh= en
there has been a new O/A? (It is kind of a waste to maintain a listener whe= n you have an active connection and aren't expecting more.
And it is asking for trouble, since you might get a new connection when you= think the old one is still functional.)


If a TCP connection has been established, I think it is enough to listen fo= r the connection when it has noticed that the old connection is lost. I ass= ume both endpoints would detect that more or less at the same time, or?

If a TCP connection has NOT been established, one would listen only when th= ere has been a O/A used to negotiate the TCP connection.

=C2=A0

WFM.

=C2=A0

I realize this is old stuff, but I'm surprised t= hat it didn't follow comedia about all of this, including who is active= .


I am not sure I understand. Comedia IS used to indicate who is active. Howe= ver, comedia is NOT used to indicate who is TLS client/server.

=C2=A0

OK.

=C2=A0

Regards,

Christer



-----Alkuper=C3=A4inen = viesti-----
L=C3=A4hett=C3=A4j=C3=A4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christe= r
Holmberg
L=C3=A4hetetty: 16. tammikuuta 2014 21:36
Vastaanottaja: Tom Kristensen
Kopio: bfcpbis@ietf.o= rg
Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes dow= n and is re-established?


Hi Tom,

I realize the following comes late in the process, a= nd I apologize
if it has been discussed, but it is related to something which just
has recently popped up in 3GPP, and it's not addressed in the draft.=


Not too late, since we are still not finished! Anyway, the TCP/TLS
connection reuse is not altered while extending BFCP to support
unreliable transport. Any fixes now must be backwards compatible in
some way.

That said and based on what I have seen from different vendors, most
of them still use TCP (without TLS) :)

So, at least if we are changing anything to solve these issues, we
should add an informational note indicating this is a change where
legacy, pure RFC 4582 implementations might differ in behaviour...


I am not suggesting to change anything - I am suggesting to specify
something which is currently unspecified :)

By the way: How these issues was solved in 3GPP are = along the lines of what you propose below?


We have had some discussions in 3GPP, and there are some text suggestions f= or the upcoming meeting next week.

However, the discussions so far have been mostly about Q2. Q1 came up on a = mailing list just this week, and whill be discussed at the 3GPP meeting nex= t week.

Section 7 says the following:

"For a TCP/TLS connection established using an SDP

offer/answer exchange [7], the answerer (which may be the client or

the floor control server) always acts as the TLS server."

Q1:

Assume the TCP/TLS connection, for whatever reason, goes down.

Now, I assume that whoever endpoint is "active" will most likely = try
to re-establish the TCP connection.

But, if the "active" endpoint doesn't send an Offer (i.e. it = simply
tries to re-establish the TCP connection based on the previously
negotiated SDP information), who will act as TLS server? There is no
Answerer.

One alternative would be to mandate the sending of an Offer when the
TCP/TLS connection is re-established. Then it would be clear who is
Offerer, and who is Answerer.

Another alternative would be to say that whoever was previously
Answerer will act as TLS server.


I'm not too fond of yet another re-INVITE being mandated, so if we
will fix this issue mandating the previous answerer to be the TLS
server would be my preference.


Assuming that, then my follow-up question is:

When you say "previous answerer", do you refer to the answerer in= the latest Offer/Answer transaction, OR the answerer in the last Offer/Ans= wer transaction that established/re-established the TCP/TLS connection (tho= se Offer/Answer transactions may, or may not, be the same).

Q2:

Assume there is an Offer/Answer transaction during the session. Now,
the TCP/TLS connection is not affected by that, but the TLS roles
may change (if whoever was Offerer in the previous O/A transaction is now A= nswerer).

I think some wording would be needed about that also.

One alternative is to say that the TLS roles may change, but that
doesn't affect the TCP/TLS connection.


A healthy TCP/TLS connection shouldn't be affected at all, should it?


Correct. The question is whether such Offer/Answer can affect the TCP/TLS r= oles - even if the TCP/TLS connection itself if not affected. That could ha= ve impact on the case in Q1, where the TCP/TLC connection goes down, and it= needs to be determined who is TLS server.

However, any potential connection re-establishment w= ill need to
monitor who was the last answerer to do the TLS initiation correctly.

Hopefully I did understand the issue here, and added my 2 zlotys or
pence or whatever,


I think you did understand the issue :)

Regards,

Christer

_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis
_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis



=C2=A0

--
# Cisco =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@c= isco.com =C2=A0| =C2=A0http://www.tandberg.com
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/



=C2=A0

--
# Cisco =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om =C2=A0| =C2=A0= http://www.tandberg.com
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/




--
# Cisco =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om =C2=A0| =C2=A0= http://www.tandberg.com
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/



--
# Cisco =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.com =C2=A0| =C2=A0http://www.tandberg.com<= br> ### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/
--001a11c3cefc1adf3704f72b4de0-- From nobody Wed Apr 16 09:29:20 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B061A0176 for ; Wed, 16 Apr 2014 09:29:19 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_4c5O-v0KSG for ; Wed, 16 Apr 2014 09:29:14 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 963451A0135 for ; Wed, 16 Apr 2014 09:29:14 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so12419464qcx.10 for ; Wed, 16 Apr 2014 09:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rm8lw4HEJ7FT+iEUfLLuSHwo4DRycl5MWoBdTZInsG0=; b=0cM/pOCzSAhpfbdNIILkYCNimpT/nU5PkoUF6uPAhTCNZpUZGiKFt0Ekt76zN8RHn9 3A6A+tPWmr4KbnPLxEXnM1OCQt9wgVWjhkmpyljp/5PuOgoQwj+bF0WUe0+Kj7lRxnL/ S2YWAPloa7aOvTTwBVG7ejvUVZPJbgaD366w80qc5eRCSX76y8YzUDfeq9hMVSmmGsXF ZJfQMtV7wmi8Iul5SzeambLk5mqnacjBk5oMDaKIae6BgBkj2LT7t2tffnYb4EgJQE/w gcefrdxtw8vLuVFSUwAzzlN/hcND8tQ5Jqq0ZsManJmXHXBG5D6jvejufLyth3IgMg2Z p4mA== MIME-Version: 1.0 X-Received: by 10.140.102.135 with SMTP id w7mr10873857qge.29.1397665751177; Wed, 16 Apr 2014 09:29:11 -0700 (PDT) Received: by 10.229.2.66 with HTTP; Wed, 16 Apr 2014 09:29:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Apr 2014 18:29:11 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a11c172149d1e2f04f72b6ad0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/b-JiEvtQJgGsHKGvxXysjffql0Y Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] call for comments on draft-ietf-bfcpbis-rfc4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:29:19 -0000 --001a11c172149d1e2f04f72b6ad0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Always good to have a native speaker polishing the text. The changes is adopted and will be part of the next version. For the last issue, in Section 13, the following text is used: "Language clarifications as a result of reviews. Also, the normative language where tightened where appropriate, i.e. changed from SHOULD strength to MUST in a number of places." -- Tom On 19 March 2014 23:27, Charles Eckel (eckelcu) wrote: > (as an individual) > > I read through the draft in detail. It addresses all the concerns I raise= d > previously. > I would to suggest a few additional changes. These are mostly editorial. > > Section 1 > s/This data include/This data includes > > Section 7 > s/and, when acting as a floor control server to use/and, when acting as a > floor control server, to use > > Section 8 > s/will direct the BFCP messages/direct the BFCP messages > > Section 9 > s/How to determine which endpoint to initiate/How to determine which > endpoint initiates > > Section 13 > I=C2=B9m not sure what "Non-functional language clarifications=C2=B2 are,= but I > don=C2=B9t think we want them in the draft :) > Perhaps replace with =C2=B3Non-normative language clarifications=C2=B2? > > > > Cheers, > Charles > > > > On 3/4/14, 3:06 PM, "Charles Eckel (eckelcu)" wrote: > > >As discussed in the session today at IETF 89, this is to officially > >announce a 2-week call for comments on draft-ietf-bfcpbis-rfc4583bis-09 > >(http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-09), due by or > >before March 19, 2014. > >If the draft is perfect as is, please share that comment on the list as > >well. > > > >Thank you, > >Charles > > > > > >_______________________________________________ > >bfcpbis mailing list > >bfcpbis@ietf.org > >https://www.ietf.org/mailman/listinfo/bfcpbis > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a11c172149d1e2f04f72b6ad0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Always good to have a native speaker polishing the text. T= he changes is adopted and will be part of the next version.

<= div style>For the last issue, in Section 13, the following text is used:=C2= =A0

=C2=A0 =C2=A0"Language clarifications = as a result of reviews. Also, the normative language where tightened where = appropriate, i.e. changed from SHOULD strength to MUST in a number of place= s."

-- Tom


On 19 March 2014 23:27, Charles Eckel = (eckelcu) <eckelcu@cisco.com> wrote:
(as an individual)

I read through the draft in detail. It addresses all the concerns I raised<= br> previously.
I would to suggest a few additional changes. These are mostly editorial.
Section 1
s/This data include/This data includes

Section 7
s/and, when acting as a floor control server to use/and, when acting as a floor control server, to use

Section 8
s/will direct the BFCP messages/direct the BFCP messages

Section 9
s/How to determine which endpoint to initiate/How to determine which
endpoint initiates

Section 13
I=C2=B9m not sure what "Non-functional language clarifications=C2=B2 a= re, but I
don=C2=B9t think we want them in the draft :)
Perhaps replace with =C2=B3Non-normative language clarifications=C2=B2?



Cheers,
Charles



On 3/4/14, 3:06 PM, "Charles Eckel (eckelcu)" <eckelcu@cisco.com> wrote:

>As discussed in the session today at IETF 89, this is to officially
>announce a 2-week call for comments on draft-ietf-bfcpbis-rfc4583bis-09=
>(http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bi= s-09), due by or
>before March 19, 2014.
>If the draft is perfect as is, please share that comment on the list as=
>well.
>
>Thank you,
>Charles
>
>
>_______________________________________________
>bfcpbis mailing list
>bfcpbis@ietf.org
>https://www.ietf.org/mailman/listinfo/bfcpbis

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



--
# Cisco =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.com =C2=A0| =C2=A0http://www.tandberg.com<= br> ### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/
--001a11c172149d1e2f04f72b6ad0-- From nobody Wed Apr 16 09:44:53 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679E81A0243 for ; Wed, 16 Apr 2014 09:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C08eTE2iMHKe for ; Wed, 16 Apr 2014 09:44:46 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 432991A01F2 for ; Wed, 16 Apr 2014 09:44:46 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id m5so8842580qaj.20 for ; Wed, 16 Apr 2014 09:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jfFJVgVJWithzzes8vrjua1WSThWLvKVP3lJZSCTzGE=; b=xbJoDEiSGDHqxCx7sAbhfpi+zh5uVFeLh8ptFiryI+CInK9Wjc97CPa/km/88eQeYB 5qLGzPTwTL4Bt+lP7d+XTLmv+1sI1EwZlbui1ADmHZ9nZdWUogohTmqyv1T+5WdgamTG wkbxqXxqmeml0BX7Pbcr9OwekEz0lu/MjfJ6mO9OyWGOVkNZyoarZRgrZZCoZcxjoRO6 Q/VD+z9DtGZ/06oJeO9NLLjgpPzm04NLlc1ojjy+AOOpHm2efhyUft9C9+jGQJkEOYsO 4tNxCIqhlpyoA1n8LE1LvOJ6uu6uIzByrtb8yB9xM7g7nd2BhWYhNFFwdkmDoIRod36W cYhQ== MIME-Version: 1.0 X-Received: by 10.224.13.76 with SMTP id b12mr6430977qaa.34.1397666682747; Wed, 16 Apr 2014 09:44:42 -0700 (PDT) Received: by 10.229.2.66 with HTTP; Wed, 16 Apr 2014 09:44:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Apr 2014 18:44:42 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=047d7bdc831c23f40904f72ba285 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/6fW2XDkShQxYSiqB3e-EvzDEbW4 Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] call for comments on draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:44:51 -0000 --047d7bdc831c23f40904f72ba285 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Charles! Also for this draft, a native English speaker and writer is very much appreciated. All issues fixed accordingly to the suggestions. -- Tom On 19 March 2014 23:27, Charles Eckel (eckelcu) wrote: > (as an individual) > > I read through the draft in detail. It addresses all the concerns I raise= d > previously. > In addition to the TCP/TLS clarifications requested by Christer, I sugges= t > the following changes. These are mostly editorial. > > Section 5.3.17: > s/should acknowledge/acknowledge > I think it is best to drop the =C2=B3should=C2=B2 to avoid confusion with= normative > statements. This is also more consistent with the rest of the message > descriptions in this section. Normative language regarding the sending of > request/response messages is specified elsewhere. > > Section 6: Transport > I suggest rewording the information note as follows: > OLD: > Informational note: In practice products are configured to try one > transport initially and use the other one as a fallback. > Whether > TCP or UDP is chosen as underlying transport depends on type > of > product and the nature of the environment it is deployed. > Here > Appendix B are important to consider. > > NEW: > Informational note: In practice, products are configured to try one > transport first and use the other transport as a fallback. > Whether > TCP or UDP is chosen as the underlying transport depends on > the type of > product and the deployment environment. See Appendix B for > additional > considerations. > > > Section 6.2 > s/Situations =C5=A0 is described/Situations =C5=A0 are described > > Section 8 > s/all requests will use retransmission timer T1/retransmission timer T1 > MUST be used for all requests > > Section 8.2 > s/valuse/values > > Section 16.2 > s/The clarification and bug fixes/Clarifications and bug fixes > > > I=C2=B9m not sure what "Non-functional language clarifications=C2=B2 are,= but I > don=C2=B9t think we want them in the draft :) > Perhaps replace with =C2=B3Non-normative language clarifications=C2=B2? > > > Cheers, > Charles > > > On 3/4/14, 3:06 PM, "Charles Eckel (eckelcu)" wrote: > > >As discussed in the session today at IETF 89, this is to officially > >announce a 2-week call for comments on draft-ietf-bfcpbis-rfc4582bis-11 > >(http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-11), due by or > >before March 19, 2014. > >If the draft is perfect as is, please share that comment on the list as > >well. > > > >Thank you, > >Charles > > > > > >_______________________________________________ > >bfcpbis mailing list > >bfcpbis@ietf.org > >https://www.ietf.org/mailman/listinfo/bfcpbis > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --047d7bdc831c23f40904f72ba285 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Charles!

Also for this draft, a= native English speaker and writer is very much appreciated. All issues fix= ed accordingly to the suggestions.=C2=A0

-- = Tom


On 19 M= arch 2014 23:27, Charles Eckel (eckelcu) <eckelcu@cisco.com>= wrote:
(as an individual)

I read through the draft in detail. It addresses all the concerns I raised<= br> previously.
In addition to the TCP/TLS clarifications requested by Christer, I suggest<= br> the following changes. These are mostly editorial.

Section 5.3.17:
s/should acknowledge/acknowledge
I think it is best to drop the =C2=B3should=C2=B2 to avoid confusion with n= ormative
statements. This is also more consistent with the rest of the message
descriptions in this section. Normative language regarding the sending of request/response messages is specified elsewhere.

Section 6: Transport
I suggest rewording the information note as follows:
OLD:
Informational note: In practice products are configured to try one
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transport initially and use= the other one as a fallback.
Whether
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TCP or UDP is chosen as und= erlying transport depends on type
of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0product and the nature of t= he environment it is deployed.
Here
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix B are important to= consider.

NEW:
Informational note: In practice, products are configured to try one
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transport first and use the= other transport as a fallback.
Whether
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TCP or UDP is chosen as the= underlying transport depends on
the type of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0product and the deployment = environment. See Appendix B for
additional
considerations.


Section 6.2
s/Situations =C5=A0 is described/Situations =C5=A0 are described

Section 8
s/all requests will use retransmission timer T1/retransmission timer T1
MUST be used for all requests

Section 8.2
s/valuse/values

Section 16.2
s/The clarification and bug fixes/Clarifications and bug fixes


I=C2=B9m not sure what "Non-functional language clarifications=C2=B2 a= re, but I
don=C2=B9t think we want them in the draft :)
Perhaps replace with =C2=B3Non-normative language clarifications=C2=B2?


Cheers,
Charles


On 3/4/14, 3:06 PM, "Charles Eckel (eckelcu)" <eckelcu@cisco.com> wrote:

>As discussed in the session today at IETF 89, this is to officially
>announce a 2-week call for comments on draft-ietf-bfcpbis-rfc4582bis-11=
>(http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bi= s-11), due by or
>before March 19, 2014.
>If the draft is perfect as is, please share that comment on the list as=
>well.
>
>Thank you,
>Charles
>
>
>_______________________________________________
>bfcpbis mailing list
>bfcpbis@ietf.org
>https://www.ietf.org/mailman/listinfo/bfcpbis

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



--
# Cisco =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.com =C2=A0| =C2=A0http://www.tandberg.com<= br> ### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/
--047d7bdc831c23f40904f72ba285-- From nobody Wed Apr 16 09:46:14 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD25F1A019B for ; Wed, 16 Apr 2014 09:46:13 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVPjHYcWwahC for ; Wed, 16 Apr 2014 09:46:09 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 41B261A0270 for ; Wed, 16 Apr 2014 09:46:08 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so3701373qgf.7 for ; Wed, 16 Apr 2014 09:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nUA8vZ12NR3Eoi4l8oiy37cUlOKYeFwXavgfWQ1tPZk=; b=Yq6Ghu8KEvZpcMoZ59FuAFnXSJoqK9GVmowl/iR142e8OhEGgmm+H3NG6PYPMgJPXd IZkrf+WQgzJjGlTUAqpUJRD8fRJBFq+v32xFsXgam9Obu/1wJDRxEEYWLHN8Su1TV5+p XlmHTu23hPKaZQNDACYAvTARg8aYqO0wuFg1JacEEiby/QMPpe9JEzmEK7M8wf6HjAQp FV1M7pyE64fkjvqHmKgZonKnU1XXGCX3tLSC61htB0aEIUatazI3ksL1B6qt3MCgOoGP 0A4wOSXmd80Dqsna8bgNjK5IIIKz4Kqk6tsqqV70yD/auUMPfe3WZ/nosA+aVgji6BPi n1jQ== MIME-Version: 1.0 X-Received: by 10.140.108.2 with SMTP id i2mr4499700qgf.80.1397666764820; Wed, 16 Apr 2014 09:46:04 -0700 (PDT) Received: by 10.229.2.66 with HTTP; Wed, 16 Apr 2014 09:46:04 -0700 (PDT) In-Reply-To: <53427849.4000704@ericsson.com> References: <534249FF.9010008@ericsson.com> <534277C8.1010003@cisco.com> <53427849.4000704@ericsson.com> Date: Wed, 16 Apr 2014 18:46:04 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=001a113ab74a08181504f72ba7d8 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/uxxZc2gxnKgTKtZBSUWKT17h7vs Cc: "bfcpbis@ietf.org" , Tom Kristensen Subject: Re: [bfcpbis] Progressing 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:46:14 -0000 --001a113ab74a08181504f72ba7d8 Content-Type: text/plain; charset=UTF-8 And for the record, I did go through the diff between the currently published version (fresh for the London IETF) and the one before to make sure the issues raised on the mailing list were addressed and fixed. I do believe that is true. -- Tom On 7 April 2014 12:04, Gonzalo Camarillo wrote: > Thanks for the quick response, Tom. > > Cheers, > > Gonzalo > > On 07/04/2014 1:02 PM, Tom Kristensen wrote: > > Comments from Charles was fine and is fixed, will respond to list. > > > > I'm currently trying to figure out how to cope with Christer's input and > > issues, will respond to list for that as well. > > > > The time plan should be fixing immediately, so any delay is very much > > unfortunate :( I agree. > > > > -- Tom > > > > On 04/07/2014 08:47 AM, Gonzalo Camarillo wrote: > >> Hi, > >> the call for comments on 4582bis and 4583bis is over. I have not seen > >> any response to the comments Charles sent a couple of weeks ago. > >> Additionally, Christer has also sent some comments. > >> > >> What is the time plan to progress these drafts? > >> > >> Thanks, > >> > >> Gonzalo > >> > >> _______________________________________________ > >> bfcpbis mailing list > >> bfcpbis@ietf.org > >> https://www.ietf.org/mailman/listinfo/bfcpbis > >> > > > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a113ab74a08181504f72ba7d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And for the record, I did go through the diff between the = currently published version (fresh for the London IETF) and the one before = to make sure the issues raised on the mailing list were addressed and fixed= . I do believe that is true.

-- Tom


<= div class=3D"gmail_quote">On 7 April 2014 12:04, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> wrote:
Thanks for the quick response, Tom.

Cheers,

Gonzalo

On 07/04/2014 1:02 PM, Tom Kristensen wrote:
> Comments from Charles was fine and is fixed, will respond to list.
>
> I'm currently trying to figure out how to cope with Christer's= input and
> issues, will respond to list for that as well.
>
> The time plan should be fixing immediately, so any delay is very much<= br> > unfortunate :( I agree.
>
> -- Tom
>
> On 04/07/2014 08:47 AM, Gonzalo Camarillo wrote:
>> Hi,
>> the call for comments on 4582bis and 4583bis is over. I have not s= een
>> any response to the comments Charles sent a couple of weeks ago. >> Additionally, Christer has also sent some comments.
>>
>> What is the time plan to progress these drafts?
>>
>> Thanks,
>>
>> Gonzalo
>>
>> _______________________________________________
>> bfcpbis mailing list
>> bfcpbis@ietf.org
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>
>

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



--
= # Cisco =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.com =C2=A0| = =C2=A0http://www.tand= berg.com
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/ --001a113ab74a08181504f72ba7d8-- From nobody Wed Apr 16 10:05:15 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1C91A028E for ; Wed, 16 Apr 2014 10:05:12 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDidbwk6rs_O for ; Wed, 16 Apr 2014 10:05:07 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3401A01DF for ; Wed, 16 Apr 2014 10:05:07 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so3752523qgf.35 for ; Wed, 16 Apr 2014 10:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Og+IIrYHoglU0iP4COF9zyPY/AWsM7dyzWwNfOe+Tqg=; b=Fxr/NaZV4sWEtrX/iBV3YWmIN9+D5LiRZPsNkCHjYwSvTH+CJm8K/TB1PaLeb7PVtA AKZOMfIeeZs/2GdzNX/xutYrFqskgmjYSsSPmC8s+2swXlsdDv3f02GFhm8y+Au70s7B XjhjgCw5YitYdYCFyoKFaAgVwDLBd8Babvi9TtueqYFnowmpkXEkD0p4Dtk+C3PjPe0U z9ZC7Ey0Ml55A0ipN+kH5OLXecbqr0qtcgmC0/C7fyrxJqHR3bAF/xeq08qRslQUHeHM OQ3VXO8T9c9/kUVc9f4uHM0Sy6HCcgQhvt9aO4zNWZOtUQ70/TOOUw782upZJ1un9a34 CG/g== MIME-Version: 1.0 X-Received: by 10.224.22.195 with SMTP id o3mr4627524qab.51.1397667904161; Wed, 16 Apr 2014 10:05:04 -0700 (PDT) Received: by 10.229.2.66 with HTTP; Wed, 16 Apr 2014 10:05:04 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D26AD60@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D26AD25@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D26AD60@ESESSMB209.ericsson.se> Date: Wed, 16 Apr 2014 19:05:04 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b5da5bbf13f8d04f72beacc Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/Mw9Vfs9LNcGcvhDkBF_CrSMLlLc Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , Tom Kristensen Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:05:13 -0000 --047d7b5da5bbf13f8d04f72beacc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm starting with addressing this last issue first: RFC 4583 has lived fine for some years and do have a number of interoperable implementations out there. This happened without structuring the O/A procedures using RFC 3264 as a blueprint as was suggested for Christer's draft in MMUSIC. Additinally, this issue never raised during SDP directorate review. I propose we do not restructure rfc4583bis this way. -- Tom On 29 March 2014 12:44, Christer Holmberg w= rote: > Hi, > > > > Another thing. > > > > As part of the WGLC for one of my draft in MMUSIC, I received comments > that the SDP O/A procedures should be structured according to RFC 3264, i= e > =E2=80=9CSending of initial offer=E2=80=9D, =E2=80=9CModifying session=E2= =80=9D, =E2=80=9CProcessing of answer=E2=80=9D etc. > > > > Eventhough this is not MMUSIC, you may want to consider doing the same J > > > > Regards, > > > > Christer > > > > > > > > > > *From:* bfcpbis [mailto:bfcpbis-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 29 March 2014 13:41 > *To:* Charles Eckel (eckelcu) > > *Cc:* bfcpbis@ietf.org > *Subject:* Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and > 4583bis > > > > Hi Charles, > > > > Without commenting on specifics at this point, I really think we should > try to get the SDP Offer/Answer procedures into one place (4583bis). > > > > 4582bis can define actions taken by the DTLS client and server, but shoul= d > not define how those roles are determined. 4583bis then defines how the > roles are determined when using SDP O/A. > > > > Regards, > > > > Christer > > > > *From:* Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > *Sent:* 27 March 2014 01:11 > *To:* Christer Holmberg > *Cc:* bfcpbis@ietf.org > *Subject:* Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and > 4583bis > > > > Hi Christer, > > > > Thanks for your comments. The more I looked into them the more complex an= d > tangled things became. Let me try to walk through the current state of > affairs and then propose a potential solutions. > > > > RFC 4582 breaks connection establishment into two cases: > > 1. when SDP offer/answer IS NOT used > 2. when SDP offer/answer IS used > > For (1), RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 > adds a reference to RFC 5239 for XCON. > > RFC 5018 deals with the connection establishment, reestablishment, and > TLS usage. > > RFC 5239 points back to RFC 5018 for connection establishment. > > RFC 5018 does not deal with DTLS. Unless we restrict DTLS to cases in > which SDP offer/answer is used, we need to update RFC 5018 to deal with > DTLS. Someone please tell me otherwise. > > > > Section 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend > RFC 5018 when dealing with BFCP over UDP or DTLS. I think this should be > relocated to an update to RFC 5018, and connection reestablishment should > be described as well. > > > > For (2), RFC 4582 provides a teaser but points to RFC 4583 for the > normative language. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to > draft-ietf-bfcpbis-rfc4583bis-09. Christer comments are in regard to > inconsistencies here. I provided comments on those inline. > > > > *From: *Christer Holmberg > *Date: *Tuesday, March 25, 2014 at 12:39 PM > *To: *"bfcpbis@ietf.org" > *Subject: *[bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis > > > > Hi, > > > > Section 7 in 4582bis, which says: > > > > =E2=80=9C7. Lower-Layer Security > > > > BFCP relies on lower-layer security mechanisms to provide replay and > > integrity protection and confidentiality. BFCP floor control servers > > and clients (which include both floor participants and floor chairs) > > > > MUST support TLS for transport over TCP [6] and MUST support DTLS [7] > > for transport over UDP. Any BFCP entity MAY support other security > > mechanisms. > > > > BFCP entities MUST support, at a minimum, the > > TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. > > > > Which party, the client or the floor control server, acts as the TLS/ > > DTLS server depends on how the underlying TLS/DTLS connection is > > established. For a TCP/TLS connection established using an SDP > > offer/answer exchange [9], the answerer (which may be the client or > > the floor control server) always acts as the TLS server. If the TCP > > connection is lost, the active endpoint, i.e., the current TLS > > client, is responsible for re-establishing the TCP connection. > > Unless a new TLS session is negotiated, subsequent SDP offers and > > answers will not impact the previously negotiated TLS roles. > > > > For a UDP/DTLS connection established using the an SDP offer/answer > > exchange, either party can be the DTLS server depending on the setup > > attributes exchanged; examples can be found in [23].=E2=80=9D > > > > *First*, we already earlier discussed that the active TCP endpoint is > responsible for re-establishing the TCP connection, and that will be > corrected in the next version of the draft. > > > > Yes. > > > > > > However, we have discussed a similar topic in CLUE, and we were wondering > whether it would be good that, whoever detects a connection failure, send= s > a new offer in order to re-establish the connection. It does not matter i= f > both endpoints send an offer =E2=80=93 the offer/answer race condition ru= les will > take care of that. > > > > In CLUE, is this for a TCP/TLS connection, or for a DTLS connection? > > For DTLS, we specifically chose to alter the behavior, as described in > section 9.1 of 4583bis: > > > > "Endpoints that use the offer/answer model to establish a DTLS > > association MUST support the 'setup' attribute, as defined in [7]. > > When DTLS is used with UDP, the 'setup' attribute indicates which of > > the endpoints (client or floor control server) initiates the DTLS > > association setup. The requirements for the offer/answer exchange > > specified in [13], Section 5 MUST be followed when using DTLS. > > > > Informational note: How to determine which endpoint to initiate > > the TLS/DTLS association depends on the selected underlying > > transport. It was decided to keep the original semantics in [15] > > for TCP to retain backwards compatibility. When using UDP, the > > procedure above was preferred since it adheres to [13] as used for > > DTLS-SRTP, it does not overload offer/answer semantics, and it > > works for offerless INVITE in scenarios with B2BUAs." > > > > > > > > > > *Second*, Section 8.1 in 4583bis says: > > > > =E2=80=9CWhen the existing TCP connection is reset following the rules= in [8], > > the client MUST generate an offer towards the floor control server in > > order to reestablish the connection. If a TCP connection cannot > > deliver a BFCP message and times out, the entity that attempted to > > send the message (i.e., the one that detected the TCP timeout) MUST > > generate an offer in order to reestablish the TCP connection.=E2=80=9D > > > > > > I am not sure what is meant by =E2=80=9CTCP connection is reset following= the > rules in [8]=E2=80=9D. Which rules are you referring to? > > > > Reset means closed and reestablished. The word =E2=80=9Creset=E2=80=9D wa= s used in RFC > 4582 and reused in 4582bis. Perhaps we should change it closed and > reestablished to avoid confusion? > > > > > > Then, the text says that the client always re-established the TCP > connection. Is that aligned with the text in 4582bis, saying that the > active party does the reestablishment? Is the client always active? > > > > I think it is a little confusing that both 4582bis and 4583bis defines SD= P > Offer/Answer procedures. Shouldn=E2=80=99t they only be in 4583bis? > > > > Yes, I think so. RFC 4582 mixed some SDP offer/answer text into its > section on lower layer security, and 4582bis followed suit. It would be > better to have all the details of connection establishment and > reestablishment in when using SDP offer/answer in 4583bis. > > > > > > > > > > *Third*, the last paragraph, talking about UDP/DTLS, says that either > party can be DTLS server depending on the setup attributes exchanged. But= , > nowhere is it described how the setup attribute is used to determine the > DTLS server role J > > > > I assume it is done in the same way as for TCP/TLS, but that is not > written anywhere. > > > > The text I pasted from 4583bis above describes this. If we put all the > connection management stuff in 4583bis instead of leaving it split across > 4582bis and 4583bis, this should be clear. > > > > Cheers, > > Charles > > > > > > > > Regards, > > > > Christer > > > > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --047d7b5da5bbf13f8d04f72beacc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm starting with addressing this last issue first: RF= C 4583 has lived fine for some years and do have a number of interoperable = implementations out there. This happened without structuring the O/A proced= ures using RFC 3264 as a blueprint as was suggested for Christer's draf= t in MMUSIC.

Additinally, this issue never raised during SDP direct= orate review.

I propose we do not rest= ructure rfc4583bis this way.=C2=A0

-- = Tom


On 29 M= arch 2014 12:44, Christer Holmberg <christer.holmberg@ericsso= n.com> wrote:

Hi,

=C2=A0

Another thing.<= u>

=C2=A0

As part of the WGLC fo= r one of my draft in MMUSIC, I received comments that the SDP O/A procedure= s should be structured according to RFC 3264, ie =E2=80=9CSending of initia= l offer=E2=80=9D, =E2=80=9CModifying session=E2=80=9D, =E2=80=9CProcessing = of answer=E2=80=9D etc.

=C2=A0

Eventhough this is not= MMUSIC, you may want to consider doing the same J

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: bfcpbis [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 29 March 2014 13:41
To: Charles Eckel (eckelcu)


Cc: bfcpbis@ie= tf.org
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and = 4583bis

=C2=A0

Hi Charles,<= /u>

=C2=A0

Without commenting on = specifics at this point, I really think we should try to get the SDP Offer/= Answer procedures into one place (4583bis).

=C2=A0

4582bis can define act= ions taken by the DTLS client and server, but should not define how those r= oles are determined. 4583bis then defines how the roles are determined when= using SDP O/A.

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
Sent: 27 March 2014 01:11
To: Christer Holmberg
Cc: bfcpbis@ie= tf.org
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and = 4583bis

=C2=A0

Hi Christer,=

=C2=A0

Thanks for your com= ments. The more I looked into them the more complex and tangled things beca= me. Let me try to walk through the current state of affairs and then propos= e a potential solutions.

=C2=A0

RFC 4582 breaks con= nection establishment into two cases:

  1. when SDP offer/answer IS NOT used
  2. when SDP offer/answer IS used

For (1), RFC 4582 p= oints to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds a reference to RFC= 5239 for XCON.

RFC 5018 deals with= the connection establishment, reestablishment, =C2=A0and TLS usage.=

RFC 5239 points bac= k to RFC 5018 for connection establishment.

RFC 5018 does not d= eal with DTLS. Unless we restrict DTLS to cases in which SDP offer/answer i= s used, we need to update RFC 5018 to deal with DTLS. Someone please tell m= e otherwise.

=C2=A0

Section 6.2 of draf= t-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC 5018 when dealing = with BFCP over UDP or DTLS. I think this should be relocated to an update t= o RFC 5018, and connection reestablishment should be described as well.

=C2=A0

For (2), RFC 4582 p= rovides a teaser but points to RFC 4583 for the normative language. draft-i= etf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf-bfcpbis-rfc4583bis= -09. Christer comments are in regard to inconsistencies here. I provided comments on those inline.=

=C2=A0

From: Christer= Holmberg <christer.holmberg@ericsson.com>
Date: Tuesday, March 25, 2014 at 12:39 PM
To: "bfcp= bis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583= bis

=C2=A0

Hi,

=C2=A0

Section 7 in 4582bis, which says:=

=C2=A0

=E2=80=9C7.=C2=A0 Lower-Layer Security<= u>

=C2=A0

=C2=A0=C2=A0 BFCP relies on lower-layer security mechanism= s to provide replay and

=C2=A0=C2=A0 integrity protection and confidentiality.=C2= =A0 BFCP floor control servers

=C2=A0=C2=A0 and clients (which include both floor partici= pants and floor chairs)

=C2=A0

=C2=A0=C2=A0 MUST support TLS for transport over TCP [6] a= nd MUST support DTLS [7]

=C2=A0=C2=A0 for transport over UDP.=C2=A0 Any BFCP entity= MAY support other security

=C2=A0=C2=A0 mechanisms.<= /span>

=C2=A0

=C2=A0=C2=A0 BFCP entities MUST support, at a minimum, the=

=C2=A0=C2=A0 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=

=C2=A0

=C2=A0=C2=A0 Which party, the client or the floor control = server, acts as the TLS/

=C2=A0=C2=A0 DTLS server depends on how the underlying TLS= /DTLS connection is

=C2=A0=C2=A0 established.=C2=A0 For a TCP/TLS connection e= stablished using an SDP

=C2=A0=C2=A0 offer/answer exchange [9], the answerer (whic= h may be the client or

=C2=A0=C2=A0 the floor control server) always acts as the = TLS server.=C2=A0 If the TCP

=C2=A0=C2=A0 connection is lost, the active endpoint, i.e.= , the current TLS

=C2=A0=C2=A0 client, is responsible for re-establishing th= e TCP connection.

=C2=A0=C2=A0 Unless a new TLS session is negotiated, subse= quent SDP offers and

=C2=A0=C2=A0 answers will not impact the previously negoti= ated TLS roles.

=C2=A0

=C2=A0=C2=A0 For a UDP/DTLS connection established using t= he an SDP offer/answer

=C2=A0=C2=A0 exchange, either party can be the DTLS server= depending on the setup

=C2=A0=C2=A0 attributes exchanged; examples can be found i= n [23].=E2=80=9D

=C2=A0

First, we already earlier discussed that the active TCP endpoint is respons= ible for re-establishing the TCP connection, and that will be corrected in = the next version of the draft.

=C2=A0

Yes.<= /span>

=C2=A0

=C2=A0

However, we have discussed a similar top= ic in CLUE, and we were wondering whether it would be good that, whoever de= tects a connection failure, sends a new offer in order to re-establish the = connection. It does not matter if both endpoints send an offer =E2=80=93 the offer/answer race= condition rules will take care of that.

=C2=A0

In CLUE, is this for a TCP/TLS conne= ction, or for a DTLS connection?

For DTLS, we specifically chose to a= lter the behavior, as described in section 9.1 of 4583bis:

=C2=A0

=C2=A0 "Endpoints that use the = offer/answer model to establish a DTLS

=C2=A0 =C2=A0association MUST suppor= t the 'setup' attribute, as defined in [7].

=C2=A0 =C2=A0When DTLS is used with = UDP, the 'setup' attribute indicates which of<= /p>

=C2=A0 =C2=A0the endpoints (client o= r floor control server) initiates the DTLS

=C2=A0 =C2=A0association setup. =C2= =A0The requirements for the offer/answer exchange

=C2=A0 =C2=A0specified in [13], Sect= ion 5 MUST be followed when using DTLS.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 Informational n= ote: How to determine which endpoint to initiate

=C2=A0 =C2=A0 =C2=A0 the TLS/DTLS as= sociation depends on the selected underlying

=C2=A0 =C2=A0 =C2=A0 transport. =C2= =A0It was decided to keep the original semantics in [15]

=C2=A0 =C2=A0 =C2=A0 for TCP to reta= in backwards compatibility. =C2=A0When using UDP, the<= /p>

=C2=A0 =C2=A0 =C2=A0 procedure above= was preferred since it adheres to [13] as used for

=C2=A0 =C2=A0 =C2=A0 DTLS-SRTP, it d= oes not overload offer/answer semantics, and it

=C2=A0 =C2=A0 =C2=A0 works for offer= less INVITE in scenarios with B2BUAs."

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Second, Section 8.1 in 4583bis says:

=C2=A0

=C2=A0=C2=A0 =E2=80=9CWhen the existing TCP connection is reset following =
the rules in [8],
=C2=A0=C2=A0 the client MUST generate an offer towards the floor control s=
erver in
=C2=A0=C2=A0 order to reestablish the connection.=C2=A0 If a TCP connectio=
n cannot
=C2=A0=C2=A0 deliver a BFCP message and times out, the entity that attempt=
ed to
=C2=A0=C2=A0 send the message (i.e., the one that detected the TCP timeout=
) MUST
=C2=A0=C2=A0 generate an offer in order to reestablish the TCP connection.=
=E2=80=9D
=C2=A0
=C2=A0

I am not sure what is meant by =E2=80=9C= TCP connection is reset following the rules in [8]=E2=80=9D. Which rules ar= e you referring to?

=C2=A0

Reset means closed and reestablished= . The word =E2=80=9Creset=E2=80=9D was used in RFC 4582 and reused in 4582b= is. Perhaps we should change it closed and reestablished to avoid confusion?

=C2=A0

=C2=A0

Then, the text says that the client alwa= ys re-established the TCP connection. Is that aligned with the text in 4582= bis, saying that the active party does the reestablishment? Is the client a= lways active?

=C2=A0

I think it is a little confusing that bo= th 4582bis and 4583bis defines SDP Offer/Answer procedures. Shouldn=E2=80= =99t they only be in 4583bis?

=C2=A0

Yes, I think so. RFC 4582 mixed some= SDP offer/answer text into its section on lower layer security, and 4582bi= s followed suit. It would be better to have all the details of connection establishment and= reestablishment in when using SDP offer/answer in 4583bis.=C2=A0=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Third, the last paragraph, talking about UDP/DTLS, says that either party c= an be DTLS server depending on the setup attributes exchanged. But, nowhere= is it described how the setup attribute is used to determine the DTLS server role J

=C2=A0

I assume it is done in the same way as f= or TCP/TLS, but that is not written anywhere.

=C2=A0

The text I pasted from 4583bis above= describes this. If we put all the connection management stuff in 4583bis i= nstead of leaving it split across 4582bis and 4583bis, this should be clear.

=C2=A0

Cheers,

Charles

=C2=A0

=C2=A0

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0


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




--
# Cisco = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.com =C2=A0| =C2=A0http://www.tandberg.com<= /a>
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/
--047d7b5da5bbf13f8d04f72beacc-- From nobody Wed Apr 16 10:09:24 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1C61A0250 for ; Wed, 16 Apr 2014 10:09: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exrRG5RhCDDt for ; Wed, 16 Apr 2014 10:09:14 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BA5F71A0165 for ; Wed, 16 Apr 2014 10:09:13 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so11029050wes.18 for ; Wed, 16 Apr 2014 10:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=dxDLjc/bjLvRJGpQ5Bri3lOtd89GF0cU6voufgIhhsA=; b=K6DwpnheAkYaaH83Qr5jEPO1g3VYwD4pQxL2iLJh9HBQFzgNscG/RUZtYnjmCZp3SE UYYW6sjsndZoGsrUV8IbnwHT1Mz33LnZY2BKFw+G2VuI/phF5Ttn5k6pbU8LehmuZooI D8pOoza4xybUhPQ2tGWq8MixFwvVtD9Xm0JHJ9ztHdPp9rx5UbhL/YsTm5FM1DPtVcPW xQFrdgYwcq/GliH4E+9D7Y/06MVulEGPMVT1sr8f2a8lF+86lDgfaNeXIv0Ck/zF5yhq bB5lT0DQYfmgQ3WUgYmSH7DLOj7wZgbmIIF/ghsuofw9o/aspbOMJhJMMV9TTK9wza4O NI4A== MIME-Version: 1.0 X-Received: by 10.180.149.143 with SMTP id ua15mr8352091wib.36.1397668149995; Wed, 16 Apr 2014 10:09:09 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Wed, 16 Apr 2014 10:09:09 -0700 (PDT) Date: Wed, 16 Apr 2014 12:09:09 -0500 Message-ID: From: Mary Barnes To: Tom Kristensen <2mkristensen@gmail.com> Content-Type: multipart/alternative; boundary=001a11c38e70982ded04f72bf920 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/9rj8HrERKTNl-mcd-lx3acl3KXY Cc: "bfcpbis@ietf.org" , Gonzalo Camarillo , Tom Kristensen Subject: Re: [bfcpbis] Progressing 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:09:19 -0000 --001a11c38e70982ded04f72bf920 Content-Type: text/plain; charset=UTF-8 I did not see a response to this comment from Christer: http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00302.html Also, I have not yet reviewed the most recent version against my proto write-up preparation reviews on Dec. 18, 2013. Once, the next revision is submitted, I'll do that within a week or so and of course, we would want confirmation from Christer that he is okay with the changes. And, I'm assuming Charles will double-check that all his editorial comments were addressed. I'm also finding it difficult looking at the archives to know which version is being discussed. Including version numbers in the emails is extremely helpful. Otherwise, I have to look at dates and see how they match with the version that's active during that timeframe. For example, for this thread, I have no idea which version is being referenced: http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00308.html So, I don't know in which version any changes should appear. Regards, Mary. On Wed, Apr 16, 2014 at 11:46 AM, Tom Kristensen <2mkristensen@gmail.com>wrote: > And for the record, I did go through the diff between the currently > published version (fresh for the London IETF) and the one before to make > sure the issues raised on the mailing list were addressed and fixed. I do > believe that is true. > > -- Tom > > > On 7 April 2014 12:04, Gonzalo Camarillo wrote: > >> Thanks for the quick response, Tom. >> >> Cheers, >> >> Gonzalo >> >> On 07/04/2014 1:02 PM, Tom Kristensen wrote: >> > Comments from Charles was fine and is fixed, will respond to list. >> > >> > I'm currently trying to figure out how to cope with Christer's input and >> > issues, will respond to list for that as well. >> > >> > The time plan should be fixing immediately, so any delay is very much >> > unfortunate :( I agree. >> > >> > -- Tom >> > >> > On 04/07/2014 08:47 AM, Gonzalo Camarillo wrote: >> >> Hi, >> >> the call for comments on 4582bis and 4583bis is over. I have not seen >> >> any response to the comments Charles sent a couple of weeks ago. >> >> Additionally, Christer has also sent some comments. >> >> >> >> What is the time plan to progress these drafts? >> >> >> >> Thanks, >> >> >> >> Gonzalo >> >> >> >> _______________________________________________ >> >> bfcpbis mailing list >> >> bfcpbis@ietf.org >> >> https://www.ietf.org/mailman/listinfo/bfcpbis >> >> >> > >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> > > > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > --001a11c38e70982ded04f72bf920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I did not see a response to this comment from Christe= r:=C2=A0

Also, I have not yet reviewed the most recent version = against my proto write-up preparation reviews on Dec. 18, 2013.=C2=A0
<= br>
Once, the next revision is submitted, I'll do that within a wee= k or so and of course, we would want confirmation from Christer that he is = okay with the changes. =C2=A0And, I'm assuming Charles will double-chec= k that all his editorial comments were addressed.=C2=A0

I'm also finding it difficult looking at the = archives to know which version is being discussed. Including version number= s in the emails is extremely helpful. Otherwise, I have to look at dates an= d see how they match with the version that's active during that timefra= me. =C2=A0For example, for this thread, I have no idea which version is bei= ng referenced: =C2=A0http://www.ietf.org/mail-archive/web/bfcpbis/curre= nt/msg00308.html
So, I don't know in which version any changes should appear.=

Regards,
Mary.=C2=A0


On Wed, Apr 16, 2014 at 11= :46 AM, Tom Kristensen <2mkristensen@gmail.com> wrote:<= br>
And for the record, I did g= o through the diff between the currently published version (fresh for the L= ondon IETF) and the one before to make sure the issues raised on the mailin= g list were addressed and fixed. I do believe that is true.

-- Tom


On 7 April 2014 12:04, Gonzalo C= amarillo <Gonzalo.Camarillo@ericsson.com> wrote= :
Thanks for the quick response, Tom.

Cheers,

Gonzalo

On 07/04/2014 1:02 PM, Tom Kristensen wrote:
> Comments from Charles was fine and is fixed, will respond to list.
>
> I'm currently trying to figure out how to cope with Christer's= input and
> issues, will respond to list for that as well.
>
> The time plan should be fixing immediately, so any delay is very much<= br> > unfortunate :( I agree.
>
> -- Tom
>
> On 04/07/2014 08:47 AM, Gonzalo Camarillo wrote:
>> Hi,
>> the call for comments on 4582bis and 4583bis is over. I have not s= een
>> any response to the comments Charles sent a couple of weeks ago. >> Additionally, Christer has also sent some comments.
>>
>> What is the time plan to progress these drafts?
>>
>> Thanks,
>>
>> Gonzalo
>>
>> _______________________________________________
>> bfcpbis mailing list
>> bfcpbis@ietf= .org
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>
>

_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis



<= /div>--
# Cisco =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om =C2=A0| =C2=A0= http://www.tandberg.com
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/

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


--001a11c38e70982ded04f72bf920-- From nobody Wed Apr 16 10:20:06 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C05F1A023D for ; Wed, 16 Apr 2014 10:20:04 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUnKlTS7SlP6 for ; Wed, 16 Apr 2014 10:19:59 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 15A8B1A022A for ; Wed, 16 Apr 2014 10:19:59 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j15so10939886qaq.2 for ; Wed, 16 Apr 2014 10:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6N9ZH6DD1vzXTP87nvUiAAC4N77lXg4KypcSAaZODig=; b=jrHX6F1USv2d6aJ6i/aiy3gN8T53Gr6PMb6rJwOt2Mz3Zj92V5c/HAau3WoWqtCDio Dh2mgMm7E0i8n9WjJUN8/OvCaTE4PLoMxaw72B1qedeIvvoRevsqIPlZ5+4epIAt/KDi DDf/VqH70Ge0jL23c7vbmD7K7bIIlU96HxH79C5CB/k4sVacKZK2cks0dhViZNic82w6 1n1Pa0XZ2Qw0yThw0nEvD9DQ80+lwoCr8Baja/J/L2CtCGU3kvzUYgCjeKguGVRdQ/p+ nZL6xrbkEGTDxXimVUKVUh7DqxWAFOVFkUJjSNa64dm+ufpuxpaTOs0UKZkIzq0NsSlH 2p7Q== MIME-Version: 1.0 X-Received: by 10.224.36.194 with SMTP id u2mr4657475qad.73.1397668795529; Wed, 16 Apr 2014 10:19:55 -0700 (PDT) Received: by 10.229.2.66 with HTTP; Wed, 16 Apr 2014 10:19:55 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D26AD25@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D26AD25@ESESSMB209.ericsson.se> Date: Wed, 16 Apr 2014 19:19:55 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c2a240128d1304f72c2028 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/68w34PzCs0Et34v_1knp_l1ztY8 Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , Tom Kristensen Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:20:04 -0000 --001a11c2a240128d1304f72c2028 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It would be much clearer and less confusing to have all the SDP offer/answer related procedures in rfc4583bis. I agree and have started working on it, i.e. moving content to rfc4583bis and polishing text in rfc4582bis. However, what do people on this list think about the concerns and sketch for solving this issue proposed by Charles? And specifically: Do we want to (i) update RFC 5018 with UDP / DTLS or do we think it is even thinkable/doable to (ii) specify UDP / DTLS as a transport only when offer/answer is used? (Not a clean approach, but very pragmatic ;) ) -- Tom On 29 March 2014 12:40, Christer Holmberg w= rote: > Hi Charles, > > > > Without commenting on specifics at this point, I really think we should > try to get the SDP Offer/Answer procedures into one place (4583bis). > > > > 4582bis can define actions taken by the DTLS client and server, but shoul= d > not define how those roles are determined. 4583bis then defines how the > roles are determined when using SDP O/A. > > > > Regards, > > > > Christer > > > > *From:* Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > *Sent:* 27 March 2014 01:11 > *To:* Christer Holmberg > *Cc:* bfcpbis@ietf.org > *Subject:* Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and > 4583bis > > > > Hi Christer, > > > > Thanks for your comments. The more I looked into them the more complex an= d > tangled things became. Let me try to walk through the current state of > affairs and then propose a potential solutions. > > > > RFC 4582 breaks connection establishment into two cases: > > 1. when SDP offer/answer IS NOT used > 2. when SDP offer/answer IS used > > For (1), RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 > adds a reference to RFC 5239 for XCON. > > RFC 5018 deals with the connection establishment, reestablishment, and > TLS usage. > > RFC 5239 points back to RFC 5018 for connection establishment. > > RFC 5018 does not deal with DTLS. Unless we restrict DTLS to cases in > which SDP offer/answer is used, we need to update RFC 5018 to deal with > DTLS. Someone please tell me otherwise. > > > > Section 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend > RFC 5018 when dealing with BFCP over UDP or DTLS. I think this should be > relocated to an update to RFC 5018, and connection reestablishment should > be described as well. > > > > For (2), RFC 4582 provides a teaser but points to RFC 4583 for the > normative language. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to > draft-ietf-bfcpbis-rfc4583bis-09. Christer comments are in regard to > inconsistencies here. I provided comments on those inline. > > > > *From: *Christer Holmberg > *Date: *Tuesday, March 25, 2014 at 12:39 PM > *To: *"bfcpbis@ietf.org" > *Subject: *[bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis > > > > Hi, > > > > Section 7 in 4582bis, which says: > > > > =E2=80=9C7. Lower-Layer Security > > > > BFCP relies on lower-layer security mechanisms to provide replay and > > integrity protection and confidentiality. BFCP floor control servers > > and clients (which include both floor participants and floor chairs) > > > > MUST support TLS for transport over TCP [6] and MUST support DTLS [7] > > for transport over UDP. Any BFCP entity MAY support other security > > mechanisms. > > > > BFCP entities MUST support, at a minimum, the > > TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. > > > > Which party, the client or the floor control server, acts as the TLS/ > > DTLS server depends on how the underlying TLS/DTLS connection is > > established. For a TCP/TLS connection established using an SDP > > offer/answer exchange [9], the answerer (which may be the client or > > the floor control server) always acts as the TLS server. If the TCP > > connection is lost, the active endpoint, i.e., the current TLS > > client, is responsible for re-establishing the TCP connection. > > Unless a new TLS session is negotiated, subsequent SDP offers and > > answers will not impact the previously negotiated TLS roles. > > > > For a UDP/DTLS connection established using the an SDP offer/answer > > exchange, either party can be the DTLS server depending on the setup > > attributes exchanged; examples can be found in [23].=E2=80=9D > > > > *First*, we already earlier discussed that the active TCP endpoint is > responsible for re-establishing the TCP connection, and that will be > corrected in the next version of the draft. > > > > Yes. > > > > > > However, we have discussed a similar topic in CLUE, and we were wondering > whether it would be good that, whoever detects a connection failure, send= s > a new offer in order to re-establish the connection. It does not matter i= f > both endpoints send an offer =E2=80=93 the offer/answer race condition ru= les will > take care of that. > > > > In CLUE, is this for a TCP/TLS connection, or for a DTLS connection? > > For DTLS, we specifically chose to alter the behavior, as described in > section 9.1 of 4583bis: > > > > "Endpoints that use the offer/answer model to establish a DTLS > > association MUST support the 'setup' attribute, as defined in [7]. > > When DTLS is used with UDP, the 'setup' attribute indicates which of > > the endpoints (client or floor control server) initiates the DTLS > > association setup. The requirements for the offer/answer exchange > > specified in [13], Section 5 MUST be followed when using DTLS. > > > > Informational note: How to determine which endpoint to initiate > > the TLS/DTLS association depends on the selected underlying > > transport. It was decided to keep the original semantics in [15] > > for TCP to retain backwards compatibility. When using UDP, the > > procedure above was preferred since it adheres to [13] as used for > > DTLS-SRTP, it does not overload offer/answer semantics, and it > > works for offerless INVITE in scenarios with B2BUAs." > > > > > > > > > > *Second*, Section 8.1 in 4583bis says: > > > > =E2=80=9CWhen the existing TCP connection is reset following the rules= in [8], > > the client MUST generate an offer towards the floor control server in > > order to reestablish the connection. If a TCP connection cannot > > deliver a BFCP message and times out, the entity that attempted to > > send the message (i.e., the one that detected the TCP timeout) MUST > > generate an offer in order to reestablish the TCP connection.=E2=80=9D > > > > > > I am not sure what is meant by =E2=80=9CTCP connection is reset following= the > rules in [8]=E2=80=9D. Which rules are you referring to? > > > > Reset means closed and reestablished. The word =E2=80=9Creset=E2=80=9D wa= s used in RFC > 4582 and reused in 4582bis. Perhaps we should change it closed and > reestablished to avoid confusion? > > > > > > Then, the text says that the client always re-established the TCP > connection. Is that aligned with the text in 4582bis, saying that the > active party does the reestablishment? Is the client always active? > > > > I think it is a little confusing that both 4582bis and 4583bis defines SD= P > Offer/Answer procedures. Shouldn=E2=80=99t they only be in 4583bis? > > > > Yes, I think so. RFC 4582 mixed some SDP offer/answer text into its > section on lower layer security, and 4582bis followed suit. It would be > better to have all the details of connection establishment and > reestablishment in when using SDP offer/answer in 4583bis. > > > > > > > > > > *Third*, the last paragraph, talking about UDP/DTLS, says that either > party can be DTLS server depending on the setup attributes exchanged. But= , > nowhere is it described how the setup attribute is used to determine the > DTLS server role J > > > > I assume it is done in the same way as for TCP/TLS, but that is not > written anywhere. > > > > The text I pasted from 4583bis above describes this. If we put all the > connection management stuff in 4583bis instead of leaving it split across > 4582bis and 4583bis, this should be clear. > > > > Cheers, > > Charles > > > > > > > > Regards, > > > > Christer > > > > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a11c2a240128d1304f72c2028 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It would be much clearer and less confusing to have all th= e SDP offer/answer related procedures in rfc4583bis. I agree and have start= ed working on it, i.e. moving content to rfc4583bis and polishing text in r= fc4582bis.

However, what do people on this list think about the c= oncerns and sketch for solving this issue proposed by Charles?

And specifically: Do we want to (i) update RFC 501= 8 with UDP / DTLS or do we think it is even thinkable/doable to (ii) specif= y UDP / DTLS as a transport only when offer/answer is used? (Not a clean ap= proach, but very pragmatic ;) )

-- Tom=C2=A0


On 29 March 2014 12:40, Christer= Holmberg <christer.holmberg@ericsson.com> wrot= e:

Hi Charles,<= /u>

=C2=A0

Without commenting on = specifics at this point, I really think we should try to get the SDP Offer/= Answer procedures into one place (4583bis).

=C2=A0

4582bis can define act= ions taken by the DTLS client and server, but should not define how those r= oles are determined. 4583bis then defines how the roles are determined when= using SDP O/A.

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
Sent: 27 March 2014 01:11
To: Christer Holmberg
Cc: bfcpbis@ie= tf.org
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and = 4583bis

=C2=A0

Hi Christer,=

=C2=A0

Thanks for your com= ments. The more I looked into them the more complex and tangled things beca= me. Let me try to walk through the current state of affairs and then propos= e a potential solutions.

=C2=A0

RFC 4582 breaks con= nection establishment into two cases:

  1. when SDP offer/answer IS NOT used
  2. when SDP offer/answer IS used

For (1), RFC 4582 p= oints to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds a reference to RFC= 5239 for XCON.

RFC 5018 deals with= the connection establishment, reestablishment, =C2=A0and TLS usage.=

RFC 5239 points bac= k to RFC 5018 for connection establishment.

RFC 5018 does not d= eal with DTLS. Unless we restrict DTLS to cases in which SDP offer/answer i= s used, we need to update RFC 5018 to deal with DTLS. Someone please tell m= e otherwise.

=C2=A0

Section 6.2 of draf= t-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC 5018 when dealing = with BFCP over UDP or DTLS. I think this should be relocated to an update t= o RFC 5018, and connection reestablishment should be described as well.

=C2=A0

For (2), RFC 4582 p= rovides a teaser but points to RFC 4583 for the normative language. draft-i= etf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf-bfcpbis-rfc4583bis= -09. Christer comments are in regard to inconsistencies here. I provided comments on those inline.=

=C2=A0

From: Christer= Holmberg <christer.holmberg@ericsson.com>
Date: Tuesday, March 25, 2014 at 12:39 PM
To: "bfcp= bis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583= bis

=C2=A0

Hi,

=C2=A0

Section 7 in 4582bis, which says:=

=C2=A0

=E2=80=9C7.=C2=A0 Lower-Layer Security<= u>

=C2=A0

=C2=A0=C2=A0 BFCP relies on lower-layer security mechanism= s to provide replay and

=C2=A0=C2=A0 integrity protection and confidentiality.=C2= =A0 BFCP floor control servers

=C2=A0=C2=A0 and clients (which include both floor partici= pants and floor chairs)

=C2=A0

=C2=A0=C2=A0 MUST support TLS for transport over TCP [6] a= nd MUST support DTLS [7]

=C2=A0=C2=A0 for transport over UDP.=C2=A0 Any BFCP entity= MAY support other security

=C2=A0=C2=A0 mechanisms.<= /span>

=C2=A0

=C2=A0=C2=A0 BFCP entities MUST support, at a minimum, the=

=C2=A0=C2=A0 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=

=C2=A0

=C2=A0=C2=A0 Which party, the client or the floor control = server, acts as the TLS/

=C2=A0=C2=A0 DTLS server depends on how the underlying TLS= /DTLS connection is

=C2=A0=C2=A0 established.=C2=A0 For a TCP/TLS connection e= stablished using an SDP

=C2=A0=C2=A0 offer/answer exchange [9], the answerer (whic= h may be the client or

=C2=A0=C2=A0 the floor control server) always acts as the = TLS server.=C2=A0 If the TCP

=C2=A0=C2=A0 connection is lost, the active endpoint, i.e.= , the current TLS

=C2=A0=C2=A0 client, is responsible for re-establishing th= e TCP connection.

=C2=A0=C2=A0 Unless a new TLS session is negotiated, subse= quent SDP offers and

=C2=A0=C2=A0 answers will not impact the previously negoti= ated TLS roles.

=C2=A0

=C2=A0=C2=A0 For a UDP/DTLS connection established using t= he an SDP offer/answer

=C2=A0=C2=A0 exchange, either party can be the DTLS server= depending on the setup

=C2=A0=C2=A0 attributes exchanged; examples can be found i= n [23].=E2=80=9D

=C2=A0

First, we already earlier discussed that the active TCP endpoint is respons= ible for re-establishing the TCP connection, and that will be corrected in = the next version of the draft.

=C2=A0

Yes.<= /span>

=C2=A0

=C2=A0

However, we have discussed a similar top= ic in CLUE, and we were wondering whether it would be good that, whoever de= tects a connection failure, sends a new offer in order to re-establish the = connection. It does not matter if both endpoints send an offer =E2=80=93 the offer/answer race= condition rules will take care of that.

=C2=A0

In CLUE, is this for a TCP/TLS conne= ction, or for a DTLS connection?

For DTLS, we specifically chose to a= lter the behavior, as described in section 9.1 of 4583bis:

=C2=A0

=C2=A0 "Endpoints that use the = offer/answer model to establish a DTLS

=C2=A0 =C2=A0association MUST suppor= t the 'setup' attribute, as defined in [7].

=C2=A0 =C2=A0When DTLS is used with = UDP, the 'setup' attribute indicates which of<= /p>

=C2=A0 =C2=A0the endpoints (client o= r floor control server) initiates the DTLS

=C2=A0 =C2=A0association setup. =C2= =A0The requirements for the offer/answer exchange

=C2=A0 =C2=A0specified in [13], Sect= ion 5 MUST be followed when using DTLS.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 Informational n= ote: How to determine which endpoint to initiate

=C2=A0 =C2=A0 =C2=A0 the TLS/DTLS as= sociation depends on the selected underlying

=C2=A0 =C2=A0 =C2=A0 transport. =C2= =A0It was decided to keep the original semantics in [15]

=C2=A0 =C2=A0 =C2=A0 for TCP to reta= in backwards compatibility. =C2=A0When using UDP, the<= /p>

=C2=A0 =C2=A0 =C2=A0 procedure above= was preferred since it adheres to [13] as used for

=C2=A0 =C2=A0 =C2=A0 DTLS-SRTP, it d= oes not overload offer/answer semantics, and it

=C2=A0 =C2=A0 =C2=A0 works for offer= less INVITE in scenarios with B2BUAs."

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Second, Section 8.1 in 4583bis says:

=C2=A0

=C2=A0=C2=A0 =E2=80=9CWhen the existing TCP connection is reset following =
the rules in [8],
=C2=A0=C2=A0 the client MUST generate an offer towards the floor control s=
erver in
=C2=A0=C2=A0 order to reestablish the connection.=C2=A0 If a TCP connectio=
n cannot
=C2=A0=C2=A0 deliver a BFCP message and times out, the entity that attempt=
ed to
=C2=A0=C2=A0 send the message (i.e., the one that detected the TCP timeout=
) MUST
=C2=A0=C2=A0 generate an offer in order to reestablish the TCP connection.=
=E2=80=9D
=C2=A0
=C2=A0

I am not sure what is meant by =E2=80=9C= TCP connection is reset following the rules in [8]=E2=80=9D. Which rules ar= e you referring to?

=C2=A0

Reset means closed and reestablished= . The word =E2=80=9Creset=E2=80=9D was used in RFC 4582 and reused in 4582b= is. Perhaps we should change it closed and reestablished to avoid confusion?

=C2=A0

=C2=A0

Then, the text says that the client alwa= ys re-established the TCP connection. Is that aligned with the text in 4582= bis, saying that the active party does the reestablishment? Is the client a= lways active?

=C2=A0

I think it is a little confusing that bo= th 4582bis and 4583bis defines SDP Offer/Answer procedures. Shouldn=E2=80= =99t they only be in 4583bis?

=C2=A0

Yes, I think so. RFC 4582 mixed some= SDP offer/answer text into its section on lower layer security, and 4582bi= s followed suit. It would be better to have all the details of connection establishment and= reestablishment in when using SDP offer/answer in 4583bis.=C2=A0=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Third, the last paragraph, talking about UDP/DTLS, says that either party c= an be DTLS server depending on the setup attributes exchanged. But, nowhere= is it described how the setup attribute is used to determine the DTLS server role J

=C2=A0

I assume it is done in the same way as f= or TCP/TLS, but that is not written anywhere.

=C2=A0

The text I pasted from 4583bis above= describes this. If we put all the connection management stuff in 4583bis i= nstead of leaving it split across 4582bis and 4583bis, this should be clear.

=C2=A0

Cheers,

Charles

=C2=A0

=C2=A0

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0


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




--
# Cisco = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.com =C2=A0| =C2=A0http://www.tandberg.com<= /a>
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/
--001a11c2a240128d1304f72c2028-- From nobody Wed Apr 16 10:27:12 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505C21A01C9 for ; Wed, 16 Apr 2014 10:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 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, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibcqk4q_5y_k for ; Wed, 16 Apr 2014 10:27:08 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id D9AA91A01AC for ; Wed, 16 Apr 2014 10:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5083; q=dns/txt; s=iport; t=1397669225; x=1398878825; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=K+2THfWKFppNjQlFT0Xz/+rvIzLYH4Mg3mDq90DOmxo=; b=HV/KaCx/vMPdWO5LHWzitXks5eYgHlBamj5qpFkguimzyYMFX4AgbYEd GJ7d/hM5iGFI/ksREqVKLVTUUfIdnLKOCWzpCIvNV/2+l1taLken2uGUq 8zZkZvT/PZxGb05xmoGC5m6vdyK6agiE3JppzHik1CqIwgy5FwHvfi73y o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAAq8TlOQ/khN/2dsb2JhbABZgwY7g2m/UlGBIhZ0giUBAQEDASNVAQULCwQUCRYLAgIJAwIBAgFFBg0BBwEBBYdrCA2mH6MKF44OAwEBTweCb4FJBJhmhlaLc4MzO4E1 X-IronPort-AV: E=Sophos; i="4.97,873,1389744000"; d="scan'208,217"; a="19121149" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 16 Apr 2014 17:27:04 +0000 Received: from [10.61.196.5] ([10.61.196.5]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3GHR3qI027362; Wed, 16 Apr 2014 17:27:03 GMT Message-ID: <534EBD67.4070706@cisco.com> Date: Wed, 16 Apr 2014 19:27:03 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050903000309070402050901" Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/WeeAsAwYxzzJxAK1CcrQh_UsV58 Cc: "bfcpbis@ietf.org" , Tom Kristensen <2mkristensen@gmail.com>, Gonzalo Camarillo Subject: Re: [bfcpbis] Progressing 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:27:10 -0000 This is a multi-part message in MIME format. --------------050903000309070402050901 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04/16/2014 07:09 PM, Mary Barnes wrote: > I did not see a response to this comment from Christer: > http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00302.html I just answered just that message and proposed not to restructure according to O/A procedures in RFC 3264. > Also, I have not yet reviewed the most recent version against my proto > write-up preparation reviews on Dec. 18, 2013. Ah, I see. Hopefully, everything was taken care of. > Once, the next revision is submitted, I'll do that within a week or so > and of course, we would want confirmation from Christer that he is > okay with the changes. And, I'm assuming Charles will double-check > that all his editorial comments were addressed. I need some guidance from the working group on the issues and on Charles' proposal. I just sent a mail to the list on that (moving O/A content to rfc4583bis only and what to do with RFC 5018 and UDP/TLS). > I'm also finding it difficult looking at the archives to know which > version is being discussed. Including version numbers in the emails is > extremely helpful. Otherwise, I have to look at dates and see how they > match with the version that's active during that timeframe. For > example, for this thread, I have no idea which version is being > referenced: > http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00308.html > So, I don't know in which version any changes should appear. OK. We'll be clearer on what versions we are dealing with from now on. Charles did review the (last call) versions of the rfc4582bis and rfc4583bis drafts, i.e. the current versions that where submitted for IETF-89 in London. -- Tom --------------050903000309070402050901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04/16/2014 07:09 PM, Mary Barnes wrote:
I did not see a response to this comment from Christer: 

I just answered just that message and proposed not to restructure according to O/A procedures in  RFC 3264.

Also, I have not yet reviewed the most recent version against my proto write-up preparation reviews on Dec. 18, 2013.

Ah, I see. Hopefully, everything was taken care of.

Once, the next revision is submitted, I'll do that within a week or so and of course, we would want confirmation from Christer that he is okay with the changes.  And, I'm assuming Charles will double-check that all his editorial comments were addressed.

I need some guidance from the working group on the issues and on Charles' proposal. I just sent a mail to the list on that (moving O/A content to rfc4583bis only and what to do with RFC 5018 and UDP/TLS).

I'm also finding it difficult looking at the archives to know which version is being discussed. Including version numbers in the emails is extremely helpful. Otherwise, I have to look at dates and see how they match with the version that's active during that timeframe.  For example, for this thread, I have no idea which version is being referenced:  http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00308.html
So, I don't know in which version any changes should appear.

OK. We'll be clearer on what versions we are dealing with from now on.

Charles did review the (last call) versions of the rfc4582bis and rfc4583bis drafts, i.e. the current versions that where submitted for IETF-89 in London.

-- Tom

<snip>
--------------050903000309070402050901-- From nobody Wed Apr 16 13:26:06 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4571A02E4 for ; Wed, 16 Apr 2014 13:26:03 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fovp2nxdvaaF for ; Wed, 16 Apr 2014 13:25:58 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id C56D01A0284 for ; Wed, 16 Apr 2014 13:25:56 -0700 (PDT) X-AuditID: c1b4fb3a-f79f36d0000039bf-95-534ee7505872 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D2.5F.14783.057EE435; Wed, 16 Apr 2014 22:25:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Wed, 16 Apr 2014 22:25:52 +0200 From: Christer Holmberg To: Tom Kristensen <2mkristensen@gmail.com> Thread-Topic: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Thread-Index: AQHPSUic50RqEV5EM0G8qoAclTNxQpr39BsggAABQxCAHIKOAIAAWUzg Date: Wed, 16 Apr 2014 20:25:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2CC87A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D26AD25@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D26AD60@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2CC87AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM+JvjW7Ac79ggy3PrSy2HH/HYvFv3VEm i02zvrBZXDnyi82BxWPK742sHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxpVzT9gLpr1m rug7f56lgXHLPeYuRk4OCQETiU/fmpkgbDGJC/fWs4HYQgJHGSV+nxDrYuQCspcwSizvvMbe xcjBwSZgIdH9TxukRkRAW+Lw6YNgc5gF6iW6l29iAbGFBbwlXvxbxQxR4yNx91oXO4TtJrHs xldmkDEsAqoS1+d7gZi8Ar4Ss87WQGz6yyix9e40sHJOgUCJtnn3wWxGoNO+n1rDBLFKXOLW k/lQJwtILNlzHuoVUYmXj/+xQthKEiu2X2KEqM+XeLTxMFicV0BQ4uTMJywTGEVnIRk1C0nZ LCRls4DOYxbQlFi/Sx+iRFFiSvdDdghbQ6J1zlx2ZPEFjOyrGEWLU4uLc9ONjPRSizKTi4vz 8/TyUks2MQJj8eCW31Y7GA8+dzzEKMDBqMTDy6bmFyzEmlhWXJl7iFGag0VJnHfSIvdgIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxCjYunrlv4PehxrHHlt7aGhe8TNpxwe1l/1iXis+x7 7qSn75WNNntfir9/bcuiukeWTgu+1Ppmit+53Peh6WfBFGl5i91crq2zpTjdJ7w61BZxsO6h 0u3w1by19vsEKvr8fnGGyqacqH7AHX9VuUeNMXTG+j9xT8IsjxcWdOy9PH/pfaGU6jYlluKM REMt5qLiRAB+zGULpgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/noXVkmcc2rxvyGDz9jphuiUbDNc Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , Tom Kristensen Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 20:26:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2CC87AESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JJ20gc3RhcnRpbmcgd2l0aCBhZGRyZXNzaW5nIHRoaXMgbGFzdCBpc3N1ZSBmaXJz dDogUkZDIDQ1ODMgaGFzIGxpdmVkIGZpbmUgZm9yIHNvbWUgeWVhcnMgYW5kID5kbyBoYXZlIGEg bnVtYmVyIG9mIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zIG91dCB0aGVyZS4gVGhpcyBo YXBwZW5lZCB3aXRob3V0ID5zdHJ1Y3R1cmluZyB0aGUgTy9BIHByb2NlZHVyZXMgdXNpbmcgUkZD IDMyNjQgYXMgYSBibHVlcHJpbnQgYXMgd2FzIHN1Z2dlc3RlZCBmb3IgQ2hyaXN0ZXIncyA+ZHJh ZnQgaW4gTU1VU0lDLg0KPg0KPkFkZGl0aW5hbGx5LCB0aGlzIGlzc3VlIG5ldmVyIHJhaXNlZCBk dXJpbmcgU0RQIGRpcmVjdG9yYXRlIHJldmlldy4NCj4NCj5JIHByb3Bvc2Ugd2UgZG8gbm90IHJl c3RydWN0dXJlIHJmYzQ1ODNiaXMgdGhpcyB3YXkuDQoNCk5vdGUgdGhhdCBJIGFtIG5vdCBhc2tp bmcgZm9yIGFueSB0ZWNobmljYWwgY2hhbmdlcy4NCg0KQnV0LCB0aGUgc3RydWN0dXJlIGJlbG93 IGRvZXMgbWFrZSB0aGluZ3MgZWFzaWVyIHRvIHJlYWQuIEJ1dCwgaWYgeW91IHRoaW5rIHlvdSBj YW4gZG8gaXQgaW4gYW5vdGhlciB3YXksIGZpbmUuIFRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdG8g Z2V0IGV2ZXJ5dGhpbmcgY292ZXJlZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAy OSBNYXJjaCAyMDE0IDEyOjQ0LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90 ZToNCkhpLA0KDQpBbm90aGVyIHRoaW5nLg0KDQpBcyBwYXJ0IG9mIHRoZSBXR0xDIGZvciBvbmUg b2YgbXkgZHJhZnQgaW4gTU1VU0lDLCBJIHJlY2VpdmVkIGNvbW1lbnRzIHRoYXQgdGhlIFNEUCBP L0EgcHJvY2VkdXJlcyBzaG91bGQgYmUgc3RydWN0dXJlZCBhY2NvcmRpbmcgdG8gUkZDIDMyNjQs IGllIOKAnFNlbmRpbmcgb2YgaW5pdGlhbCBvZmZlcuKAnSwg4oCcTW9kaWZ5aW5nIHNlc3Npb27i gJ0sIOKAnFByb2Nlc3Npbmcgb2YgYW5zd2Vy4oCdIGV0Yy4NCg0KRXZlbnRob3VnaCB0aGlzIGlz IG5vdCBNTVVTSUMsIHlvdSBtYXkgd2FudCB0byBjb25zaWRlciBkb2luZyB0aGUgc2FtZSDimLoN Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KRnJvbTogYmZjcGJpcyBbbWFpbHRvOmJm Y3BiaXMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YmZjcGJpcy1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiAyOSBNYXJjaCAyMDE0IDEzOjQx DQpUbzogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkNCg0KQ2M6IGJmY3BiaXNAaWV0Zi5vcmc8bWFp bHRvOmJmY3BiaXNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2JmY3BiaXNdIFRDUC9UTFMgYW5k IFVEUC9EVExTIGNvbW1lbnRzIG9uIDQ1ODJiaXMgYW5kIDQ1ODNiaXMNCg0KSGkgQ2hhcmxlcywN Cg0KV2l0aG91dCBjb21tZW50aW5nIG9uIHNwZWNpZmljcyBhdCB0aGlzIHBvaW50LCBJIHJlYWxs eSB0aGluayB3ZSBzaG91bGQgdHJ5IHRvIGdldCB0aGUgU0RQIE9mZmVyL0Fuc3dlciBwcm9jZWR1 cmVzIGludG8gb25lIHBsYWNlICg0NTgzYmlzKS4NCg0KNDU4MmJpcyBjYW4gZGVmaW5lIGFjdGlv bnMgdGFrZW4gYnkgdGhlIERUTFMgY2xpZW50IGFuZCBzZXJ2ZXIsIGJ1dCBzaG91bGQgbm90IGRl ZmluZSBob3cgdGhvc2Ugcm9sZXMgYXJlIGRldGVybWluZWQuIDQ1ODNiaXMgdGhlbiBkZWZpbmVz IGhvdyB0aGUgcm9sZXMgYXJlIGRldGVybWluZWQgd2hlbiB1c2luZyBTRFAgTy9BLg0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBDaGFybGVzIEVja2VsIChlY2tlbGN1KSBbbWFpbHRv OmVja2VsY3VAY2lzY28uY29tXQ0KU2VudDogMjcgTWFyY2ggMjAxNCAwMToxMQ0KVG86IENocmlz dGVyIEhvbG1iZXJnDQpDYzogYmZjcGJpc0BpZXRmLm9yZzxtYWlsdG86YmZjcGJpc0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbYmZjcGJpc10gVENQL1RMUyBhbmQgVURQL0RUTFMgY29tbWVudHMg b24gNDU4MmJpcyBhbmQgNDU4M2Jpcw0KDQpIaSBDaHJpc3RlciwNCg0KVGhhbmtzIGZvciB5b3Vy IGNvbW1lbnRzLiBUaGUgbW9yZSBJIGxvb2tlZCBpbnRvIHRoZW0gdGhlIG1vcmUgY29tcGxleCBh bmQgdGFuZ2xlZCB0aGluZ3MgYmVjYW1lLiBMZXQgbWUgdHJ5IHRvIHdhbGsgdGhyb3VnaCB0aGUg Y3VycmVudCBzdGF0ZSBvZiBhZmZhaXJzIGFuZCB0aGVuIHByb3Bvc2UgYSBwb3RlbnRpYWwgc29s dXRpb25zLg0KDQpSRkMgNDU4MiBicmVha3MgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IGludG8g dHdvIGNhc2VzOg0KDQogIDEuICB3aGVuIFNEUCBvZmZlci9hbnN3ZXIgSVMgTk9UIHVzZWQNCiAg Mi4gIHdoZW4gU0RQIG9mZmVyL2Fuc3dlciBJUyB1c2VkDQpGb3IgKDEpLCBSRkMgNDU4MiBwb2lu dHMgdG8gUkZDIDUwMTguIGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgyYmlzLTExIGFkZHMgYSBy ZWZlcmVuY2UgdG8gUkZDIDUyMzkgZm9yIFhDT04uDQpSRkMgNTAxOCBkZWFscyB3aXRoIHRoZSBj b25uZWN0aW9uIGVzdGFibGlzaG1lbnQsIHJlZXN0YWJsaXNobWVudCwgIGFuZCBUTFMgdXNhZ2Uu DQpSRkMgNTIzOSBwb2ludHMgYmFjayB0byBSRkMgNTAxOCBmb3IgY29ubmVjdGlvbiBlc3RhYmxp c2htZW50Lg0KUkZDIDUwMTggZG9lcyBub3QgZGVhbCB3aXRoIERUTFMuIFVubGVzcyB3ZSByZXN0 cmljdCBEVExTIHRvIGNhc2VzIGluIHdoaWNoIFNEUCBvZmZlci9hbnN3ZXIgaXMgdXNlZCwgd2Ug bmVlZCB0byB1cGRhdGUgUkZDIDUwMTggdG8gZGVhbCB3aXRoIERUTFMuIFNvbWVvbmUgcGxlYXNl IHRlbGwgbWUgb3RoZXJ3aXNlLg0KDQpTZWN0aW9uIDYuMiBvZiBkcmFmdC1pZXRmLWJmY3BiaXMt cmZjNDU4MmJpcy0xMSBkZXNjcmliZXMgaG93IHRvIGV4dGVuZCBSRkMgNTAxOCB3aGVuIGRlYWxp bmcgd2l0aCBCRkNQIG92ZXIgVURQIG9yIERUTFMuIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgcmVs b2NhdGVkIHRvIGFuIHVwZGF0ZSB0byBSRkMgNTAxOCwgYW5kIGNvbm5lY3Rpb24gcmVlc3RhYmxp c2htZW50IHNob3VsZCBiZSBkZXNjcmliZWQgYXMgd2VsbC4NCg0KRm9yICgyKSwgUkZDIDQ1ODIg cHJvdmlkZXMgYSB0ZWFzZXIgYnV0IHBvaW50cyB0byBSRkMgNDU4MyBmb3IgdGhlIG5vcm1hdGl2 ZSBsYW5ndWFnZS4gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXMtMTEgc2ltaWxhcmx5IHBv aW50cyB0byBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcy0wOS4gQ2hyaXN0ZXIgY29tbWVu dHMgYXJlIGluIHJlZ2FyZCB0byBpbmNvbnNpc3RlbmNpZXMgaGVyZS4gSSBwcm92aWRlZCBjb21t ZW50cyBvbiB0aG9zZSBpbmxpbmUuDQoNCkZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBNYXJjaCAyNSwgMjAxNCBhdCAxMjozOSBQTQ0KVG86ICJi ZmNwYmlzQGlldGYub3JnPG1haWx0bzpiZmNwYmlzQGlldGYub3JnPiIgPGJmY3BiaXNAaWV0Zi5v cmc8bWFpbHRvOmJmY3BiaXNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW2JmY3BiaXNdIFRDUC9UTFMg YW5kIFVEUC9EVExTIGNvbW1lbnRzIG9uIDQ1ODJiaXMgYW5kIDQ1ODNiaXMNCg0KSGksDQoNClNl Y3Rpb24gNyBpbiA0NTgyYmlzLCB3aGljaCBzYXlzOg0KDQrigJw3LiAgTG93ZXItTGF5ZXIgU2Vj dXJpdHkNCg0KICAgQkZDUCByZWxpZXMgb24gbG93ZXItbGF5ZXIgc2VjdXJpdHkgbWVjaGFuaXNt cyB0byBwcm92aWRlIHJlcGxheSBhbmQNCiAgIGludGVncml0eSBwcm90ZWN0aW9uIGFuZCBjb25m aWRlbnRpYWxpdHkuICBCRkNQIGZsb29yIGNvbnRyb2wgc2VydmVycw0KICAgYW5kIGNsaWVudHMg KHdoaWNoIGluY2x1ZGUgYm90aCBmbG9vciBwYXJ0aWNpcGFudHMgYW5kIGZsb29yIGNoYWlycykN Cg0KICAgTVVTVCBzdXBwb3J0IFRMUyBmb3IgdHJhbnNwb3J0IG92ZXIgVENQIFs2XSBhbmQgTVVT VCBzdXBwb3J0IERUTFMgWzddDQogICBmb3IgdHJhbnNwb3J0IG92ZXIgVURQLiAgQW55IEJGQ1Ag ZW50aXR5IE1BWSBzdXBwb3J0IG90aGVyIHNlY3VyaXR5DQogICBtZWNoYW5pc21zLg0KDQogICBC RkNQIGVudGl0aWVzIE1VU1Qgc3VwcG9ydCwgYXQgYSBtaW5pbXVtLCB0aGUNCiAgIFRMU19SU0Ff V0lUSF9BRVNfMTI4X0NCQ19TSEEgY2lwaGVyc3VpdGUgWzZdLg0KDQogICBXaGljaCBwYXJ0eSwg dGhlIGNsaWVudCBvciB0aGUgZmxvb3IgY29udHJvbCBzZXJ2ZXIsIGFjdHMgYXMgdGhlIFRMUy8N CiAgIERUTFMgc2VydmVyIGRlcGVuZHMgb24gaG93IHRoZSB1bmRlcmx5aW5nIFRMUy9EVExTIGNv bm5lY3Rpb24gaXMNCiAgIGVzdGFibGlzaGVkLiAgRm9yIGEgVENQL1RMUyBjb25uZWN0aW9uIGVz dGFibGlzaGVkIHVzaW5nIGFuIFNEUA0KICAgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIFs5XSwgdGhl IGFuc3dlcmVyICh3aGljaCBtYXkgYmUgdGhlIGNsaWVudCBvcg0KICAgdGhlIGZsb29yIGNvbnRy b2wgc2VydmVyKSBhbHdheXMgYWN0cyBhcyB0aGUgVExTIHNlcnZlci4gIElmIHRoZSBUQ1ANCiAg IGNvbm5lY3Rpb24gaXMgbG9zdCwgdGhlIGFjdGl2ZSBlbmRwb2ludCwgaS5lLiwgdGhlIGN1cnJl bnQgVExTDQogICBjbGllbnQsIGlzIHJlc3BvbnNpYmxlIGZvciByZS1lc3RhYmxpc2hpbmcgdGhl IFRDUCBjb25uZWN0aW9uLg0KICAgVW5sZXNzIGEgbmV3IFRMUyBzZXNzaW9uIGlzIG5lZ290aWF0 ZWQsIHN1YnNlcXVlbnQgU0RQIG9mZmVycyBhbmQNCiAgIGFuc3dlcnMgd2lsbCBub3QgaW1wYWN0 IHRoZSBwcmV2aW91c2x5IG5lZ290aWF0ZWQgVExTIHJvbGVzLg0KDQogICBGb3IgYSBVRFAvRFRM UyBjb25uZWN0aW9uIGVzdGFibGlzaGVkIHVzaW5nIHRoZSBhbiBTRFAgb2ZmZXIvYW5zd2VyDQog ICBleGNoYW5nZSwgZWl0aGVyIHBhcnR5IGNhbiBiZSB0aGUgRFRMUyBzZXJ2ZXIgZGVwZW5kaW5n IG9uIHRoZSBzZXR1cA0KICAgYXR0cmlidXRlcyBleGNoYW5nZWQ7IGV4YW1wbGVzIGNhbiBiZSBm b3VuZCBpbiBbMjNdLuKAnQ0KDQpGaXJzdCwgd2UgYWxyZWFkeSBlYXJsaWVyIGRpc2N1c3NlZCB0 aGF0IHRoZSBhY3RpdmUgVENQIGVuZHBvaW50IGlzIHJlc3BvbnNpYmxlIGZvciByZS1lc3RhYmxp c2hpbmcgdGhlIFRDUCBjb25uZWN0aW9uLCBhbmQgdGhhdCB3aWxsIGJlIGNvcnJlY3RlZCBpbiB0 aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KWWVzLg0KDQoNCkhvd2V2ZXIsIHdlIGhh dmUgZGlzY3Vzc2VkIGEgc2ltaWxhciB0b3BpYyBpbiBDTFVFLCBhbmQgd2Ugd2VyZSB3b25kZXJp bmcgd2hldGhlciBpdCB3b3VsZCBiZSBnb29kIHRoYXQsIHdob2V2ZXIgZGV0ZWN0cyBhIGNvbm5l Y3Rpb24gZmFpbHVyZSwgc2VuZHMgYSBuZXcgb2ZmZXIgaW4gb3JkZXIgdG8gcmUtZXN0YWJsaXNo IHRoZSBjb25uZWN0aW9uLiBJdCBkb2VzIG5vdCBtYXR0ZXIgaWYgYm90aCBlbmRwb2ludHMgc2Vu ZCBhbiBvZmZlciDigJMgdGhlIG9mZmVyL2Fuc3dlciByYWNlIGNvbmRpdGlvbiBydWxlcyB3aWxs IHRha2UgY2FyZSBvZiB0aGF0Lg0KDQpJbiBDTFVFLCBpcyB0aGlzIGZvciBhIFRDUC9UTFMgY29u bmVjdGlvbiwgb3IgZm9yIGEgRFRMUyBjb25uZWN0aW9uPw0KRm9yIERUTFMsIHdlIHNwZWNpZmlj YWxseSBjaG9zZSB0byBhbHRlciB0aGUgYmVoYXZpb3IsIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9u IDkuMSBvZiA0NTgzYmlzOg0KDQogICJFbmRwb2ludHMgdGhhdCB1c2UgdGhlIG9mZmVyL2Fuc3dl ciBtb2RlbCB0byBlc3RhYmxpc2ggYSBEVExTDQogICBhc3NvY2lhdGlvbiBNVVNUIHN1cHBvcnQg dGhlICdzZXR1cCcgYXR0cmlidXRlLCBhcyBkZWZpbmVkIGluIFs3XS4NCiAgIFdoZW4gRFRMUyBp cyB1c2VkIHdpdGggVURQLCB0aGUgJ3NldHVwJyBhdHRyaWJ1dGUgaW5kaWNhdGVzIHdoaWNoIG9m DQogICB0aGUgZW5kcG9pbnRzIChjbGllbnQgb3IgZmxvb3IgY29udHJvbCBzZXJ2ZXIpIGluaXRp YXRlcyB0aGUgRFRMUw0KICAgYXNzb2NpYXRpb24gc2V0dXAuICBUaGUgcmVxdWlyZW1lbnRzIGZv ciB0aGUgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlDQogICBzcGVjaWZpZWQgaW4gWzEzXSwgU2VjdGlv biA1IE1VU1QgYmUgZm9sbG93ZWQgd2hlbiB1c2luZyBEVExTLg0KDQogICAgICBJbmZvcm1hdGlv bmFsIG5vdGU6IEhvdyB0byBkZXRlcm1pbmUgd2hpY2ggZW5kcG9pbnQgdG8gaW5pdGlhdGUNCiAg ICAgIHRoZSBUTFMvRFRMUyBhc3NvY2lhdGlvbiBkZXBlbmRzIG9uIHRoZSBzZWxlY3RlZCB1bmRl cmx5aW5nDQogICAgICB0cmFuc3BvcnQuICBJdCB3YXMgZGVjaWRlZCB0byBrZWVwIHRoZSBvcmln aW5hbCBzZW1hbnRpY3MgaW4gWzE1XQ0KICAgICAgZm9yIFRDUCB0byByZXRhaW4gYmFja3dhcmRz IGNvbXBhdGliaWxpdHkuICBXaGVuIHVzaW5nIFVEUCwgdGhlDQogICAgICBwcm9jZWR1cmUgYWJv dmUgd2FzIHByZWZlcnJlZCBzaW5jZSBpdCBhZGhlcmVzIHRvIFsxM10gYXMgdXNlZCBmb3INCiAg ICAgIERUTFMtU1JUUCwgaXQgZG9lcyBub3Qgb3ZlcmxvYWQgb2ZmZXIvYW5zd2VyIHNlbWFudGlj cywgYW5kIGl0DQogICAgICB3b3JrcyBmb3Igb2ZmZXJsZXNzIElOVklURSBpbiBzY2VuYXJpb3Mg d2l0aCBCMkJVQXMuIg0KDQoNCg0KDQpTZWNvbmQsIFNlY3Rpb24gOC4xIGluIDQ1ODNiaXMgc2F5 czoNCg0KDQogICDigJxXaGVuIHRoZSBleGlzdGluZyBUQ1AgY29ubmVjdGlvbiBpcyByZXNldCBm b2xsb3dpbmcgdGhlIHJ1bGVzIGluIFs4XSwNCg0KICAgdGhlIGNsaWVudCBNVVNUIGdlbmVyYXRl IGFuIG9mZmVyIHRvd2FyZHMgdGhlIGZsb29yIGNvbnRyb2wgc2VydmVyIGluDQoNCiAgIG9yZGVy IHRvIHJlZXN0YWJsaXNoIHRoZSBjb25uZWN0aW9uLiAgSWYgYSBUQ1AgY29ubmVjdGlvbiBjYW5u b3QNCg0KICAgZGVsaXZlciBhIEJGQ1AgbWVzc2FnZSBhbmQgdGltZXMgb3V0LCB0aGUgZW50aXR5 IHRoYXQgYXR0ZW1wdGVkIHRvDQoNCiAgIHNlbmQgdGhlIG1lc3NhZ2UgKGkuZS4sIHRoZSBvbmUg dGhhdCBkZXRlY3RlZCB0aGUgVENQIHRpbWVvdXQpIE1VU1QNCg0KICAgZ2VuZXJhdGUgYW4gb2Zm ZXIgaW4gb3JkZXIgdG8gcmVlc3RhYmxpc2ggdGhlIFRDUCBjb25uZWN0aW9uLuKAnQ0KDQoNCg0K DQpJIGFtIG5vdCBzdXJlIHdoYXQgaXMgbWVhbnQgYnkg4oCcVENQIGNvbm5lY3Rpb24gaXMgcmVz ZXQgZm9sbG93aW5nIHRoZSBydWxlcyBpbiBbOF3igJ0uIFdoaWNoIHJ1bGVzIGFyZSB5b3UgcmVm ZXJyaW5nIHRvPw0KDQpSZXNldCBtZWFucyBjbG9zZWQgYW5kIHJlZXN0YWJsaXNoZWQuIFRoZSB3 b3JkIOKAnHJlc2V04oCdIHdhcyB1c2VkIGluIFJGQyA0NTgyIGFuZCByZXVzZWQgaW4gNDU4MmJp cy4gUGVyaGFwcyB3ZSBzaG91bGQgY2hhbmdlIGl0IGNsb3NlZCBhbmQgcmVlc3RhYmxpc2hlZCB0 byBhdm9pZCBjb25mdXNpb24/DQoNCg0KVGhlbiwgdGhlIHRleHQgc2F5cyB0aGF0IHRoZSBjbGll bnQgYWx3YXlzIHJlLWVzdGFibGlzaGVkIHRoZSBUQ1AgY29ubmVjdGlvbi4gSXMgdGhhdCBhbGln bmVkIHdpdGggdGhlIHRleHQgaW4gNDU4MmJpcywgc2F5aW5nIHRoYXQgdGhlIGFjdGl2ZSBwYXJ0 eSBkb2VzIHRoZSByZWVzdGFibGlzaG1lbnQ/IElzIHRoZSBjbGllbnQgYWx3YXlzIGFjdGl2ZT8N Cg0KSSB0aGluayBpdCBpcyBhIGxpdHRsZSBjb25mdXNpbmcgdGhhdCBib3RoIDQ1ODJiaXMgYW5k IDQ1ODNiaXMgZGVmaW5lcyBTRFAgT2ZmZXIvQW5zd2VyIHByb2NlZHVyZXMuIFNob3VsZG7igJl0 IHRoZXkgb25seSBiZSBpbiA0NTgzYmlzPw0KDQpZZXMsIEkgdGhpbmsgc28uIFJGQyA0NTgyIG1p eGVkIHNvbWUgU0RQIG9mZmVyL2Fuc3dlciB0ZXh0IGludG8gaXRzIHNlY3Rpb24gb24gbG93ZXIg bGF5ZXIgc2VjdXJpdHksIGFuZCA0NTgyYmlzIGZvbGxvd2VkIHN1aXQuIEl0IHdvdWxkIGJlIGJl dHRlciB0byBoYXZlIGFsbCB0aGUgZGV0YWlscyBvZiBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQg YW5kIHJlZXN0YWJsaXNobWVudCBpbiB3aGVuIHVzaW5nIFNEUCBvZmZlci9hbnN3ZXIgaW4gNDU4 M2Jpcy4NCg0KDQoNCg0KVGhpcmQsIHRoZSBsYXN0IHBhcmFncmFwaCwgdGFsa2luZyBhYm91dCBV RFAvRFRMUywgc2F5cyB0aGF0IGVpdGhlciBwYXJ0eSBjYW4gYmUgRFRMUyBzZXJ2ZXIgZGVwZW5k aW5nIG9uIHRoZSBzZXR1cCBhdHRyaWJ1dGVzIGV4Y2hhbmdlZC4gQnV0LCBub3doZXJlIGlzIGl0 IGRlc2NyaWJlZCBob3cgdGhlIHNldHVwIGF0dHJpYnV0ZSBpcyB1c2VkIHRvIGRldGVybWluZSB0 aGUgRFRMUyBzZXJ2ZXIgcm9sZSDimLoNCg0KSSBhc3N1bWUgaXQgaXMgZG9uZSBpbiB0aGUgc2Ft ZSB3YXkgYXMgZm9yIFRDUC9UTFMsIGJ1dCB0aGF0IGlzIG5vdCB3cml0dGVuIGFueXdoZXJlLg0K DQpUaGUgdGV4dCBJIHBhc3RlZCBmcm9tIDQ1ODNiaXMgYWJvdmUgZGVzY3JpYmVzIHRoaXMuIElm IHdlIHB1dCBhbGwgdGhlIGNvbm5lY3Rpb24gbWFuYWdlbWVudCBzdHVmZiBpbiA0NTgzYmlzIGlu c3RlYWQgb2YgbGVhdmluZyBpdCBzcGxpdCBhY3Jvc3MgNDU4MmJpcyBhbmQgNDU4M2JpcywgdGhp cyBzaG91bGQgYmUgY2xlYXIuDQoNCkNoZWVycywNCkNoYXJsZXMNCg0KDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmJmY3BiaXMgbWFpbGluZyBsaXN0DQpiZmNwYmlzQGlldGYub3JnPG1haWx0bzpiZmNw YmlzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZmNw YmlzDQoNCg0KDQotLQ0KIyBDaXNjbyAgICAgICAgICAgICAgICAgICAgICAgICB8ICBodHRwOi8v d3d3LmNpc2NvLmNvbS90ZWxlcHJlc2VuY2UvDQojIyB0b21rcmlzdEBjaXNjby5jb208bWFpbHRv OnRvbWtyaXN0QGNpc2NvLmNvbT4gIHwgIGh0dHA6Ly93d3cudGFuZGJlcmcuY29tDQojIyMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgaHR0cDovL2ZvbGsudWlvLm5vL3RvbWtyaS8N Cg== --_000_7594FB04B1934943A5C02806D1A2204B1D2CC87AESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDM0NDQ0NjkyOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotNjkxMTIzNzM4O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+ SSdtIHN0YXJ0aW5nIHdpdGggYWRkcmVzc2luZyB0aGlzIGxhc3QgaXNzdWUgZmlyc3Q6IFJGQyA0 NTgzIGhhcyBsaXZlZCBmaW5lIGZvciBzb21lIHllYXJzIGFuZA0KPHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZndDs8L3NwYW4+ZG8gaGF2ZSBhIG51bWJlciBvZiBpbnRlcm9wZXJhYmxlIGlt cGxlbWVudGF0aW9ucyBvdXQgdGhlcmUuIFRoaXMgaGFwcGVuZWQgd2l0aG91dA0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+c3RydWN0dXJpbmcgdGhlIE8vQSBwcm9jZWR1 cmVzIHVzaW5nIFJGQyAzMjY0IGFzIGEgYmx1ZXByaW50IGFzIHdhcyBzdWdnZXN0ZWQgZm9yIENo cmlzdGVyJ3MNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPmRyYWZ0IGlu IE1NVVNJQy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mZ3Q7PC9zcGFuPkFkZGl0aW5hbGx5LCB0aGlzIGlzc3VlIG5ldmVyIHJhaXNlZCBk dXJpbmcgU0RQIGRpcmVjdG9yYXRlIHJldmlldy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7 PC9zcGFuPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+SSBwcm9wb3Nl IHdlIGRvIG5vdCByZXN0cnVjdHVyZSByZmM0NTgzYmlzIHRoaXMgd2F5LiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ob3Rl IHRoYXQgSSBhbSBub3QgYXNraW5nIGZvciBhbnkgdGVjaG5pY2FsIGNoYW5nZXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5CdXQsIHRoZSBzdHJ1Y3R1cmUgYmVsb3cgZG9lcyBtYWtlIHRoaW5ncyBlYXNpZXIgdG8gcmVh ZC4gQnV0LCBpZiB5b3UgdGhpbmsgeW91IGNhbiBkbyBpdCBpbiBhbm90aGVyIHdheSwgZmluZS4g VGhlIGltcG9ydGFudCB0aGluZyBpcyB0byBnZXQgZXZlcnl0aGluZyBjb3ZlcmVkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyOSBN YXJjaCAyMDE0IDEyOjQ0LCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+QW5vdGhlciB0aGluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5BcyBwYXJ0IG9mIHRoZSBXR0xDIGZvciBvbmUgb2YgbXkgZHJhZnQgaW4gTU1VU0lDLCBJIHJl Y2VpdmVkIGNvbW1lbnRzIHRoYXQgdGhlIFNEUCBPL0EgcHJvY2VkdXJlcyBzaG91bGQgYmUgc3Ry dWN0dXJlZCBhY2NvcmRpbmcgdG8gUkZDIDMyNjQsIGllIOKAnFNlbmRpbmcNCiBvZiBpbml0aWFs IG9mZmVy4oCdLCDigJxNb2RpZnlpbmcgc2Vzc2lvbuKAnSwg4oCcUHJvY2Vzc2luZyBvZiBhbnN3 ZXLigJ0gZXRjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkV2ZW50 aG91Z2ggdGhpcyBpcyBub3QgTU1VU0lDLCB5b3UgbWF5IHdhbnQgdG8gY29uc2lkZXIgZG9pbmcg dGhlIHNhbWUNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9y OiMxRjQ5N0QiPko8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdh cmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48YSBuYW1lPSIxNDUwZGE3ZTJlMTU4YWE1X19NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gYmZjcGJp cyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpiZmNwYmlzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5iZmNwYmlzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiAyOSBNYXJjaCAyMDE0IDEz OjQxPGJyPg0KPGI+VG86PC9iPiBDaGFybGVzIEVja2VsIChlY2tlbGN1KTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86YmZjcGJpc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJm Y3BiaXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYmZjcGJpc10gVENQ L1RMUyBhbmQgVURQL0RUTFMgY29tbWVudHMgb24gNDU4MmJpcyBhbmQgNDU4M2JpczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBDaGFybGVzLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldpdGhvdXQgY29tbWVudGluZyBvbiBz cGVjaWZpY3MgYXQgdGhpcyBwb2ludCwgSSByZWFsbHkgdGhpbmsgd2Ugc2hvdWxkIHRyeSB0byBn ZXQgdGhlIFNEUCBPZmZlci9BbnN3ZXIgcHJvY2VkdXJlcyBpbnRvIG9uZSBwbGFjZSAoNDU4M2Jp cykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+NDU4MmJpcyBjYW4g ZGVmaW5lIGFjdGlvbnMgdGFrZW4gYnkgdGhlIERUTFMgY2xpZW50IGFuZCBzZXJ2ZXIsIGJ1dCBz aG91bGQgbm90IGRlZmluZSBob3cgdGhvc2Ugcm9sZXMgYXJlIGRldGVybWluZWQuIDQ1ODNiaXMg dGhlbiBkZWZpbmVzIGhvdyB0aGUgcm9sZXMNCiBhcmUgZGV0ZXJtaW5lZCB3aGVuIHVzaW5nIFNE UCBPL0EuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVO LVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBDaGFybGVzIEVja2VsIChl Y2tlbGN1KSBbPGEgaHJlZj0ibWFpbHRvOmVja2VsY3VAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOmVja2VsY3VAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNyBN YXJjaCAyMDE0IDAxOjExPGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZzxicj4NCjxi PkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmJmY3BiaXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5iZmNwYmlzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2JmY3BiaXNd IFRDUC9UTFMgYW5kIFVEUC9EVExTIGNvbW1lbnRzIG9uIDQ1ODJiaXMgYW5kIDQ1ODNiaXM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5IaSBDaHJpc3Rlciw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0Ij5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFRoZSBtb3JlIEkgbG9va2VkIGludG8gdGhl bSB0aGUgbW9yZSBjb21wbGV4IGFuZCB0YW5nbGVkIHRoaW5ncyBiZWNhbWUuIExldCBtZSB0cnkg dG8gd2FsayB0aHJvdWdoIHRoZSBjdXJyZW50IHN0YXRlIG9mDQogYWZmYWlycyBhbmQgdGhlbiBw cm9wb3NlIGEgcG90ZW50aWFsIHNvbHV0aW9ucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5SRkMgNDU4 MiBicmVha3MgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IGludG8gdHdvIGNhc2VzOjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPndoZW4gU0RQIG9mZmVyL2Fuc3dlciBJUyBOT1QgdXNlZDwvc3Bhbj48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+d2hlbiBTRFAgb2ZmZXIvYW5z d2VyIElTIHVzZWQ8L3NwYW4+PG86cD48L286cD48L2xpPjwvb2w+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Rm9yICgxKSwgUkZD IDQ1ODIgcG9pbnRzIHRvIFJGQyA1MDE4LiBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpcy0x MSBhZGRzIGEgcmVmZXJlbmNlIHRvIFJGQyA1MjM5IGZvciBYQ09OLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQiPlJGQyA1MDE4IGRlYWxzIHdpdGggdGhlIGNvbm5lY3Rpb24gZXN0 YWJsaXNobWVudCwgcmVlc3RhYmxpc2htZW50LCAmbmJzcDthbmQgVExTIHVzYWdlLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPlJGQyA1MjM5IHBvaW50cyBiYWNrIHRvIFJGQyA1 MDE4IGZvciBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdCI+UkZDIDUwMTggZG9lcyBub3QgZGVhbCB3aXRoIERUTFMuIFVubGVzcyB3ZSBy ZXN0cmljdCBEVExTIHRvIGNhc2VzIGluIHdoaWNoIFNEUCBvZmZlci9hbnN3ZXIgaXMgdXNlZCwg d2UgbmVlZCB0byB1cGRhdGUgUkZDIDUwMTggdG8gZGVhbCB3aXRoIERUTFMuDQogU29tZW9uZSBw bGVhc2UgdGVsbCBtZSBvdGhlcndpc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+U2VjdGlvbiA2LjIg b2YgZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXMtMTEgZGVzY3JpYmVzIGhvdyB0byBleHRl bmQgUkZDIDUwMTggd2hlbiBkZWFsaW5nIHdpdGggQkZDUCBvdmVyIFVEUCBvciBEVExTLiBJIHRo aW5rIHRoaXMgc2hvdWxkIGJlIHJlbG9jYXRlZA0KIHRvIGFuIHVwZGF0ZSB0byBSRkMgNTAxOCwg YW5kIGNvbm5lY3Rpb24gcmVlc3RhYmxpc2htZW50IHNob3VsZCBiZSBkZXNjcmliZWQgYXMgd2Vs bC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0Ij5Gb3IgKDIpLCBSRkMgNDU4MiBwcm92aWRlcyBhIHRlYXNl ciBidXQgcG9pbnRzIHRvIFJGQyA0NTgzIGZvciB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlLiBkcmFm dC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpcy0xMSBzaW1pbGFybHkgcG9pbnRzIHRvIGRyYWZ0LWll dGYtYmZjcGJpcy1yZmM0NTgzYmlzLTA5Lg0KIENocmlzdGVyIGNvbW1lbnRzIGFyZSBpbiByZWdh cmQgdG8gaW5jb25zaXN0ZW5jaWVzIGhlcmUuIEkgcHJvdmlkZWQgY29tbWVudHMgb24gdGhvc2Ug aW5saW5lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOg0KPC9iPkNocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBo cmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFu ayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+VHVlc2RheSwgTWFyY2ggMjUsIDIwMTQgYXQgMTI6MzkgUE08YnI+DQo8Yj5UbzogPC9iPiZx dW90OzxhIGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmZj cGJpc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDogPC9iPltiZmNwYmlzXSBUQ1AvVExTIGFuZCBVRFAvRFRMUyBjb21tZW50cyBvbiA0NTgy YmlzIGFuZCA0NTgzYmlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7 bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5I aSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNlY3Rpb24gNyBpbiA0NTgyYmlzLCB3aGlj aCBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAnDcuJm5ic3A7 IExvd2VyLUxheWVyIFNlY3VyaXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEJGQ1AgcmVsaWVzIG9uIGxv d2VyLWxheWVyIHNlY3VyaXR5IG1lY2hhbmlzbXMgdG8gcHJvdmlkZSByZXBsYXkgYW5kPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IGludGVncml0eSBwcm90ZWN0aW9uIGFuZCBjb25maWRlbnRpYWxpdHkuJm5ic3A7IEJG Q1AgZmxvb3IgY29udHJvbCBzZXJ2ZXJzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGFuZCBjbGllbnRzICh3aGljaCBp bmNsdWRlIGJvdGggZmxvb3IgcGFydGljaXBhbnRzIGFuZCBmbG9vciBjaGFpcnMpPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IE1VU1Qgc3VwcG9ydCBUTFMgZm9yIHRyYW5zcG9ydCBvdmVyIFRDUCBbNl0gYW5k IE1VU1Qgc3VwcG9ydCBEVExTIFs3XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBmb3IgdHJhbnNwb3J0IG92ZXIgVURQ LiZuYnNwOyBBbnkgQkZDUCBlbnRpdHkgTUFZIHN1cHBvcnQgb3RoZXIgc2VjdXJpdHk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgbWVjaGFuaXNtcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQkZDUCBlbnRpdGllcyBNVVNUIHN1 cHBvcnQsIGF0IGEgbWluaW11bSwgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRMU19SU0FfV0lUSF9BRVNfMTI4 X0NCQ19TSEEgY2lwaGVyc3VpdGUgWzZdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBXaGljaCBwYXJ0eSwg dGhlIGNsaWVudCBvciB0aGUgZmxvb3IgY29udHJvbCBzZXJ2ZXIsIGFjdHMgYXMgdGhlIFRMUy88 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgRFRMUyBzZXJ2ZXIgZGVwZW5kcyBvbiBob3cgdGhlIHVuZGVybHlpbmcgVExT L0RUTFMgY29ubmVjdGlvbiBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBlc3RhYmxpc2hlZC4mbmJzcDsgRm9yIGEg VENQL1RMUyBjb25uZWN0aW9uIGVzdGFibGlzaGVkIHVzaW5nIGFuIFNEUDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBv ZmZlci9hbnN3ZXIgZXhjaGFuZ2UgWzldLCB0aGUgYW5zd2VyZXIgKHdoaWNoIG1heSBiZSB0aGUg Y2xpZW50IG9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoZSBmbG9vciBjb250cm9sIHNlcnZlcikgYWx3YXlzIGFj dHMgYXMgdGhlIFRMUyBzZXJ2ZXIuJm5ic3A7IElmIHRoZSBUQ1A8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY29ubmVj dGlvbiBpcyBsb3N0LCB0aGUgYWN0aXZlIGVuZHBvaW50LCBpLmUuLCB0aGUgY3VycmVudCBUTFM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgY2xpZW50LCBpcyByZXNwb25zaWJsZSBmb3IgcmUtZXN0YWJsaXNoaW5nIHRo ZSBUQ1AgY29ubmVjdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVW5sZXNzIGEgbmV3IFRMUyBzZXNzaW9uIGlz IG5lZ290aWF0ZWQsIHN1YnNlcXVlbnQgU0RQIG9mZmVycyBhbmQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYW5zd2Vy cyB3aWxsIG5vdCBpbXBhY3QgdGhlIHByZXZpb3VzbHkgbmVnb3RpYXRlZCBUTFMgcm9sZXMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IEZvciBhIFVEUC9EVExTIGNvbm5lY3Rpb24gZXN0YWJsaXNoZWQgdXNp bmcgdGhlIGFuIFNEUCBvZmZlci9hbnN3ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZXhjaGFuZ2UsIGVpdGhlciBw YXJ0eSBjYW4gYmUgdGhlIERUTFMgc2VydmVyIGRlcGVuZGluZyBvbiB0aGUgc2V0dXA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgYXR0cmlidXRlcyBleGNoYW5nZWQ7IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiBbMjNd LuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpyZWQiPkZpcnN0PC9zcGFuPjwvYj4sIHdlIGFscmVhZHkgZWFybGllciBkaXNjdXNzZWQg dGhhdCB0aGUgYWN0aXZlIFRDUCBlbmRwb2ludCBpcyByZXNwb25zaWJsZSBmb3IgcmUtZXN0YWJs aXNoaW5nIHRoZSBUQ1AgY29ubmVjdGlvbiwgYW5kIHRoYXQgd2lsbCBiZSBjb3JyZWN0ZWQNCiBp biB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdCI+WWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3dl dmVyLCB3ZSBoYXZlIGRpc2N1c3NlZCBhIHNpbWlsYXIgdG9waWMgaW4gQ0xVRSwgYW5kIHdlIHdl cmUgd29uZGVyaW5nIHdoZXRoZXIgaXQgd291bGQgYmUgZ29vZCB0aGF0LCB3aG9ldmVyIGRldGVj dHMgYSBjb25uZWN0aW9uIGZhaWx1cmUsIHNlbmRzIGEgbmV3IG9mZmVyIGluIG9yZGVyIHRvIHJl LWVzdGFibGlzaA0KIHRoZSBjb25uZWN0aW9uLiBJdCBkb2VzIG5vdCBtYXR0ZXIgaWYgYm90aCBl bmRwb2ludHMgc2VuZCBhbiBvZmZlciDigJMgdGhlIG9mZmVyL2Fuc3dlciByYWNlIGNvbmRpdGlv biBydWxlcyB3aWxsIHRha2UgY2FyZSBvZiB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0Ij5JbiBDTFVFLCBpcyB0aGlzIGZvciBhIFRDUC9UTFMgY29ubmVjdGlvbiwgb3Ig Zm9yIGEgRFRMUyBjb25uZWN0aW9uPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi PkZvciBEVExTLCB3ZSBzcGVjaWZpY2FsbHkgY2hvc2UgdG8gYWx0ZXIgdGhlIGJlaGF2aW9yLCBh cyBkZXNjcmliZWQgaW4gc2VjdGlvbiA5LjEgb2YgNDU4M2Jpczo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 Ij4mbmJzcDsgJnF1b3Q7RW5kcG9pbnRzIHRoYXQgdXNlIHRoZSBvZmZlci9hbnN3ZXIgbW9kZWwg dG8gZXN0YWJsaXNoIGEgRFRMUzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDthc3NvY2lhdGlvbiBN VVNUIHN1cHBvcnQgdGhlICdzZXR1cCcgYXR0cmlidXRlLCBhcyBkZWZpbmVkIGluIFs3XS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwO1doZW4gRFRMUyBpcyB1c2VkIHdpdGggVURQLCB0aGUgJ3NldHVwJyBhdHRyaWJ1dGUg aW5kaWNhdGVzIHdoaWNoIG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt0aGUgZW5kcG9pbnRzIChjbGllbnQgb3IgZmxv b3IgY29udHJvbCBzZXJ2ZXIpIGluaXRpYXRlcyB0aGUgRFRMUzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7YXNzb2NpYXRp b24gc2V0dXAuICZuYnNwO1RoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBvZmZlci9hbnN3ZXIgZXhj aGFuZ2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7ICZuYnNwO3NwZWNpZmllZCBpbiBbMTNdLCBTZWN0aW9uIDUgTVVTVCBiZSBmb2xs b3dlZCB3aGVuIHVzaW5nIERUTFMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmZvcm1hdGlvbmFs IG5vdGU6IEhvdyB0byBkZXRlcm1pbmUgd2hpY2ggZW5kcG9pbnQgdG8gaW5pdGlhdGU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgdGhlIFRMUy9EVExTIGFzc29jaWF0aW9uIGRlcGVuZHMgb24gdGhlIHNlbGVj dGVkIHVuZGVybHlpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJhbnNwb3J0LiAmbmJzcDtJdCB3YXMg ZGVjaWRlZCB0byBrZWVwIHRoZSBvcmlnaW5hbCBzZW1hbnRpY3MgaW4gWzE1XTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyBmb3IgVENQIHRvIHJldGFpbiBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4gJm5ic3A7 V2hlbiB1c2luZyBVRFAsIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBwcm9jZWR1cmUgYWJvdmUgd2Fz IHByZWZlcnJlZCBzaW5jZSBpdCBhZGhlcmVzIHRvIFsxM10gYXMgdXNlZCBmb3I8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgRFRMUy1TUlRQLCBpdCBkb2VzIG5vdCBvdmVybG9hZCBvZmZlci9hbnN3ZXIgc2Vt YW50aWNzLCBhbmQgaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgd29ya3MgZm9yIG9mZmVybGVzcyBJTlZJ VEUgaW4gc2NlbmFyaW9zIHdpdGggQjJCVUFzLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjpyZWQiPlNlY29uZDwvc3Bhbj48L2I+LCBTZWN0aW9uIDguMSBpbiA0NTgzYmlz IHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsg4oCcV2hlbiB0aGUgZXhp c3RpbmcgVENQIGNvbm5lY3Rpb24gaXMgcmVzZXQgZm9sbG93aW5nIHRoZSBydWxlcyBpbiBbOF0s PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyB0 aGUgY2xpZW50IE1VU1QgZ2VuZXJhdGUgYW4gb2ZmZXIgdG93YXJkcyB0aGUgZmxvb3IgY29udHJv bCBzZXJ2ZXIgaW48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7Jm5ic3A7IG9yZGVyIHRvIHJlZXN0YWJsaXNoIHRoZSBjb25uZWN0aW9uLiZuYnNwOyBJZiBh IFRDUCBjb25uZWN0aW9uIGNhbm5vdDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZGVsaXZlciBhIEJGQ1AgbWVzc2FnZSBhbmQgdGltZXMgb3V0 LCB0aGUgZW50aXR5IHRoYXQgYXR0ZW1wdGVkIHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBzZW5kIHRoZSBtZXNzYWdlIChpLmUuLCB0aGUg b25lIHRoYXQgZGV0ZWN0ZWQgdGhlIFRDUCB0aW1lb3V0KSBNVVNUPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBnZW5lcmF0ZSBhbiBvZmZlciBp biBvcmRlciB0byByZWVzdGFibGlzaCB0aGUgVENQIGNvbm5lY3Rpb24u4oCdPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhbSBub3Qgc3VyZSB3aGF0IGlzIG1lYW50IGJ5IOKAnFRD UCBjb25uZWN0aW9uIGlzIHJlc2V0IGZvbGxvd2luZyB0aGUgcnVsZXMgaW4gWzhd4oCdLiBXaGlj aCBydWxlcyBhcmUgeW91IHJlZmVycmluZyB0bz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+UmVzZXQgbWVhbnMgY2xvc2VkIGFuZCByZWVzdGFibGlzaGVkLiBUaGUgd29yZCDi gJxyZXNldOKAnSB3YXMgdXNlZCBpbiBSRkMgNDU4MiBhbmQgcmV1c2VkIGluIDQ1ODJiaXMuIFBl cmhhcHMgd2Ugc2hvdWxkIGNoYW5nZSBpdCBjbG9zZWQgYW5kIHJlZXN0YWJsaXNoZWQNCiB0byBh dm9pZCBjb25mdXNpb24/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZW4s IHRoZSB0ZXh0IHNheXMgdGhhdCB0aGUgY2xpZW50IGFsd2F5cyByZS1lc3RhYmxpc2hlZCB0aGUg VENQIGNvbm5lY3Rpb24uIElzIHRoYXQgYWxpZ25lZCB3aXRoIHRoZSB0ZXh0IGluIDQ1ODJiaXMs IHNheWluZyB0aGF0IHRoZSBhY3RpdmUgcGFydHkgZG9lcyB0aGUgcmVlc3RhYmxpc2htZW50PyBJ cw0KIHRoZSBjbGllbnQgYWx3YXlzIGFjdGl2ZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkkgdGhpbmsgaXQgaXMgYSBsaXR0bGUgY29uZnVzaW5nIHRoYXQgYm90aCA0NTgyYmlzIGFuZCA0 NTgzYmlzIGRlZmluZXMgU0RQIE9mZmVyL0Fuc3dlciBwcm9jZWR1cmVzLiBTaG91bGRu4oCZdCB0 aGV5IG9ubHkgYmUgaW4gNDU4M2Jpcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dCI+WWVzLCBJIHRoaW5rIHNvLiBSRkMgNDU4MiBtaXhlZCBzb21lIFNEUCBvZmZlci9hbnN3ZXIg dGV4dCBpbnRvIGl0cyBzZWN0aW9uIG9uIGxvd2VyIGxheWVyIHNlY3VyaXR5LCBhbmQgNDU4MmJp cyBmb2xsb3dlZCBzdWl0LiBJdCB3b3VsZCBiZSBiZXR0ZXINCiB0byBoYXZlIGFsbCB0aGUgZGV0 YWlscyBvZiBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgYW5kIHJlZXN0YWJsaXNobWVudCBpbiB3 aGVuIHVzaW5nIFNEUCBvZmZlci9hbnN3ZXIgaW4gNDU4M2Jpcy4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVD NERGIDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5UaGlyZDwvc3Bhbj48L2I+LCB0aGUgbGFzdCBw YXJhZ3JhcGgsIHRhbGtpbmcgYWJvdXQgVURQL0RUTFMsIHNheXMgdGhhdCBlaXRoZXIgcGFydHkg Y2FuIGJlIERUTFMgc2VydmVyIGRlcGVuZGluZyBvbiB0aGUgc2V0dXAgYXR0cmlidXRlcyBleGNo YW5nZWQuIEJ1dCwNCiBub3doZXJlIGlzIGl0IGRlc2NyaWJlZCBob3cgdGhlIHNldHVwIGF0dHJp YnV0ZSBpcyB1c2VkIHRvIGRldGVybWluZSB0aGUgRFRMUyBzZXJ2ZXIgcm9sZQ0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+Sjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkkgYXNzdW1lIGl0IGlzIGRvbmUgaW4gdGhlIHNhbWUgd2F5IGFzIGZvciBUQ1AvVExT LCBidXQgdGhhdCBpcyBub3Qgd3JpdHRlbiBhbnl3aGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+VGhlIHRleHQgSSBwYXN0ZWQgZnJvbSA0NTgzYmlzIGFib3ZlIGRlc2NyaWJlcyB0aGlzLiBJ ZiB3ZSBwdXQgYWxsIHRoZSBjb25uZWN0aW9uIG1hbmFnZW1lbnQgc3R1ZmYgaW4gNDU4M2JpcyBp bnN0ZWFkIG9mIGxlYXZpbmcgaXQgc3BsaXQgYWNyb3NzIDQ1ODJiaXMgYW5kIDQ1ODNiaXMsIHRo aXMgc2hvdWxkDQogYmUgY2xlYXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoYXJsZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj QjVDNERGIDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaHJp c3RlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpiZmNwYmlzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpiZmNw YmlzQGlldGYub3JnIj5iZmNwYmlzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJpcyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJpczwvYT48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tIDxicj4NCiMgQ2lzY28gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDs8YSBo cmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWxlcHJlc2VuY2UvIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL3d3dy5jaXNjby5jb20vdGVsZXByZXNlbmNlLzwvYT48YnI+DQojIyA8YSBocmVmPSJt YWlsdG86dG9ta3Jpc3RAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dG9ta3Jpc3RAY2lzY28u Y29tPC9hPiAmbmJzcDt8ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cudGFuZGJlcmcuY29tIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy50YW5kYmVyZy5jb208L2E+PGJyPg0KIyMjICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7PGEgaHJl Zj0iaHR0cDovL2ZvbGsudWlvLm5vL3RvbWtyaS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZm9s ay51aW8ubm8vdG9ta3JpLzwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D2CC87AESESSMB209erics_-- From nobody Wed Apr 16 13:36:51 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAEC1A0286 for ; Wed, 16 Apr 2014 13:36:48 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VjdqjomaTKE for ; Wed, 16 Apr 2014 13:36:42 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id A6D5E1A032A for ; Wed, 16 Apr 2014 13:36:41 -0700 (PDT) X-AuditID: c1b4fb3a-f79f36d0000039bf-2a-534ee9d59b0d Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 70.EF.14783.5D9EE435; Wed, 16 Apr 2014 22:36:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Wed, 16 Apr 2014 22:36:37 +0200 From: Christer Holmberg To: Tom Kristensen <2mkristensen@gmail.com> Thread-Topic: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Thread-Index: AQHPSUic50RqEV5EM0G8qoAclTNxQpr39BsggByH94CAAFfBAA== Date: Wed, 16 Apr 2014 20:36:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2CC894@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D26AD25@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2CC894ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM+Jvje7Vl37BBqcWm1psOf6OxeLfuqNM FptmfWGzuHLkF5sDi8eU3xtZPXbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSujF97jrAWPNjD XLHg9FLGBsYZG5m7GDk4JARMJCZ+9u1i5AQyxSQu3FvP1sXIxSEkcJRR4sDOScwQzhJGidvT t7CANLAJWEh0/9MGaRAR0JY4fPogM4jNLFAv0b18EwuILSzgLfHi3ypmiBofibvXutghbCeJ y4cmgcVZBFQlZq+4wwpi8wr4Spxp/wrWKySwk1Hiw4wEEJtTIFDix7epYDWMQMd9P7WGCWKX uMStJ/OZII4WkFiy5zwzhC0q8fLxP1YIW0lixfZLjBD1+RKPNi1mhNglKHFy5hOWCYyis5CM moWkbBaSsllAHzMLaEqs36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYyixanFxbnpRkZ6qUWZ ycXF+Xl6eaklmxiB0Xhwy2+rHYwHnzseYhTgYFTi4WVT8wsWYk0sK67MPcQozcGiJM47aZF7 sJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGWUWTFhtuYr4sH/XQ1PCx2C9nJ4NC1UOO61gd Q54LBn5aUhFXKPBbJD3mLeM8d+5l8b95fwbtL+dKm1x/PZTXoc3l+Vx7U3k2fp/zYZVqfxxU 5mfduxjx85HFnNpwB2uF/RV7fec9N77l0rfTZNqFzy6rdS0+fLjmq6To8WzydP4TnTPDdjsr sRRnJBpqMRcVJwIAPO3WhKcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/uvn0hZQDWlS-ZPLyCUGwltxf03g Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , Tom Kristensen Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 20:36:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2CC894ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JdCB3b3VsZCBiZSBtdWNoIGNsZWFyZXIgYW5kIGxlc3MgY29uZnVzaW5nIHRvIGhh dmUgYWxsIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIHJlbGF0ZWQgPnByb2NlZHVyZXMgaW4gcmZjNDU4 M2Jpcy4gSSBhZ3JlZSBhbmQgaGF2ZSBzdGFydGVkIHdvcmtpbmcgb24gaXQsIGkuZS4gbW92aW5n IGNvbnRlbnQgdG8gPnJmYzQ1ODNiaXMgYW5kIHBvbGlzaGluZyB0ZXh0IGluIHJmYzQ1ODJiaXMu DQo+DQo+SG93ZXZlciwgd2hhdCBkbyBwZW9wbGUgb24gdGhpcyBsaXN0IHRoaW5rIGFib3V0IHRo ZSBjb25jZXJucyBhbmQgc2tldGNoIGZvciBzb2x2aW5nIHRoaXMgPmlzc3VlIHByb3Bvc2VkIGJ5 IENoYXJsZXM/DQo+DQo+QW5kIHNwZWNpZmljYWxseTogRG8gd2Ugd2FudCB0byAoaSkgdXBkYXRl IFJGQyA1MDE4IHdpdGggVURQIC8gRFRMUyBvciBkbyB3ZSB0aGluayBpdCBpcyA+ZXZlbiB0aGlu a2FibGUvZG9hYmxlIHRvIChpaSkgc3BlY2lmeSBVRFAgLyBEVExTIGFzIGEgdHJhbnNwb3J0IG9u bHkgd2hlbiBvZmZlci9hbnN3ZXIgaXMgPnVzZWQ/IChOb3QgYSBjbGVhbiBhcHByb2FjaCwgYnV0 IHZlcnkgcHJhZ21hdGljIDspICkNCg0KV2VsbCwgaGFzIGFueW9uZSByZXF1ZXN0ZWQgYSBub24t Ty9BIG1lY2hhbmlzbT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAyOSBNYXJjaCAy MDE0IDEyOjQwLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpIENo YXJsZXMsDQoNCldpdGhvdXQgY29tbWVudGluZyBvbiBzcGVjaWZpY3MgYXQgdGhpcyBwb2ludCwg SSByZWFsbHkgdGhpbmsgd2Ugc2hvdWxkIHRyeSB0byBnZXQgdGhlIFNEUCBPZmZlci9BbnN3ZXIg cHJvY2VkdXJlcyBpbnRvIG9uZSBwbGFjZSAoNDU4M2JpcykuDQoNCjQ1ODJiaXMgY2FuIGRlZmlu ZSBhY3Rpb25zIHRha2VuIGJ5IHRoZSBEVExTIGNsaWVudCBhbmQgc2VydmVyLCBidXQgc2hvdWxk IG5vdCBkZWZpbmUgaG93IHRob3NlIHJvbGVzIGFyZSBkZXRlcm1pbmVkLiA0NTgzYmlzIHRoZW4g ZGVmaW5lcyBob3cgdGhlIHJvbGVzIGFyZSBkZXRlcm1pbmVkIHdoZW4gdXNpbmcgU0RQIE8vQS4N Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkg W21haWx0bzplY2tlbGN1QGNpc2NvLmNvbTxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+XQ0KU2Vu dDogMjcgTWFyY2ggMjAxNCAwMToxMQ0KVG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzogYmZjcGJp c0BpZXRmLm9yZzxtYWlsdG86YmZjcGJpc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbYmZjcGJp c10gVENQL1RMUyBhbmQgVURQL0RUTFMgY29tbWVudHMgb24gNDU4MmJpcyBhbmQgNDU4M2Jpcw0K DQpIaSBDaHJpc3RlciwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBUaGUgbW9yZSBJIGxv b2tlZCBpbnRvIHRoZW0gdGhlIG1vcmUgY29tcGxleCBhbmQgdGFuZ2xlZCB0aGluZ3MgYmVjYW1l LiBMZXQgbWUgdHJ5IHRvIHdhbGsgdGhyb3VnaCB0aGUgY3VycmVudCBzdGF0ZSBvZiBhZmZhaXJz IGFuZCB0aGVuIHByb3Bvc2UgYSBwb3RlbnRpYWwgc29sdXRpb25zLg0KDQpSRkMgNDU4MiBicmVh a3MgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IGludG8gdHdvIGNhc2VzOg0KDQogIDEuICB3aGVu IFNEUCBvZmZlci9hbnN3ZXIgSVMgTk9UIHVzZWQNCiAgMi4gIHdoZW4gU0RQIG9mZmVyL2Fuc3dl ciBJUyB1c2VkDQpGb3IgKDEpLCBSRkMgNDU4MiBwb2ludHMgdG8gUkZDIDUwMTguIGRyYWZ0LWll dGYtYmZjcGJpcy1yZmM0NTgyYmlzLTExIGFkZHMgYSByZWZlcmVuY2UgdG8gUkZDIDUyMzkgZm9y IFhDT04uDQpSRkMgNTAxOCBkZWFscyB3aXRoIHRoZSBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQs IHJlZXN0YWJsaXNobWVudCwgIGFuZCBUTFMgdXNhZ2UuDQpSRkMgNTIzOSBwb2ludHMgYmFjayB0 byBSRkMgNTAxOCBmb3IgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50Lg0KUkZDIDUwMTggZG9lcyBu b3QgZGVhbCB3aXRoIERUTFMuIFVubGVzcyB3ZSByZXN0cmljdCBEVExTIHRvIGNhc2VzIGluIHdo aWNoIFNEUCBvZmZlci9hbnN3ZXIgaXMgdXNlZCwgd2UgbmVlZCB0byB1cGRhdGUgUkZDIDUwMTgg dG8gZGVhbCB3aXRoIERUTFMuIFNvbWVvbmUgcGxlYXNlIHRlbGwgbWUgb3RoZXJ3aXNlLg0KDQpT ZWN0aW9uIDYuMiBvZiBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpcy0xMSBkZXNjcmliZXMg aG93IHRvIGV4dGVuZCBSRkMgNTAxOCB3aGVuIGRlYWxpbmcgd2l0aCBCRkNQIG92ZXIgVURQIG9y IERUTFMuIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgcmVsb2NhdGVkIHRvIGFuIHVwZGF0ZSB0byBS RkMgNTAxOCwgYW5kIGNvbm5lY3Rpb24gcmVlc3RhYmxpc2htZW50IHNob3VsZCBiZSBkZXNjcmli ZWQgYXMgd2VsbC4NCg0KRm9yICgyKSwgUkZDIDQ1ODIgcHJvdmlkZXMgYSB0ZWFzZXIgYnV0IHBv aW50cyB0byBSRkMgNDU4MyBmb3IgdGhlIG5vcm1hdGl2ZSBsYW5ndWFnZS4gZHJhZnQtaWV0Zi1i ZmNwYmlzLXJmYzQ1ODJiaXMtMTEgc2ltaWxhcmx5IHBvaW50cyB0byBkcmFmdC1pZXRmLWJmY3Bi aXMtcmZjNDU4M2Jpcy0wOS4gQ2hyaXN0ZXIgY29tbWVudHMgYXJlIGluIHJlZ2FyZCB0byBpbmNv bnNpc3RlbmNpZXMgaGVyZS4gSSBwcm92aWRlZCBjb21tZW50cyBvbiB0aG9zZSBpbmxpbmUuDQoN CkZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208 bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBN YXJjaCAyNSwgMjAxNCBhdCAxMjozOSBQTQ0KVG86ICJiZmNwYmlzQGlldGYub3JnPG1haWx0bzpi ZmNwYmlzQGlldGYub3JnPiIgPGJmY3BiaXNAaWV0Zi5vcmc8bWFpbHRvOmJmY3BiaXNAaWV0Zi5v cmc+Pg0KU3ViamVjdDogW2JmY3BiaXNdIFRDUC9UTFMgYW5kIFVEUC9EVExTIGNvbW1lbnRzIG9u IDQ1ODJiaXMgYW5kIDQ1ODNiaXMNCg0KSGksDQoNClNlY3Rpb24gNyBpbiA0NTgyYmlzLCB3aGlj aCBzYXlzOg0KDQrigJw3LiAgTG93ZXItTGF5ZXIgU2VjdXJpdHkNCg0KICAgQkZDUCByZWxpZXMg b24gbG93ZXItbGF5ZXIgc2VjdXJpdHkgbWVjaGFuaXNtcyB0byBwcm92aWRlIHJlcGxheSBhbmQN CiAgIGludGVncml0eSBwcm90ZWN0aW9uIGFuZCBjb25maWRlbnRpYWxpdHkuICBCRkNQIGZsb29y IGNvbnRyb2wgc2VydmVycw0KICAgYW5kIGNsaWVudHMgKHdoaWNoIGluY2x1ZGUgYm90aCBmbG9v ciBwYXJ0aWNpcGFudHMgYW5kIGZsb29yIGNoYWlycykNCg0KICAgTVVTVCBzdXBwb3J0IFRMUyBm b3IgdHJhbnNwb3J0IG92ZXIgVENQIFs2XSBhbmQgTVVTVCBzdXBwb3J0IERUTFMgWzddDQogICBm b3IgdHJhbnNwb3J0IG92ZXIgVURQLiAgQW55IEJGQ1AgZW50aXR5IE1BWSBzdXBwb3J0IG90aGVy IHNlY3VyaXR5DQogICBtZWNoYW5pc21zLg0KDQogICBCRkNQIGVudGl0aWVzIE1VU1Qgc3VwcG9y dCwgYXQgYSBtaW5pbXVtLCB0aGUNCiAgIFRMU19SU0FfV0lUSF9BRVNfMTI4X0NCQ19TSEEgY2lw aGVyc3VpdGUgWzZdLg0KDQogICBXaGljaCBwYXJ0eSwgdGhlIGNsaWVudCBvciB0aGUgZmxvb3Ig Y29udHJvbCBzZXJ2ZXIsIGFjdHMgYXMgdGhlIFRMUy8NCiAgIERUTFMgc2VydmVyIGRlcGVuZHMg b24gaG93IHRoZSB1bmRlcmx5aW5nIFRMUy9EVExTIGNvbm5lY3Rpb24gaXMNCiAgIGVzdGFibGlz aGVkLiAgRm9yIGEgVENQL1RMUyBjb25uZWN0aW9uIGVzdGFibGlzaGVkIHVzaW5nIGFuIFNEUA0K ICAgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIFs5XSwgdGhlIGFuc3dlcmVyICh3aGljaCBtYXkgYmUg dGhlIGNsaWVudCBvcg0KICAgdGhlIGZsb29yIGNvbnRyb2wgc2VydmVyKSBhbHdheXMgYWN0cyBh cyB0aGUgVExTIHNlcnZlci4gIElmIHRoZSBUQ1ANCiAgIGNvbm5lY3Rpb24gaXMgbG9zdCwgdGhl IGFjdGl2ZSBlbmRwb2ludCwgaS5lLiwgdGhlIGN1cnJlbnQgVExTDQogICBjbGllbnQsIGlzIHJl c3BvbnNpYmxlIGZvciByZS1lc3RhYmxpc2hpbmcgdGhlIFRDUCBjb25uZWN0aW9uLg0KICAgVW5s ZXNzIGEgbmV3IFRMUyBzZXNzaW9uIGlzIG5lZ290aWF0ZWQsIHN1YnNlcXVlbnQgU0RQIG9mZmVy cyBhbmQNCiAgIGFuc3dlcnMgd2lsbCBub3QgaW1wYWN0IHRoZSBwcmV2aW91c2x5IG5lZ290aWF0 ZWQgVExTIHJvbGVzLg0KDQogICBGb3IgYSBVRFAvRFRMUyBjb25uZWN0aW9uIGVzdGFibGlzaGVk IHVzaW5nIHRoZSBhbiBTRFAgb2ZmZXIvYW5zd2VyDQogICBleGNoYW5nZSwgZWl0aGVyIHBhcnR5 IGNhbiBiZSB0aGUgRFRMUyBzZXJ2ZXIgZGVwZW5kaW5nIG9uIHRoZSBzZXR1cA0KICAgYXR0cmli dXRlcyBleGNoYW5nZWQ7IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiBbMjNdLuKAnQ0KDQpGaXJz dCwgd2UgYWxyZWFkeSBlYXJsaWVyIGRpc2N1c3NlZCB0aGF0IHRoZSBhY3RpdmUgVENQIGVuZHBv aW50IGlzIHJlc3BvbnNpYmxlIGZvciByZS1lc3RhYmxpc2hpbmcgdGhlIFRDUCBjb25uZWN0aW9u LCBhbmQgdGhhdCB3aWxsIGJlIGNvcnJlY3RlZCBpbiB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBk cmFmdC4NCg0KWWVzLg0KDQoNCkhvd2V2ZXIsIHdlIGhhdmUgZGlzY3Vzc2VkIGEgc2ltaWxhciB0 b3BpYyBpbiBDTFVFLCBhbmQgd2Ugd2VyZSB3b25kZXJpbmcgd2hldGhlciBpdCB3b3VsZCBiZSBn b29kIHRoYXQsIHdob2V2ZXIgZGV0ZWN0cyBhIGNvbm5lY3Rpb24gZmFpbHVyZSwgc2VuZHMgYSBu ZXcgb2ZmZXIgaW4gb3JkZXIgdG8gcmUtZXN0YWJsaXNoIHRoZSBjb25uZWN0aW9uLiBJdCBkb2Vz IG5vdCBtYXR0ZXIgaWYgYm90aCBlbmRwb2ludHMgc2VuZCBhbiBvZmZlciDigJMgdGhlIG9mZmVy L2Fuc3dlciByYWNlIGNvbmRpdGlvbiBydWxlcyB3aWxsIHRha2UgY2FyZSBvZiB0aGF0Lg0KDQpJ biBDTFVFLCBpcyB0aGlzIGZvciBhIFRDUC9UTFMgY29ubmVjdGlvbiwgb3IgZm9yIGEgRFRMUyBj b25uZWN0aW9uPw0KRm9yIERUTFMsIHdlIHNwZWNpZmljYWxseSBjaG9zZSB0byBhbHRlciB0aGUg YmVoYXZpb3IsIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDkuMSBvZiA0NTgzYmlzOg0KDQogICJF bmRwb2ludHMgdGhhdCB1c2UgdGhlIG9mZmVyL2Fuc3dlciBtb2RlbCB0byBlc3RhYmxpc2ggYSBE VExTDQogICBhc3NvY2lhdGlvbiBNVVNUIHN1cHBvcnQgdGhlICdzZXR1cCcgYXR0cmlidXRlLCBh cyBkZWZpbmVkIGluIFs3XS4NCiAgIFdoZW4gRFRMUyBpcyB1c2VkIHdpdGggVURQLCB0aGUgJ3Nl dHVwJyBhdHRyaWJ1dGUgaW5kaWNhdGVzIHdoaWNoIG9mDQogICB0aGUgZW5kcG9pbnRzIChjbGll bnQgb3IgZmxvb3IgY29udHJvbCBzZXJ2ZXIpIGluaXRpYXRlcyB0aGUgRFRMUw0KICAgYXNzb2Np YXRpb24gc2V0dXAuICBUaGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgb2ZmZXIvYW5zd2VyIGV4Y2hh bmdlDQogICBzcGVjaWZpZWQgaW4gWzEzXSwgU2VjdGlvbiA1IE1VU1QgYmUgZm9sbG93ZWQgd2hl biB1c2luZyBEVExTLg0KDQogICAgICBJbmZvcm1hdGlvbmFsIG5vdGU6IEhvdyB0byBkZXRlcm1p bmUgd2hpY2ggZW5kcG9pbnQgdG8gaW5pdGlhdGUNCiAgICAgIHRoZSBUTFMvRFRMUyBhc3NvY2lh dGlvbiBkZXBlbmRzIG9uIHRoZSBzZWxlY3RlZCB1bmRlcmx5aW5nDQogICAgICB0cmFuc3BvcnQu ICBJdCB3YXMgZGVjaWRlZCB0byBrZWVwIHRoZSBvcmlnaW5hbCBzZW1hbnRpY3MgaW4gWzE1XQ0K ICAgICAgZm9yIFRDUCB0byByZXRhaW4gYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuICBXaGVuIHVz aW5nIFVEUCwgdGhlDQogICAgICBwcm9jZWR1cmUgYWJvdmUgd2FzIHByZWZlcnJlZCBzaW5jZSBp dCBhZGhlcmVzIHRvIFsxM10gYXMgdXNlZCBmb3INCiAgICAgIERUTFMtU1JUUCwgaXQgZG9lcyBu b3Qgb3ZlcmxvYWQgb2ZmZXIvYW5zd2VyIHNlbWFudGljcywgYW5kIGl0DQogICAgICB3b3JrcyBm b3Igb2ZmZXJsZXNzIElOVklURSBpbiBzY2VuYXJpb3Mgd2l0aCBCMkJVQXMuIg0KDQoNCg0KDQpT ZWNvbmQsIFNlY3Rpb24gOC4xIGluIDQ1ODNiaXMgc2F5czoNCg0KDQogICDigJxXaGVuIHRoZSBl eGlzdGluZyBUQ1AgY29ubmVjdGlvbiBpcyByZXNldCBmb2xsb3dpbmcgdGhlIHJ1bGVzIGluIFs4 XSwNCg0KICAgdGhlIGNsaWVudCBNVVNUIGdlbmVyYXRlIGFuIG9mZmVyIHRvd2FyZHMgdGhlIGZs b29yIGNvbnRyb2wgc2VydmVyIGluDQoNCiAgIG9yZGVyIHRvIHJlZXN0YWJsaXNoIHRoZSBjb25u ZWN0aW9uLiAgSWYgYSBUQ1AgY29ubmVjdGlvbiBjYW5ub3QNCg0KICAgZGVsaXZlciBhIEJGQ1Ag bWVzc2FnZSBhbmQgdGltZXMgb3V0LCB0aGUgZW50aXR5IHRoYXQgYXR0ZW1wdGVkIHRvDQoNCiAg IHNlbmQgdGhlIG1lc3NhZ2UgKGkuZS4sIHRoZSBvbmUgdGhhdCBkZXRlY3RlZCB0aGUgVENQIHRp bWVvdXQpIE1VU1QNCg0KICAgZ2VuZXJhdGUgYW4gb2ZmZXIgaW4gb3JkZXIgdG8gcmVlc3RhYmxp c2ggdGhlIFRDUCBjb25uZWN0aW9uLuKAnQ0KDQoNCg0KDQpJIGFtIG5vdCBzdXJlIHdoYXQgaXMg bWVhbnQgYnkg4oCcVENQIGNvbm5lY3Rpb24gaXMgcmVzZXQgZm9sbG93aW5nIHRoZSBydWxlcyBp biBbOF3igJ0uIFdoaWNoIHJ1bGVzIGFyZSB5b3UgcmVmZXJyaW5nIHRvPw0KDQpSZXNldCBtZWFu cyBjbG9zZWQgYW5kIHJlZXN0YWJsaXNoZWQuIFRoZSB3b3JkIOKAnHJlc2V04oCdIHdhcyB1c2Vk IGluIFJGQyA0NTgyIGFuZCByZXVzZWQgaW4gNDU4MmJpcy4gUGVyaGFwcyB3ZSBzaG91bGQgY2hh bmdlIGl0IGNsb3NlZCBhbmQgcmVlc3RhYmxpc2hlZCB0byBhdm9pZCBjb25mdXNpb24/DQoNCg0K VGhlbiwgdGhlIHRleHQgc2F5cyB0aGF0IHRoZSBjbGllbnQgYWx3YXlzIHJlLWVzdGFibGlzaGVk IHRoZSBUQ1AgY29ubmVjdGlvbi4gSXMgdGhhdCBhbGlnbmVkIHdpdGggdGhlIHRleHQgaW4gNDU4 MmJpcywgc2F5aW5nIHRoYXQgdGhlIGFjdGl2ZSBwYXJ0eSBkb2VzIHRoZSByZWVzdGFibGlzaG1l bnQ/IElzIHRoZSBjbGllbnQgYWx3YXlzIGFjdGl2ZT8NCg0KSSB0aGluayBpdCBpcyBhIGxpdHRs ZSBjb25mdXNpbmcgdGhhdCBib3RoIDQ1ODJiaXMgYW5kIDQ1ODNiaXMgZGVmaW5lcyBTRFAgT2Zm ZXIvQW5zd2VyIHByb2NlZHVyZXMuIFNob3VsZG7igJl0IHRoZXkgb25seSBiZSBpbiA0NTgzYmlz Pw0KDQpZZXMsIEkgdGhpbmsgc28uIFJGQyA0NTgyIG1peGVkIHNvbWUgU0RQIG9mZmVyL2Fuc3dl ciB0ZXh0IGludG8gaXRzIHNlY3Rpb24gb24gbG93ZXIgbGF5ZXIgc2VjdXJpdHksIGFuZCA0NTgy YmlzIGZvbGxvd2VkIHN1aXQuIEl0IHdvdWxkIGJlIGJldHRlciB0byBoYXZlIGFsbCB0aGUgZGV0 YWlscyBvZiBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgYW5kIHJlZXN0YWJsaXNobWVudCBpbiB3 aGVuIHVzaW5nIFNEUCBvZmZlci9hbnN3ZXIgaW4gNDU4M2Jpcy4NCg0KDQoNCg0KVGhpcmQsIHRo ZSBsYXN0IHBhcmFncmFwaCwgdGFsa2luZyBhYm91dCBVRFAvRFRMUywgc2F5cyB0aGF0IGVpdGhl ciBwYXJ0eSBjYW4gYmUgRFRMUyBzZXJ2ZXIgZGVwZW5kaW5nIG9uIHRoZSBzZXR1cCBhdHRyaWJ1 dGVzIGV4Y2hhbmdlZC4gQnV0LCBub3doZXJlIGlzIGl0IGRlc2NyaWJlZCBob3cgdGhlIHNldHVw IGF0dHJpYnV0ZSBpcyB1c2VkIHRvIGRldGVybWluZSB0aGUgRFRMUyBzZXJ2ZXIgcm9sZSDimLoN Cg0KSSBhc3N1bWUgaXQgaXMgZG9uZSBpbiB0aGUgc2FtZSB3YXkgYXMgZm9yIFRDUC9UTFMsIGJ1 dCB0aGF0IGlzIG5vdCB3cml0dGVuIGFueXdoZXJlLg0KDQpUaGUgdGV4dCBJIHBhc3RlZCBmcm9t IDQ1ODNiaXMgYWJvdmUgZGVzY3JpYmVzIHRoaXMuIElmIHdlIHB1dCBhbGwgdGhlIGNvbm5lY3Rp b24gbWFuYWdlbWVudCBzdHVmZiBpbiA0NTgzYmlzIGluc3RlYWQgb2YgbGVhdmluZyBpdCBzcGxp dCBhY3Jvc3MgNDU4MmJpcyBhbmQgNDU4M2JpcywgdGhpcyBzaG91bGQgYmUgY2xlYXIuDQoNCkNo ZWVycywNCkNoYXJsZXMNCg0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmJmY3BiaXMgbWFpbGluZyBs aXN0DQpiZmNwYmlzQGlldGYub3JnPG1haWx0bzpiZmNwYmlzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZmNwYmlzDQoNCg0KDQotLQ0KIyBDaXNjbyAg ICAgICAgICAgICAgICAgICAgICAgICB8ICBodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWxlcHJlc2Vu Y2UvDQojIyB0b21rcmlzdEBjaXNjby5jb208bWFpbHRvOnRvbWtyaXN0QGNpc2NvLmNvbT4gIHwg IGh0dHA6Ly93d3cudGFuZGJlcmcuY29tDQojIyMgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgaHR0cDovL2ZvbGsudWlvLm5vL3RvbWtyaS8NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D2CC894ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDo0NzY4NDY3NDk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEz ODU3MDEzMDA7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5JdCB3b3VsZCBiZSBtdWNo IGNsZWFyZXIgYW5kIGxlc3MgY29uZnVzaW5nIHRvIGhhdmUgYWxsIHRoZSBTRFAgb2ZmZXIvYW5z d2VyIHJlbGF0ZWQNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPnByb2Nl ZHVyZXMgaW4gcmZjNDU4M2Jpcy4gSSBhZ3JlZSBhbmQgaGF2ZSBzdGFydGVkIHdvcmtpbmcgb24g aXQsIGkuZS4gbW92aW5nIGNvbnRlbnQgdG8NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m Z3Q7PC9zcGFuPnJmYzQ1ODNiaXMgYW5kIHBvbGlzaGluZyB0ZXh0IGluIHJmYzQ1ODJiaXMuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0 Ozwvc3Bhbj5Ib3dldmVyLCB3aGF0IGRvIHBlb3BsZSBvbiB0aGlzIGxpc3QgdGhpbmsgYWJvdXQg dGhlIGNvbmNlcm5zIGFuZCBza2V0Y2ggZm9yIHNvbHZpbmcgdGhpcw0KPHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+aXNzdWUgcHJvcG9zZWQgYnkgQ2hhcmxlcz88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZndDs8L3NwYW4+QW5kIHNwZWNpZmljYWxseTogRG8gd2Ugd2FudCB0byAoaSkgdXBkYXRlIFJG QyA1MDE4IHdpdGggVURQIC8gRFRMUyBvciBkbyB3ZSB0aGluayBpdCBpcw0KPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+ZXZlbiB0aGlua2FibGUvZG9hYmxlIHRvIChpaSkg c3BlY2lmeSBVRFAgLyBEVExTIGFzIGEgdHJhbnNwb3J0IG9ubHkgd2hlbiBvZmZlci9hbnN3ZXIg aXMNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPnVzZWQ/IChOb3QgYSBj bGVhbiBhcHByb2FjaCwgYnV0IHZlcnkgcHJhZ21hdGljIDspICk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2VsbCwgaGFzIGFueW9u ZSByZXF1ZXN0ZWQgYSBub24tTy9BIG1lY2hhbmlzbT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjkgTWFyY2ggMjAxNCAxMjo0MCwgQ2hyaXN0 ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIENoYXJs ZXMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2l0aG91dCBjb21t ZW50aW5nIG9uIHNwZWNpZmljcyBhdCB0aGlzIHBvaW50LCBJIHJlYWxseSB0aGluayB3ZSBzaG91 bGQgdHJ5IHRvIGdldCB0aGUgU0RQIE9mZmVyL0Fuc3dlciBwcm9jZWR1cmVzIGludG8gb25lIHBs YWNlICg0NTgzYmlzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj40 NTgyYmlzIGNhbiBkZWZpbmUgYWN0aW9ucyB0YWtlbiBieSB0aGUgRFRMUyBjbGllbnQgYW5kIHNl cnZlciwgYnV0IHNob3VsZCBub3QgZGVmaW5lIGhvdyB0aG9zZSByb2xlcyBhcmUgZGV0ZXJtaW5l ZC4gNDU4M2JpcyB0aGVuIGRlZmluZXMgaG93IHRoZSByb2xlcw0KIGFyZSBkZXRlcm1pbmVkIHdo ZW4gdXNpbmcgU0RQIE8vQS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNocmlz dGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1l PSIxNDUwZGE0YWIwNTVkNDg1X19NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQ2hhcmxlcyBFY2tlbCAo ZWNrZWxjdSkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20iIHRhcmdl dD0iX2JsYW5rIj5lY2tlbGN1QGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjcg TWFyY2ggMjAxNCAwMToxMTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8 Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+YmZjcGJpc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtiZmNwYmlz XSBUQ1AvVExTIGFuZCBVRFAvRFRMUyBjb21tZW50cyBvbiA0NTgyYmlzIGFuZCA0NTgzYmlzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5IaSBDaHJpc3Rlciw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0Ij5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFRoZSBtb3JlIEkg bG9va2VkIGludG8gdGhlbSB0aGUgbW9yZSBjb21wbGV4IGFuZCB0YW5nbGVkIHRoaW5ncyBiZWNh bWUuIExldCBtZSB0cnkgdG8gd2FsayB0aHJvdWdoIHRoZSBjdXJyZW50IHN0YXRlIG9mDQogYWZm YWlycyBhbmQgdGhlbiBwcm9wb3NlIGEgcG90ZW50aWFsIHNvbHV0aW9ucy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0Ij5SRkMgNDU4MiBicmVha3MgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IGludG8gdHdv IGNhc2VzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBl PSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPndoZW4gU0RQIG9mZmVyL2Fuc3dlciBJUyBO T1QgdXNlZDwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+d2hl biBTRFAgb2ZmZXIvYW5zd2VyIElTIHVzZWQ8L3NwYW4+PG86cD48L286cD48L2xpPjwvb2w+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dCI+Rm9yICgxKSwgUkZDIDQ1ODIgcG9pbnRzIHRvIFJGQyA1MDE4LiBkcmFmdC1pZXRmLWJmY3Bi aXMtcmZjNDU4MmJpcy0xMSBhZGRzIGEgcmVmZXJlbmNlIHRvIFJGQyA1MjM5IGZvciBYQ09OLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPlJGQyA1MDE4IGRlYWxzIHdpdGggdGhl IGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudCwgcmVlc3RhYmxpc2htZW50LCAmbmJzcDthbmQgVExT IHVzYWdlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPlJGQyA1MjM5IHBvaW50 cyBiYWNrIHRvIFJGQyA1MDE4IGZvciBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+UkZDIDUwMTggZG9lcyBub3QgZGVhbCB3aXRoIERU TFMuIFVubGVzcyB3ZSByZXN0cmljdCBEVExTIHRvIGNhc2VzIGluIHdoaWNoIFNEUCBvZmZlci9h bnN3ZXIgaXMgdXNlZCwgd2UgbmVlZCB0byB1cGRhdGUgUkZDIDUwMTggdG8gZGVhbCB3aXRoIERU TFMuDQogU29tZW9uZSBwbGVhc2UgdGVsbCBtZSBvdGhlcndpc2UuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dCI+U2VjdGlvbiA2LjIgb2YgZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXMtMTEgZGVzY3Jp YmVzIGhvdyB0byBleHRlbmQgUkZDIDUwMTggd2hlbiBkZWFsaW5nIHdpdGggQkZDUCBvdmVyIFVE UCBvciBEVExTLiBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIHJlbG9jYXRlZA0KIHRvIGFuIHVwZGF0 ZSB0byBSRkMgNTAxOCwgYW5kIGNvbm5lY3Rpb24gcmVlc3RhYmxpc2htZW50IHNob3VsZCBiZSBk ZXNjcmliZWQgYXMgd2VsbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5Gb3IgKDIpLCBSRkMgNDU4MiBw cm92aWRlcyBhIHRlYXNlciBidXQgcG9pbnRzIHRvIFJGQyA0NTgzIGZvciB0aGUgbm9ybWF0aXZl IGxhbmd1YWdlLiBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpcy0xMSBzaW1pbGFybHkgcG9p bnRzIHRvIGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTA5Lg0KIENocmlzdGVyIGNvbW1l bnRzIGFyZSBpbiByZWdhcmQgdG8gaW5jb25zaXN0ZW5jaWVzIGhlcmUuIEkgcHJvdmlkZWQgY29t bWVudHMgb24gdGhvc2UgaW5saW5lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOg0KPC9iPkNocmlzdGVyIEhv bG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t IiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgTWFyY2ggMjUsIDIwMTQgYXQgMTI6MzkgUE08YnI+ DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+YmZjcGJpc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltiZmNwYmlzXSBUQ1AvVExTIGFuZCBVRFAvRFRMUyBj b21tZW50cyBvbiA0NTgyYmlzIGFuZCA0NTgzYmlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNlY3Rpb24gNyBp biA0NTgyYmlzLCB3aGljaCBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPuKAnDcuJm5ic3A7IExvd2VyLUxheWVyIFNlY3VyaXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEJG Q1AgcmVsaWVzIG9uIGxvd2VyLWxheWVyIHNlY3VyaXR5IG1lY2hhbmlzbXMgdG8gcHJvdmlkZSBy ZXBsYXkgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGludGVncml0eSBwcm90ZWN0aW9uIGFuZCBjb25maWRlbnRp YWxpdHkuJm5ic3A7IEJGQ1AgZmxvb3IgY29udHJvbCBzZXJ2ZXJzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGFuZCBj bGllbnRzICh3aGljaCBpbmNsdWRlIGJvdGggZmxvb3IgcGFydGljaXBhbnRzIGFuZCBmbG9vciBj aGFpcnMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IE1VU1Qgc3VwcG9ydCBUTFMgZm9yIHRyYW5zcG9ydCBv dmVyIFRDUCBbNl0gYW5kIE1VU1Qgc3VwcG9ydCBEVExTIFs3XTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBmb3IgdHJh bnNwb3J0IG92ZXIgVURQLiZuYnNwOyBBbnkgQkZDUCBlbnRpdHkgTUFZIHN1cHBvcnQgb3RoZXIg c2VjdXJpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbWVjaGFuaXNtcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQkZDUCBl bnRpdGllcyBNVVNUIHN1cHBvcnQsIGF0IGEgbWluaW11bSwgdGhlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRMU19S U0FfV0lUSF9BRVNfMTI4X0NCQ19TSEEgY2lwaGVyc3VpdGUgWzZdLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBXaGljaCBwYXJ0eSwgdGhlIGNsaWVudCBvciB0aGUgZmxvb3IgY29udHJvbCBzZXJ2ZXIsIGFj dHMgYXMgdGhlIFRMUy88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgRFRMUyBzZXJ2ZXIgZGVwZW5kcyBvbiBob3cgdGhl IHVuZGVybHlpbmcgVExTL0RUTFMgY29ubmVjdGlvbiBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBlc3RhYmxpc2hl ZC4mbmJzcDsgRm9yIGEgVENQL1RMUyBjb25uZWN0aW9uIGVzdGFibGlzaGVkIHVzaW5nIGFuIFNE UDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgWzldLCB0aGUgYW5zd2VyZXIgKHdo aWNoIG1heSBiZSB0aGUgY2xpZW50IG9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoZSBmbG9vciBjb250cm9sIHNl cnZlcikgYWx3YXlzIGFjdHMgYXMgdGhlIFRMUyBzZXJ2ZXIuJm5ic3A7IElmIHRoZSBUQ1A8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgY29ubmVjdGlvbiBpcyBsb3N0LCB0aGUgYWN0aXZlIGVuZHBvaW50LCBpLmUuLCB0 aGUgY3VycmVudCBUTFM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY2xpZW50LCBpcyByZXNwb25zaWJsZSBmb3IgcmUt ZXN0YWJsaXNoaW5nIHRoZSBUQ1AgY29ubmVjdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVW5sZXNzIGEgbmV3 IFRMUyBzZXNzaW9uIGlzIG5lZ290aWF0ZWQsIHN1YnNlcXVlbnQgU0RQIG9mZmVycyBhbmQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgYW5zd2VycyB3aWxsIG5vdCBpbXBhY3QgdGhlIHByZXZpb3VzbHkgbmVnb3RpYXRl ZCBUTFMgcm9sZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEZvciBhIFVEUC9EVExTIGNvbm5lY3Rpb24g ZXN0YWJsaXNoZWQgdXNpbmcgdGhlIGFuIFNEUCBvZmZlci9hbnN3ZXI8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZXhj aGFuZ2UsIGVpdGhlciBwYXJ0eSBjYW4gYmUgdGhlIERUTFMgc2VydmVyIGRlcGVuZGluZyBvbiB0 aGUgc2V0dXA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYXR0cmlidXRlcyBleGNoYW5nZWQ7IGV4YW1wbGVzIGNhbiBi ZSBmb3VuZCBpbiBbMjNdLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZpcnN0PC9zcGFuPjwvYj4sIHdlIGFscmVhZHkgZWFy bGllciBkaXNjdXNzZWQgdGhhdCB0aGUgYWN0aXZlIFRDUCBlbmRwb2ludCBpcyByZXNwb25zaWJs ZSBmb3IgcmUtZXN0YWJsaXNoaW5nIHRoZSBUQ1AgY29ubmVjdGlvbiwgYW5kIHRoYXQgd2lsbCBi ZSBjb3JyZWN0ZWQNCiBpbiB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+WWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Ib3dldmVyLCB3ZSBoYXZlIGRpc2N1c3NlZCBhIHNpbWlsYXIgdG9waWMgaW4g Q0xVRSwgYW5kIHdlIHdlcmUgd29uZGVyaW5nIHdoZXRoZXIgaXQgd291bGQgYmUgZ29vZCB0aGF0 LCB3aG9ldmVyIGRldGVjdHMgYSBjb25uZWN0aW9uIGZhaWx1cmUsIHNlbmRzIGEgbmV3IG9mZmVy IGluIG9yZGVyIHRvIHJlLWVzdGFibGlzaA0KIHRoZSBjb25uZWN0aW9uLiBJdCBkb2VzIG5vdCBt YXR0ZXIgaWYgYm90aCBlbmRwb2ludHMgc2VuZCBhbiBvZmZlciDigJMgdGhlIG9mZmVyL2Fuc3dl ciByYWNlIGNvbmRpdGlvbiBydWxlcyB3aWxsIHRha2UgY2FyZSBvZiB0aGF0LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5JbiBDTFVFLCBpcyB0aGlzIGZvciBhIFRDUC9UTFMg Y29ubmVjdGlvbiwgb3IgZm9yIGEgRFRMUyBjb25uZWN0aW9uPzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPkZvciBEVExTLCB3ZSBzcGVjaWZpY2FsbHkgY2hvc2UgdG8gYWx0ZXIg dGhlIGJlaGF2aW9yLCBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA5LjEgb2YgNDU4M2Jpczo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0Ij4mbmJzcDsgJnF1b3Q7RW5kcG9pbnRzIHRoYXQgdXNlIHRoZSBvZmZl ci9hbnN3ZXIgbW9kZWwgdG8gZXN0YWJsaXNoIGEgRFRMUzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJz cDthc3NvY2lhdGlvbiBNVVNUIHN1cHBvcnQgdGhlICdzZXR1cCcgYXR0cmlidXRlLCBhcyBkZWZp bmVkIGluIFs3XS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7ICZuYnNwO1doZW4gRFRMUyBpcyB1c2VkIHdpdGggVURQLCB0aGUgJ3Nl dHVwJyBhdHRyaWJ1dGUgaW5kaWNhdGVzIHdoaWNoIG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt0aGUgZW5kcG9pbnRz IChjbGllbnQgb3IgZmxvb3IgY29udHJvbCBzZXJ2ZXIpIGluaXRpYXRlcyB0aGUgRFRMUzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg Jm5ic3A7YXNzb2NpYXRpb24gc2V0dXAuICZuYnNwO1RoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBv ZmZlci9hbnN3ZXIgZXhjaGFuZ2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3NwZWNpZmllZCBpbiBbMTNdLCBTZWN0aW9u IDUgTVVTVCBiZSBmb2xsb3dlZCB3aGVuIHVzaW5nIERUTFMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyBJbmZvcm1hdGlvbmFsIG5vdGU6IEhvdyB0byBkZXRlcm1pbmUgd2hpY2ggZW5kcG9pbnQgdG8g aW5pdGlhdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIFRMUy9EVExTIGFzc29jaWF0aW9uIGRlcGVu ZHMgb24gdGhlIHNlbGVjdGVkIHVuZGVybHlpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJhbnNwb3J0 LiAmbmJzcDtJdCB3YXMgZGVjaWRlZCB0byBrZWVwIHRoZSBvcmlnaW5hbCBzZW1hbnRpY3MgaW4g WzE1XTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyBmb3IgVENQIHRvIHJldGFpbiBiYWNrd2FyZHMgY29tcGF0 aWJpbGl0eS4gJm5ic3A7V2hlbiB1c2luZyBVRFAsIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBwcm9j ZWR1cmUgYWJvdmUgd2FzIHByZWZlcnJlZCBzaW5jZSBpdCBhZGhlcmVzIHRvIFsxM10gYXMgdXNl ZCBmb3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRFRMUy1TUlRQLCBpdCBkb2VzIG5vdCBvdmVybG9hZCBv ZmZlci9hbnN3ZXIgc2VtYW50aWNzLCBhbmQgaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgd29ya3MgZm9y IG9mZmVybGVzcyBJTlZJVEUgaW4gc2NlbmFyaW9zIHdpdGggQjJCVUFzLiZxdW90OzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPlNlY29uZDwvc3Bhbj48L2I+LCBTZWN0aW9u IDguMSBpbiA0NTgzYmlzIHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsg 4oCcV2hlbiB0aGUgZXhpc3RpbmcgVENQIGNvbm5lY3Rpb24gaXMgcmVzZXQgZm9sbG93aW5nIHRo ZSBydWxlcyBpbiBbOF0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOyZuYnNwOyB0aGUgY2xpZW50IE1VU1QgZ2VuZXJhdGUgYW4gb2ZmZXIgdG93YXJkcyB0 aGUgZmxvb3IgY29udHJvbCBzZXJ2ZXIgaW48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IG9yZGVyIHRvIHJlZXN0YWJsaXNoIHRoZSBjb25uZWN0 aW9uLiZuYnNwOyBJZiBhIFRDUCBjb25uZWN0aW9uIGNhbm5vdDwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZGVsaXZlciBhIEJGQ1AgbWVzc2Fn ZSBhbmQgdGltZXMgb3V0LCB0aGUgZW50aXR5IHRoYXQgYXR0ZW1wdGVkIHRvPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBzZW5kIHRoZSBtZXNz YWdlIChpLmUuLCB0aGUgb25lIHRoYXQgZGV0ZWN0ZWQgdGhlIFRDUCB0aW1lb3V0KSBNVVNUPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBnZW5l cmF0ZSBhbiBvZmZlciBpbiBvcmRlciB0byByZWVzdGFibGlzaCB0aGUgVENQIGNvbm5lY3Rpb24u 4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhbSBub3Qgc3VyZSB3aGF0IGlz IG1lYW50IGJ5IOKAnFRDUCBjb25uZWN0aW9uIGlzIHJlc2V0IGZvbGxvd2luZyB0aGUgcnVsZXMg aW4gWzhd4oCdLiBXaGljaCBydWxlcyBhcmUgeW91IHJlZmVycmluZyB0bz88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdCI+UmVzZXQgbWVhbnMgY2xvc2VkIGFuZCByZWVzdGFibGlz aGVkLiBUaGUgd29yZCDigJxyZXNldOKAnSB3YXMgdXNlZCBpbiBSRkMgNDU4MiBhbmQgcmV1c2Vk IGluIDQ1ODJiaXMuIFBlcmhhcHMgd2Ugc2hvdWxkIGNoYW5nZSBpdCBjbG9zZWQgYW5kIHJlZXN0 YWJsaXNoZWQNCiB0byBhdm9pZCBjb25mdXNpb24/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoZW4sIHRoZSB0ZXh0IHNheXMgdGhhdCB0aGUgY2xpZW50IGFsd2F5cyByZS1l c3RhYmxpc2hlZCB0aGUgVENQIGNvbm5lY3Rpb24uIElzIHRoYXQgYWxpZ25lZCB3aXRoIHRoZSB0 ZXh0IGluIDQ1ODJiaXMsIHNheWluZyB0aGF0IHRoZSBhY3RpdmUgcGFydHkgZG9lcyB0aGUgcmVl c3RhYmxpc2htZW50PyBJcw0KIHRoZSBjbGllbnQgYWx3YXlzIGFjdGl2ZT88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgaXQgaXMgYSBsaXR0bGUgY29uZnVzaW5nIHRoYXQgYm90 aCA0NTgyYmlzIGFuZCA0NTgzYmlzIGRlZmluZXMgU0RQIE9mZmVyL0Fuc3dlciBwcm9jZWR1cmVz LiBTaG91bGRu4oCZdCB0aGV5IG9ubHkgYmUgaW4gNDU4M2Jpcz88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdCI+WWVzLCBJIHRoaW5rIHNvLiBSRkMgNDU4MiBtaXhlZCBzb21lIFNE UCBvZmZlci9hbnN3ZXIgdGV4dCBpbnRvIGl0cyBzZWN0aW9uIG9uIGxvd2VyIGxheWVyIHNlY3Vy aXR5LCBhbmQgNDU4MmJpcyBmb2xsb3dlZCBzdWl0LiBJdCB3b3VsZCBiZSBiZXR0ZXINCiB0byBo YXZlIGFsbCB0aGUgZGV0YWlscyBvZiBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgYW5kIHJlZXN0 YWJsaXNobWVudCBpbiB3aGVuIHVzaW5nIFNEUCBvZmZlci9hbnN3ZXIgaW4gNDU4M2Jpcy4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2lu LWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5UaGlyZDwvc3Bhbj48 L2I+LCB0aGUgbGFzdCBwYXJhZ3JhcGgsIHRhbGtpbmcgYWJvdXQgVURQL0RUTFMsIHNheXMgdGhh dCBlaXRoZXIgcGFydHkgY2FuIGJlIERUTFMgc2VydmVyIGRlcGVuZGluZyBvbiB0aGUgc2V0dXAg YXR0cmlidXRlcyBleGNoYW5nZWQuIEJ1dCwNCiBub3doZXJlIGlzIGl0IGRlc2NyaWJlZCBob3cg dGhlIHNldHVwIGF0dHJpYnV0ZSBpcyB1c2VkIHRvIGRldGVybWluZSB0aGUgRFRMUyBzZXJ2ZXIg cm9sZQ0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+Sjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYXNzdW1lIGl0IGlzIGRvbmUgaW4gdGhlIHNhbWUgd2F5 IGFzIGZvciBUQ1AvVExTLCBidXQgdGhhdCBpcyBub3Qgd3JpdHRlbiBhbnl3aGVyZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGhlIHRleHQgSSBwYXN0ZWQgZnJvbSA0NTgzYmlzIGFib3ZlIGRl c2NyaWJlcyB0aGlzLiBJZiB3ZSBwdXQgYWxsIHRoZSBjb25uZWN0aW9uIG1hbmFnZW1lbnQgc3R1 ZmYgaW4gNDU4M2JpcyBpbnN0ZWFkIG9mIGxlYXZpbmcgaXQgc3BsaXQgYWNyb3NzIDQ1ODJiaXMg YW5kIDQ1ODNiaXMsIHRoaXMgc2hvdWxkDQogYmUgY2xlYXIuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGVlcnMsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoYXJsZXM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFy Z2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpiZmNwYmlzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIj5iZmNwYmlzQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJpcyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJp czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NCiMgQ2lzY28gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS90ZWxlcHJlc2VuY2UvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5jaXNjby5jb20vdGVsZXByZXNlbmNlLzwvYT48YnI+ DQojIyA8YSBocmVmPSJtYWlsdG86dG9ta3Jpc3RAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ dG9ta3Jpc3RAY2lzY28uY29tPC9hPiAmbmJzcDt8ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cu dGFuZGJlcmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy50YW5kYmVyZy5jb208L2E+ PGJyPg0KIyMjICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7PGEgaHJlZj0iaHR0cDovL2ZvbGsudWlvLm5vL3RvbWtyaS8iIHRhcmdldD0iX2Js YW5rIj5odHRwOi8vZm9say51aW8ubm8vdG9ta3JpLzwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D2CC894ESESSMB209erics_-- From nobody Thu Apr 17 09:25:03 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B955D1A00DD for ; Thu, 17 Apr 2014 09:25:01 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ6cBiUMsb0x for ; Thu, 17 Apr 2014 09:24:56 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 509AB1A019C for ; Thu, 17 Apr 2014 09:24:56 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id ih12so590793qab.37 for ; Thu, 17 Apr 2014 09:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8QgSPsXfBoceo9oSlLMU9SqjJvVMsJLEZuEwk+cS5wc=; b=UeCTW/CtIKdDlo0AaW5T8nq0+loldRYQoKhNC5Ha6HGBYczHmieg0yonOIcMJkWxt6 hlCQ/lw+899FNfhE/frC78QBKVZQeTip0dCj3jJK8LKhPKKuxAxn6D/or/mOL9/cQLX9 dHe6/pmfLxaOBa4jS4N/8Leo06G4sE+jqKVO215NcN1bQlleOQyEaqmp30y0v0Dy3PU5 SKZpqzXKd7hlfT4FscCV2LZXK3ObUwigfV5s8Cqx7pvzxa13AwSrO0xQ5FC5ex9FhIch /tRxo5D3GqYkBvR0LC+7uQT2amIDqWPyQ2jBI/w3xG/LE6YdmLxHRY5GMxi5FUOjeSzL bExQ== MIME-Version: 1.0 X-Received: by 10.140.32.97 with SMTP id g88mr17901939qgg.17.1397751892506; Thu, 17 Apr 2014 09:24:52 -0700 (PDT) Received: by 10.229.2.66 with HTTP; Thu, 17 Apr 2014 09:24:52 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2CC894@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D26AD25@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2CC894@ESESSMB209.ericsson.se> Date: Thu, 17 Apr 2014 18:24:52 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113a665a097fcd04f73f794f Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/1ro91v5QvceEdfnn2cZ_MCopIGM Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , Tom Kristensen Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:25:01 -0000 --001a113a665a097fcd04f73f794f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have never heard of any need for a non-O/A mechanism, UDP/DTLS is currently used by vendors utilizing offer/answer in a SIP context. On 16 April 2014 22:36, Christer Holmberg w= rote: > Hi, > > > > >It would be much clearer and less confusing to have all the SDP > offer/answer related >procedures in rfc4583bis. I agree and have started > working on it, i.e. moving content to >rfc4583bis and polishing text in > rfc4582bis. > > > > > >However, what do people on this list think about the concerns and sketch > for solving this >issue proposed by Charles? > > > > > >And specifically: Do we want to (i) update RFC 5018 with UDP / DTLS or > do we think it is >even thinkable/doable to (ii) specify UDP / DTLS as a > transport only when offer/answer is >used? (Not a clean approach, but > very pragmatic ;) ) > > > > Well, has anyone requested a non-O/A mechanism? > > > > Regards, > > > > Christer > > > > > > On 29 March 2014 12:40, Christer Holmberg > wrote: > > Hi Charles, > > > > Without commenting on specifics at this point, I really think we should > try to get the SDP Offer/Answer procedures into one place (4583bis). > > > > 4582bis can define actions taken by the DTLS client and server, but shoul= d > not define how those roles are determined. 4583bis then defines how the > roles are determined when using SDP O/A. > > > > Regards, > > > > Christer > > > > *From:* Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > *Sent:* 27 March 2014 01:11 > *To:* Christer Holmberg > *Cc:* bfcpbis@ietf.org > *Subject:* Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and > 4583bis > > > > Hi Christer, > > > > Thanks for your comments. The more I looked into them the more complex an= d > tangled things became. Let me try to walk through the current state of > affairs and then propose a potential solutions. > > > > RFC 4582 breaks connection establishment into two cases: > > 1. when SDP offer/answer IS NOT used > 2. when SDP offer/answer IS used > > For (1), RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 > adds a reference to RFC 5239 for XCON. > > RFC 5018 deals with the connection establishment, reestablishment, and > TLS usage. > > RFC 5239 points back to RFC 5018 for connection establishment. > > RFC 5018 does not deal with DTLS. Unless we restrict DTLS to cases in > which SDP offer/answer is used, we need to update RFC 5018 to deal with > DTLS. Someone please tell me otherwise. > > > > Section 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend > RFC 5018 when dealing with BFCP over UDP or DTLS. I think this should be > relocated to an update to RFC 5018, and connection reestablishment should > be described as well. > > > > For (2), RFC 4582 provides a teaser but points to RFC 4583 for the > normative language. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to > draft-ietf-bfcpbis-rfc4583bis-09. Christer comments are in regard to > inconsistencies here. I provided comments on those inline. > > > > *From: *Christer Holmberg > *Date: *Tuesday, March 25, 2014 at 12:39 PM > *To: *"bfcpbis@ietf.org" > *Subject: *[bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis > > > > Hi, > > > > Section 7 in 4582bis, which says: > > > > =E2=80=9C7. Lower-Layer Security > > > > BFCP relies on lower-layer security mechanisms to provide replay and > > integrity protection and confidentiality. BFCP floor control servers > > and clients (which include both floor participants and floor chairs) > > > > MUST support TLS for transport over TCP [6] and MUST support DTLS [7] > > for transport over UDP. Any BFCP entity MAY support other security > > mechanisms. > > > > BFCP entities MUST support, at a minimum, the > > TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. > > > > Which party, the client or the floor control server, acts as the TLS/ > > DTLS server depends on how the underlying TLS/DTLS connection is > > established. For a TCP/TLS connection established using an SDP > > offer/answer exchange [9], the answerer (which may be the client or > > the floor control server) always acts as the TLS server. If the TCP > > connection is lost, the active endpoint, i.e., the current TLS > > client, is responsible for re-establishing the TCP connection. > > Unless a new TLS session is negotiated, subsequent SDP offers and > > answers will not impact the previously negotiated TLS roles. > > > > For a UDP/DTLS connection established using the an SDP offer/answer > > exchange, either party can be the DTLS server depending on the setup > > attributes exchanged; examples can be found in [23].=E2=80=9D > > > > *First*, we already earlier discussed that the active TCP endpoint is > responsible for re-establishing the TCP connection, and that will be > corrected in the next version of the draft. > > > > Yes. > > > > > > However, we have discussed a similar topic in CLUE, and we were wondering > whether it would be good that, whoever detects a connection failure, send= s > a new offer in order to re-establish the connection. It does not matter i= f > both endpoints send an offer =E2=80=93 the offer/answer race condition ru= les will > take care of that. > > > > In CLUE, is this for a TCP/TLS connection, or for a DTLS connection? > > For DTLS, we specifically chose to alter the behavior, as described in > section 9.1 of 4583bis: > > > > "Endpoints that use the offer/answer model to establish a DTLS > > association MUST support the 'setup' attribute, as defined in [7]. > > When DTLS is used with UDP, the 'setup' attribute indicates which of > > the endpoints (client or floor control server) initiates the DTLS > > association setup. The requirements for the offer/answer exchange > > specified in [13], Section 5 MUST be followed when using DTLS. > > > > Informational note: How to determine which endpoint to initiate > > the TLS/DTLS association depends on the selected underlying > > transport. It was decided to keep the original semantics in [15] > > for TCP to retain backwards compatibility. When using UDP, the > > procedure above was preferred since it adheres to [13] as used for > > DTLS-SRTP, it does not overload offer/answer semantics, and it > > works for offerless INVITE in scenarios with B2BUAs." > > > > > > > > > > *Second*, Section 8.1 in 4583bis says: > > > > =E2=80=9CWhen the existing TCP connection is reset following the rules= in [8], > > the client MUST generate an offer towards the floor control server in > > order to reestablish the connection. If a TCP connection cannot > > deliver a BFCP message and times out, the entity that attempted to > > send the message (i.e., the one that detected the TCP timeout) MUST > > generate an offer in order to reestablish the TCP connection.=E2=80=9D > > > > > > I am not sure what is meant by =E2=80=9CTCP connection is reset following= the > rules in [8]=E2=80=9D. Which rules are you referring to? > > > > Reset means closed and reestablished. The word =E2=80=9Creset=E2=80=9D wa= s used in RFC > 4582 and reused in 4582bis. Perhaps we should change it closed and > reestablished to avoid confusion? > > > > > > Then, the text says that the client always re-established the TCP > connection. Is that aligned with the text in 4582bis, saying that the > active party does the reestablishment? Is the client always active? > > > > I think it is a little confusing that both 4582bis and 4583bis defines SD= P > Offer/Answer procedures. Shouldn=E2=80=99t they only be in 4583bis? > > > > Yes, I think so. RFC 4582 mixed some SDP offer/answer text into its > section on lower layer security, and 4582bis followed suit. It would be > better to have all the details of connection establishment and > reestablishment in when using SDP offer/answer in 4583bis. > > > > > > > > > > *Third*, the last paragraph, talking about UDP/DTLS, says that either > party can be DTLS server depending on the setup attributes exchanged. But= , > nowhere is it described how the setup attribute is used to determine the > DTLS server role J > > > > I assume it is done in the same way as for TCP/TLS, but that is not > written anywhere. > > > > The text I pasted from 4583bis above describes this. If we put all the > connection management stuff in 4583bis instead of leaving it split across > 4582bis and 4583bis, this should be clear. > > > > Cheers, > > Charles > > > > > > > > Regards, > > > > Christer > > > > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > > > > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a113a665a097fcd04f73f794f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have never heard of any need for a non-O/A mechanism, UD= P/DTLS is currently used by vendors utilizing offer/answer in a SIP context= .


On 16 = April 2014 22:36, Christer Holmberg <christer.holmberg@ericss= on.com> wrote:

Hi,<= /p>

=C2=A0

>It would be= much clearer and less confusing to have all the SDP offer/answer related >procedures in rfc4583bis. I agree = and have started working on it, i.e. moving content to >rfc4583bis and polishing text in r= fc4582bis.

>=C2= =A0

>However, wh= at do people on this list think about the concerns and sketch for solving t= his >issue proposed by Charles?<= u>

>=C2= =A0

>And specifi= cally: Do we want to (i) update RFC 5018 with UDP / DTLS or do we think it = is >even thinkable/doable to (ii) spec= ify UDP / DTLS as a transport only when offer/answer is >used? (Not a clean approach, but v= ery pragmatic ;) )

=C2=A0

Well, has anyone requeste= d a non-O/A mechanism?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0<= /p>

On 29 March 2014 12:40, Christer Holmberg <christer.holm= berg@ericsson.com> wrote:

Hi Charles,<= /u>

=C2=A0

Without commenting on = specifics at this point, I really think we should try to get the SDP Offer/= Answer procedures into one place (4583bis).

=C2=A0

4582bis can define act= ions taken by the DTLS client and server, but should not define how those r= oles are determined. 4583bis then defines how the roles are determined when using SDP O/A.

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
Sent: 27 March 2014 01:11
To: Christer Holmberg
Cc: bfcpbis@ie= tf.org
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and = 4583bis

=C2=A0

Hi Christer,=

=C2=A0

Thanks for your com= ments. The more I looked into them the more complex and tangled things beca= me. Let me try to walk through the current state of affairs and then propose a potential solutions.

=C2=A0

RFC 4582 breaks con= nection establishment into two cases:

  1. when SDP offer/answer IS NOT used
  2. when SDP offer/answer IS used

For (1), RFC 4582 p= oints to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds a reference to RFC= 5239 for XCON.

RFC 5018 deals with= the connection establishment, reestablishment, =C2=A0and TLS usage.=

RFC 5239 points bac= k to RFC 5018 for connection establishment.

RFC 5018 does not d= eal with DTLS. Unless we restrict DTLS to cases in which SDP offer/answer i= s used, we need to update RFC 5018 to deal with DTLS. Someone please tell me otherwise.

=C2=A0

Section 6.2 of draf= t-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC 5018 when dealing = with BFCP over UDP or DTLS. I think this should be relocated to an update to RFC 5018, and connection reestablishment should be describ= ed as well.

=C2=A0

For (2), RFC 4582 p= rovides a teaser but points to RFC 4583 for the normative language. draft-i= etf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf-bfcpbis-rfc4583bis= -09. Christer comments are in regard to inconsistencies here. I provided commen= ts on those inline.

=C2=A0

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Tuesday, March 25, 2014 at 12:39 PM
To: "bfcp= bis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583= bis

=C2=A0

Hi,

=C2=A0

Section 7 in 4582bis, which says:

=C2=A0

=E2=80=9C7.=C2=A0 Lower-Layer Security

=C2=A0

=C2=A0=C2=A0 BFCP relies on lower-layer security mechanism= s to provide replay and

=C2=A0=C2=A0 integrity protection and confidentiality.=C2= =A0 BFCP floor control servers

=C2=A0=C2=A0 and clients (which include both floor partici= pants and floor chairs)

=C2=A0

=C2=A0=C2=A0 MUST support TLS for transport over TCP [6] a= nd MUST support DTLS [7]

=C2=A0=C2=A0 for transport over UDP.=C2=A0 Any BFCP entity= MAY support other security

=C2=A0=C2=A0 mechanisms.

=C2=A0

=C2=A0=C2=A0 BFCP entities MUST support, at a minimum, the=

=C2=A0=C2=A0 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=

=C2=A0

=C2=A0=C2=A0 Which party, the client or the floor control = server, acts as the TLS/

=C2=A0=C2=A0 DTLS server depends on how the underlying TLS= /DTLS connection is

=C2=A0=C2=A0 established.=C2=A0 For a TCP/TLS connection e= stablished using an SDP

=C2=A0=C2=A0 offer/answer exchange [9], the answerer (whic= h may be the client or

=C2=A0=C2=A0 the floor control server) always acts as the = TLS server.=C2=A0 If the TCP

=C2=A0=C2=A0 connection is lost, the active endpoint, i.e.= , the current TLS

=C2=A0=C2=A0 client, is responsible for re-establishing th= e TCP connection.

=C2=A0=C2=A0 Unless a new TLS session is negotiated, subse= quent SDP offers and

=C2=A0=C2=A0 answers will not impact the previously negoti= ated TLS roles.

=C2=A0

=C2=A0=C2=A0 For a UDP/DTLS connection established using t= he an SDP offer/answer

=C2=A0=C2=A0 exchange, either party can be the DTLS server= depending on the setup

=C2=A0=C2=A0 attributes exchanged; examples can be found i= n [23].=E2=80=9D

=C2=A0

First, we al= ready earlier discussed that the active TCP endpoint is responsible for re-= establishing the TCP connection, and that will be corrected in the next version of the draft.

=C2=A0

Yes.<= u>

=C2=A0

=C2=A0

However, we have discussed a similar topic in CLUE, = and we were wondering whether it would be good that, whoever detects a conn= ection failure, sends a new offer in order to re-establish the connection. It does not matter if both endpoints send an offer =E2=80= =93 the offer/answer race condition rules will take care of that.=

=C2=A0

In CLUE, is this fo= r a TCP/TLS connection, or for a DTLS connection?

For DTLS, we specif= ically chose to alter the behavior, as described in section 9.1 of 4583bis:=

=C2=A0

=C2=A0 "Endpoi= nts that use the offer/answer model to establish a DTLS

=C2=A0 =C2=A0association MUST support the 'setup= ' attribute, as defined in [7].

=C2=A0 =C2=A0When DTLS is used with UDP, the 'se= tup' attribute indicates which of

=C2=A0 =C2=A0the endpoints (client or floor control = server) initiates the DTLS

=C2=A0 =C2=A0association setup. =C2=A0The requiremen= ts for the offer/answer exchange

=C2=A0 =C2=A0specified in [13], Section 5 MUST be fo= llowed when using DTLS.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 Informational note: How to dete= rmine which endpoint to initiate

=C2=A0 =C2=A0 =C2=A0 the TLS/DTLS association depend= s on the selected underlying

=C2=A0 =C2=A0 =C2=A0 transport. =C2=A0It was decided= to keep the original semantics in [15]

=C2=A0 =C2=A0 =C2=A0 for TCP to retain backwards com= patibility. =C2=A0When using UDP, the

=C2=A0 =C2=A0 =C2=A0 procedure above was preferred s= ince it adheres to [13] as used for

=C2=A0 =C2=A0 =C2=A0 DTLS-SRTP, it does not overload= offer/answer semantics, and it

=C2=A0 =C2=A0 =C2=A0 works for offerless INVITE in s= cenarios with B2BUAs."

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Second, Sect= ion 8.1 in 4583bis says:

=C2=A0

=C2=A0=C2=A0 =E2=80=9CWhen the existing TCP connection is reset following =
the rules in [8],
=C2=A0=C2=A0 the client MUST generate an offer towards the floor control s=
erver in
=C2=A0=C2=A0 order to reestablish the connection.=C2=A0 If a TCP connectio=
n cannot
=C2=A0=C2=A0 deliver a BFCP message and times out, the entity that attempt=
ed to
=C2=A0=C2=A0 send the message (i.e., the one that detected the TCP timeout=
) MUST
=C2=A0=C2=A0 generate an offer in order to reestablish the TCP connection.=
=E2=80=9D
=C2=A0
=C2=A0

I am not sure what is meant by =E2=80=9CTCP connecti= on is reset following the rules in [8]=E2=80=9D. Which rules are you referr= ing to?

=C2=A0

Reset means closed = and reestablished. The word =E2=80=9Creset=E2=80=9D was used in RFC 4582 an= d reused in 4582bis. Perhaps we should change it closed and reestablished to avoid confusion?

=C2=A0

=C2=A0

Then, the text says that the client always re-establ= ished the TCP connection. Is that aligned with the text in 4582bis, saying = that the active party does the reestablishment? Is the client always active?

=C2=A0

I think it is a little confusing that both 4582bis a= nd 4583bis defines SDP Offer/Answer procedures. Shouldn=E2=80=99t they only= be in 4583bis?

=C2=A0

Yes, I think so. RF= C 4582 mixed some SDP offer/answer text into its section on lower layer sec= urity, and 4582bis followed suit. It would be better to have all the details of connection establishment and reestablishment in= when using SDP offer/answer in 4583bis.=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Third, the l= ast paragraph, talking about UDP/DTLS, says that either party can be DTLS s= erver depending on the setup attributes exchanged. But, nowhere is it described how the setup attribute is used to determine the D= TLS server role J

=C2=A0

I assume it is done in the same way as for TCP/TLS, = but that is not written anywhere.

=C2=A0

The text I pasted from 4583bis above describes this.= If we put all the connection management stuff in 4583bis instead of leavin= g it split across 4582bis and 4583bis, this should be clear.

=C2=A0

Cheers,

Charles

=C2=A0

=C2=A0

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis



=C2=A0

--
# Cisco =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om =C2=A0| =C2=A0= http://www.tandberg.com
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/




--
# Cisco =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.com =C2=A0| =C2=A0http://www.tandberg.com<= br> ### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/
--001a113a665a097fcd04f73f794f-- From nobody Thu Apr 17 14:35:27 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDED1A01C5 for ; Thu, 17 Apr 2014 14:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 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, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kw8-WHB0oru for ; Thu, 17 Apr 2014 14:35:22 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 9965E1A01C3 for ; Thu, 17 Apr 2014 14:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38813; q=dns/txt; s=iport; t=1397770518; x=1398980118; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KMMEaXrToMuEYuPn/Dq1BXvH1TDIWVY4nI+pe1fxB84=; b=heA/OwlphFcjMvNgefImiINqiBPcrAJAyP0Pj43OmVkNSVZV141OvLsd VDP880F+XMb5ML2ldeF7OOHh8fWWhE6hDBe4DpbGj5IfwvSnLDIJbPyzO 6WkBPaNXpK+tDa4AugOY7JkuiORaLy8en4wsGFF7/Svyj5ArMD3nJ2vWy 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcFAONIUFOtJA2I/2dsb2JhbABZgkJEO1e6cIE/hmZSgSgWdIIlAQEBBAEBAVIZCxACAQgOAwMBAQEhAQYHIQYLFAkIAgQBDQUbh00DEQ3FHg2GaxeJPYMMgggNBAYBBgOELwSFZI8cggCBboE3i0YDhU2DMYFpBzs X-IronPort-AV: E=Sophos; i="4.97,881,1389744000"; d="scan'208,217"; a="36746032" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 17 Apr 2014 21:35:02 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3HLZ2Vs013407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 21:35:02 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 16:35:01 -0500 From: "Charles Eckel (eckelcu)" To: Tom Kristensen <2mkristensen@gmail.com>, Christer Holmberg Thread-Topic: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Thread-Index: AQHPSUic50RqEV5EM0G8qoAclTNxQpr39BsggBz9UICAADb0AIABTAAA///hUYA= Date: Thu, 17 Apr 2014 21:35:01 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D26AD25@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2CC894@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.75.189] Content-Type: multipart/alternative; boundary="_000_CF7593242681Deckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/b3C7ADp446e1eYLQ7mmdigiFSeM Cc: "bfcpbis@ietf.org" , "Tom Kristensen \(tomkrist\)" Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 21:35:27 -0000 --_000_CF7593242681Deckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable That no one caught this sooner is another good indication there is no real = need for a non offer/answer mechanism when using BFCP UDP/DTLS. I would be = willing to sacrifice completeness for simplicity and restrict BFCP over UDP= /DTLS to offer/answer usages. Having taken another look at RFC 5763, dealin= g with connection reestablishment via another offer/answer exchange seems a= ppropriate as well. Cheers, Charles From: Tom Kristensen <2mkristensen@gmail.com= > Date: Thursday, April 17, 2014 at 9:24 AM To: Christer Holmberg > Cc: Charles Eckel >, "bfcpbis@i= etf.org" >, Tom Kristensen > Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis I have never heard of any need for a non-O/A mechanism, UDP/DTLS is current= ly used by vendors utilizing offer/answer in a SIP context. On 16 April 2014 22:36, Christer Holmberg > wrote: Hi, >It would be much clearer and less confusing to have all the SDP offer/answ= er related >procedures in rfc4583bis. I agree and have started working on i= t, i.e. moving content to >rfc4583bis and polishing text in rfc4582bis. > >However, what do people on this list think about the concerns and sketch f= or solving this >issue proposed by Charles? > >And specifically: Do we want to (i) update RFC 5018 with UDP / DTLS or do = we think it is >even thinkable/doable to (ii) specify UDP / DTLS as a trans= port only when offer/answer is >used? (Not a clean approach, but very pragm= atic ;) ) Well, has anyone requested a non-O/A mechanism? Regards, Christer On 29 March 2014 12:40, Christer Holmberg > wrote: Hi Charles, Without commenting on specifics at this point, I really think we should try= to get the SDP Offer/Answer procedures into one place (4583bis). 4582bis can define actions taken by the DTLS client and server, but should = not define how those roles are determined. 4583bis then defines how the rol= es are determined when using SDP O/A. Regards, Christer From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] Sent: 27 March 2014 01:11 To: Christer Holmberg Cc: bfcpbis@ietf.org Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Hi Christer, Thanks for your comments. The more I looked into them the more complex and = tangled things became. Let me try to walk through the current state of affa= irs and then propose a potential solutions. RFC 4582 breaks connection establishment into two cases: 1. when SDP offer/answer IS NOT used 2. when SDP offer/answer IS used For (1), RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds= a reference to RFC 5239 for XCON. RFC 5018 deals with the connection establishment, reestablishment, and TLS= usage. RFC 5239 points back to RFC 5018 for connection establishment. RFC 5018 does not deal with DTLS. Unless we restrict DTLS to cases in which= SDP offer/answer is used, we need to update RFC 5018 to deal with DTLS. So= meone please tell me otherwise. Section 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC= 5018 when dealing with BFCP over UDP or DTLS. I think this should be reloc= ated to an update to RFC 5018, and connection reestablishment should be des= cribed as well. For (2), RFC 4582 provides a teaser but points to RFC 4583 for the normativ= e language. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf= -bfcpbis-rfc4583bis-09. Christer comments are in regard to inconsistencies = here. I provided comments on those inline. From: Christer Holmberg > Date: Tuesday, March 25, 2014 at 12:39 PM To: "bfcpbis@ietf.org" > Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Hi, Section 7 in 4582bis, which says: =937. Lower-Layer Security BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS for transport over TCP [6] and MUST support DTLS [7] for transport over UDP. Any BFCP entity MAY support other security mechanisms. BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. Which party, the client or the floor control server, acts as the TLS/ DTLS server depends on how the underlying TLS/DTLS connection is established. For a TCP/TLS connection established using an SDP offer/answer exchange [9], the answerer (which may be the client or the floor control server) always acts as the TLS server. If the TCP connection is lost, the active endpoint, i.e., the current TLS client, is responsible for re-establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. For a UDP/DTLS connection established using the an SDP offer/answer exchange, either party can be the DTLS server depending on the setup attributes exchanged; examples can be found in [23].=94 First, we already earlier discussed that the active TCP endpoint is respons= ible for re-establishing the TCP connection, and that will be corrected in = the next version of the draft. Yes. However, we have discussed a similar topic in CLUE, and we were wondering w= hether it would be good that, whoever detects a connection failure, sends a= new offer in order to re-establish the connection. It does not matter if b= oth endpoints send an offer =96 the offer/answer race condition rules will = take care of that. In CLUE, is this for a TCP/TLS connection, or for a DTLS connection? For DTLS, we specifically chose to alter the behavior, as described in sect= ion 9.1 of 4583bis: "Endpoints that use the offer/answer model to establish a DTLS association MUST support the 'setup' attribute, as defined in [7]. When DTLS is used with UDP, the 'setup' attribute indicates which of the endpoints (client or floor control server) initiates the DTLS association setup. The requirements for the offer/answer exchange specified in [13], Section 5 MUST be followed when using DTLS. Informational note: How to determine which endpoint to initiate the TLS/DTLS association depends on the selected underlying transport. It was decided to keep the original semantics in [15] for TCP to retain backwards compatibility. When using UDP, the procedure above was preferred since it adheres to [13] as used for DTLS-SRTP, it does not overload offer/answer semantics, and it works for offerless INVITE in scenarios with B2BUAs." Second, Section 8.1 in 4583bis says: =93When the existing TCP connection is reset following the rules in [8], the client MUST generate an offer towards the floor control server in order to reestablish the connection. If a TCP connection cannot deliver a BFCP message and times out, the entity that attempted to send the message (i.e., the one that detected the TCP timeout) MUST generate an offer in order to reestablish the TCP connection.=94 I am not sure what is meant by =93TCP connection is reset following the rul= es in [8]=94. Which rules are you referring to? Reset means closed and reestablished. The word =93reset=94 was used in RFC = 4582 and reused in 4582bis. Perhaps we should change it closed and reestabl= ished to avoid confusion? Then, the text says that the client always re-established the TCP connectio= n. Is that aligned with the text in 4582bis, saying that the active party d= oes the reestablishment? Is the client always active? I think it is a little confusing that both 4582bis and 4583bis defines SDP = Offer/Answer procedures. Shouldn=92t they only be in 4583bis? Yes, I think so. RFC 4582 mixed some SDP offer/answer text into its section= on lower layer security, and 4582bis followed suit. It would be better to = have all the details of connection establishment and reestablishment in whe= n using SDP offer/answer in 4583bis. Third, the last paragraph, talking about UDP/DTLS, says that either party c= an be DTLS server depending on the setup attributes exchanged. But, nowhere= is it described how the setup attribute is used to determine the DTLS serv= er role :) I assume it is done in the same way as for TCP/TLS, but that is not written= anywhere. The text I pasted from 4583bis above describes this. If we put all the conn= ection management stuff in 4583bis instead of leaving it split across 4582b= is and 4583bis, this should be clear. Cheers, Charles Regards, Christer _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ --_000_CF7593242681Deckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <21010D1364A175449A3A27AC849A2F2C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
That no one caught this sooner is another good indication there is no = real need for a non offer/answer mechanism when using BFCP UDP/DTLS. I woul= d be willing to sacrifice completeness for simplicity and restrict BFCP ove= r UDP/DTLS to offer/answer usages. Having taken another look at RFC 5763, dealing with connection reestablish= ment via another offer/answer exchange seems appropriate as well.

Cheers,
Charles
 
From: Tom Kristensen <2mkristensen@gmail.com>
Date: Thursday, April 17, 2014 at 9= :24 AM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Charles Eckel <eckelcu@cisco.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Tom Kristensen <tomkrist@cisco.com>
Subject: Re: [bfcpbis] TCP/TLS and = UDP/DTLS comments on 4582bis and 4583bis

I have never heard of any need for a non-O/A mechanism, UD= P/DTLS is currently used by vendors utilizing offer/answer in a SIP context= .


On 16 April 2014 22:36, Christer Holmberg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

>It would be= much clearer and less confusing to have all the SDP offer/answer related >procedures in rfc4583bis. I agree = and have started working on it, i.e. moving content to >rfc4583bis and polishing text in r= fc4582bis.

>&nbs= p;

>However, wh= at do people on this list think about the concerns and sketch for solving t= his >issue proposed by Charles?<= u>

>&nbs= p;

>And specifi= cally: Do we want to (i) update RFC 5018 with UDP / DTLS or do we think it = is >even thinkable/doable to (ii) spec= ify UDP / DTLS as a transport only when offer/answer is >used? (Not a clean approach, but v= ery pragmatic ;) )

 

Well, has anyone requested a non-O/= A mechanism?

 

Regards,

 

Christer

 

 <= /p>

On 29 March 2014 12:40, Christer Holmberg <christer.holm= berg@ericsson.com> wrote:

Hi Charles,<= /u>

 

Without commenting on = specifics at this point, I really think we should try to get the SDP Offer/= Answer procedures into one place (4583bis).

 

4582bis can define act= ions taken by the DTLS client and server, but should not define how those r= oles are determined. 4583bis then defines how the roles are determined when= using SDP O/A.

 

Regards,=

 

Christer=

 

From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
Sent: 27 March 2014 01:11
To: Christer Holmberg
Cc: bfcpbis@ie= tf.org
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and = 4583bis

 

Hi Christer,=

 

Thanks for your com= ments. The more I looked into them the more complex and tangled things beca= me. Let me try to walk through the current state of affairs and then propos= e a potential solutions.

 

RFC 4582 breaks con= nection establishment into two cases:

  1. when SDP offer/ans= wer IS NOT used
  2. when SDP offer/answer IS used

For (1), RFC 4582 p= oints to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds a reference to RFC= 5239 for XCON.

RFC 5018 deals with= the connection establishment, reestablishment,  and TLS usage.=

RFC 5239 points bac= k to RFC 5018 for connection establishment.

RFC 5018 does not d= eal with DTLS. Unless we restrict DTLS to cases in which SDP offer/answer i= s used, we need to update RFC 5018 to deal with DTLS. Someone please tell m= e otherwise.

 

Section 6.2 of draf= t-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC 5018 when dealing = with BFCP over UDP or DTLS. I think this should be relocated to an update t= o RFC 5018, and connection reestablishment should be described as well.

 

For (2), RFC 4582 p= rovides a teaser but points to RFC 4583 for the normative language. draft-i= etf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf-bfcpbis-rfc4583bis= -09. Christer comments are in regard to inconsistencies here. I provided comments on those inline.

 

From: Christer Holmberg <christer.holmberg@ericss= on.com>
Date: Tuesday, March 25, 2014 at 12:39 PM
To: "bfcp= bis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583= bis

 

Hi,

 

Section 7 in 4582bis, which says:

 

=937.  Lower-Layer Security

 

   BFCP relies on lower-layer security mechanisms to pro= vide replay and

   integrity protection and confidentiality.  BFCP = floor control servers

   and clients (which include both floor participants an= d floor chairs)

 

   MUST support TLS for transport over TCP [6] and MUST = support DTLS [7]

   for transport over UDP.  Any BFCP entity MAY sup= port other security

   mechanisms.

 

   BFCP entities MUST support, at a minimum, the<= u>

   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].<= u>

 

   Which party, the client or the floor control server, = acts as the TLS/

   DTLS server depends on how the underlying TLS/DTLS co= nnection is

   established.  For a TCP/TLS connection establish= ed using an SDP

   offer/answer exchange [9], the answerer (which may be= the client or

   the floor control server) always acts as the TLS serv= er.  If the TCP

   connection is lost, the active endpoint, i.e., the cu= rrent TLS

   client, is responsible for re-establishing the TCP co= nnection.

   Unless a new TLS session is negotiated, subsequent SD= P offers and

   answers will not impact the previously negotiated TLS= roles.

 

   For a UDP/DTLS connection established using the an SD= P offer/answer

   exchange, either party can be the DTLS server dependi= ng on the setup

   attributes exchanged; examples can be found in [23].= =94

 

First, we al= ready earlier discussed that the active TCP endpoint is responsible for re-= establishing the TCP connection, and that will be corrected in the next ver= sion of the draft.

 

Yes.<= u>

 

 

However, we have discussed a similar topic in CLUE, = and we were wondering whether it would be good that, whoever detects a conn= ection failure, sends a new offer in order to re-establish the connection. = It does not matter if both endpoints send an offer =96 the offer/answer race condition rules will take care of = that.

 

In CLUE, is this fo= r a TCP/TLS connection, or for a DTLS connection?

For DTLS, we specif= ically chose to alter the behavior, as described in section 9.1 of 4583bis:=

 

  "Endpoi= nts that use the offer/answer model to establish a DTLS

   association MUST support the 'setup' at= tribute, as defined in [7].

   When DTLS is used with UDP, the 'setup'= attribute indicates which of

   the endpoints (client or floor control = server) initiates the DTLS

   association setup.  The requiremen= ts for the offer/answer exchange

   specified in [13], Section 5 MUST be fo= llowed when using DTLS.

 

      Informational note: How to dete= rmine which endpoint to initiate

      the TLS/DTLS association depend= s on the selected underlying

      transport.  It was decided= to keep the original semantics in [15]

      for TCP to retain backwards com= patibility.  When using UDP, the

      procedure above was preferred s= ince it adheres to [13] as used for

      DTLS-SRTP, it does not overload= offer/answer semantics, and it

      works for offerless INVITE in s= cenarios with B2BUAs."

 

 

 

 

Second, Sect= ion 8.1 in 4583bis says:

 

   =93When=
 the existing TCP connection is reset following the rules in [8],=

   the cli=
ent MUST generate an offer towards the floor control server in
   order t=
o reestablish the connection.  If a TCP connection cannot
   deliver=
 a BFCP message and times out, the entity that attempted to
   send th=
e message (i.e., the one that detected the TCP timeout) MUST<=
u>
   generat=
e an offer in order to reestablish the TCP connection.=94<=
/u>
 =

 =

I am not sure what is meant by =93TCP connection is = reset following the rules in [8]=94. Which rules are you referring to?

 

Reset means closed = and reestablished. The word =93reset=94 was used in RFC 4582 and reused in = 4582bis. Perhaps we should change it closed and reestablished to avoid conf= usion?

 

 

Then, the text says that the client always re-establ= ished the TCP connection. Is that aligned with the text in 4582bis, saying = that the active party does the reestablishment? Is the client always active= ?

 

I think it is a little confusing that both 4582bis a= nd 4583bis defines SDP Offer/Answer procedures. Shouldn=92t they only be in= 4583bis?

 

Yes, I think so. RF= C 4582 mixed some SDP offer/answer text into its section on lower layer sec= urity, and 4582bis followed suit. It would be better to have all the detail= s of connection establishment and reestablishment in when using SDP offer/answer in 4583bis. 

 

 

 

 

Third, the l= ast paragraph, talking about UDP/DTLS, says that either party can be DTLS s= erver depending on the setup attributes exchanged. But, nowhere is it descr= ibed how the setup attribute is used to determine the DTLS server role J<= /span>

 

I assume it is done in the same way as for TCP/TLS, = but that is not written anywhere.

 

The text I pasted from 4583bis above describes this.= If we put all the connection management stuff in 4583bis instead of leavin= g it split across 4582bis and 4583bis, this should be clear.<= /p>

 

Cheers,

Charles

 

 

 

Regards,

 

Christer

 


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis



 

--
# Cisco                   &nbs= p;     |  http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###                     &= nbsp;         |  http://folk.uio.no/tomkri/




--
# Cisco                   &nbs= p;     |  http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###                     &= nbsp;         |  http://folk.uio.no/tomkri/
--_000_CF7593242681Deckelcuciscocom_--