From nobody Fri Feb 1 07:03:16 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066381277CC for ; Fri, 1 Feb 2019 07:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.936 X-Spam-Level: ** X-Spam-Status: No, score=2.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy-S4B8gVxeI for ; Fri, 1 Feb 2019 07:03:10 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293531276D0 for ; Fri, 1 Feb 2019 07:03:10 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.176.248.72; From: "Susan Hares" To: "'Dongjie \(Jimmy\)'" , "'Borchert, Oliver \(Fed\)'" , , "'Borchert, Oliver \(Fed\)'" Cc: References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <009501d4b7f1$962d0080$c2870180$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927C3286B43@NKGEML515-MBX.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927C3286B43@NKGEML515-MBX.china.huawei.com> Date: Fri, 1 Feb 2019 10:02:52 -0500 Message-ID: <00e201d4ba3f$34bb67b0$9e323710$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E3_01D4BA15.4BEC6490" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rAb/ZDQcBMZz+VgGA2nz4pFFXa9A= Content-Language: en-us X-Antivirus: AVG (VPS 190201-4, 02/01/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 15:03:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E3_01D4BA15.4BEC6490 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable JIe, Bruno and Oliver:=20 =20 Thank you for your input. You are correct that the error handling = behavior was unclear based on the questions in the chart. The purpose = of the chart is to provide other BGP WGs (Bess, SPRING, LSVR) a clear = indication of changes to the base BGP specification.=20 =20 I=E2=80=99ve reformatted sections 4 and 5 of the chart. =20 =20 To section 4 I=E2=80=99ve added:=20 4c Does send Extended Message - with a yes from all = implementations (based on their email)=20 =20 Section 5, I=E2=80=99ve alter to be:=20 5 Error handing =20 5a Accepts Extended message without receiving=20 BGP Extended Message Capability [Section 5 paragraph 1 MAY] =20 5b If receives Extended Message without BGP extended message = support, follows RFC4271 handling and sends Bad message length = Notification=20 [section 5 paragraph 2 MUST]=20 =20 Oliver =E2=80=93 if you would read the current text and let me know the = updated message. I believe the answer for all 3 implementations is = =E2=80=9Cyes=E2=80=9D due to 4b. Please let me know and I will update = the information in the chart.=20 =20 To follow-up on Jie=E2=80=99s comments, the text did not accurately = represent the error handling. Section 5, paragraph 1 has a = =E2=80=9CSHOULD NOT=E2=80=9D modified by a =E2=80=9CMAY=E2=80=9D, which = results in simply a =E2=80=9CMAY=E2=80=9D. For readability, I think = the =E2=80=9CSHOULD NOT=E2=80=9D provides useful information to the = implementer, but it cannot be tested accurately when combined with the = =E2=80=9CMAY=E2=80=9D. =20 =20 Let me give you an example of that: If the peer did not send a BGP Extended Message capability, and it = accepts the extended message (with a length of 10,000 bytes), it could = have a liberal policy of MAY as a default in the implementation. The = =E2=80=9Con-wire=E2=80=9D observations cannot tell =E2=80=93 only the = implementation=E2=80=99s policy (default + configured). =20 =20 I also broke out the management information away from the specification = information. =20 =20 Sue Hares =20 =20 From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com]=20 Sent: Wednesday, January 30, 2019 8:53 PM To: Borchert, Oliver (Fed); Susan Hares; bruno.decraene@orange.com; = Borchert, Oliver (Fed) Cc: idr@ietf.org Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Hi Oliver, Bruno and Sue, =20 To my understanding, bullet 5/5a/5b in the implementation report is = corresponding to the second paragraph in section 5 =E2=80=9CError = Handling=E2=80=9D: =20 A BGP speaker that does not advertise the BGP Extended Messages capability might also genuinely not support Extended Messages. Such a speaker MUST follow the error handling procedures of [RFC4271] if it receives an Extended Message. Similarly, any speaker that treats an improper Extended Message as a fatal error, MUST treat it similarly. =20 Thus it is to describe the error handling behavior of an implementation = version which does not support extended message.=20 =20 While I agree this could be misleading for a report of implementation = which supports extended message capability, maybe it could be used to = verify the behavior of an old version which does not support this = capability? =20 Best regards, Jie =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Borchert, Oliver = (Fed) Sent: Wednesday, January 30, 2019 4:35 AM To: Susan Hares ; bruno.decraene@orange.com; Borchert, = Oliver (Fed) Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Bruno and Susan, =20 I cannot speak for the ExaBGP Implementation but for BGPSEC-IO and = QuaggaSRx. I believe when I compiled the report, I mis-read 5a and overlooked the = =E2=80=9Cnot=E2=80=9D and read instead: =E2=80=9CDoes send Extended = Message Capability=E2=80=9D. Therefore the implementation report for section 5a must be corrected = from =E2=80=9CYes=E2=80=9D into =E2=80=9CNo=E2=80=9D for both BGPSEC-IO = and QuaggaSRx =20 BGPSEC-IO and QuaggaSRx, both do send the extended message capability if = so configured. I just checked the code and run it again. I copy/pasted the relevant = output generated by BGPSEC-IO, =20 Oliver =20 ----- output of BGPSEC-IO ------- =20 =EF=BB=BF./bgpsecio -f bgpsecio.test.cfg.qsrx=20 Starting bgpsecio 0.2.0.25... Send: (Open message send from BGPSEC-IO to QuaggaSRx)=20 OPEN Message +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF =E2=80=A6 +--Optional Parameter: Capability | +--Type: Capability (2) | +--Length: 2 | +--Capability: Extended message support capability | +--Type: Extended message support capability (6) | +--Length: 0 =E2=80=A6 =20 Received: (Open message send from QuaggaSRx and received by BGPSEC-IO) OPEN Message +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF =E2=80=A6 +--Optional Parameter: Capability +--Type: Capability (2) +--Length: 2 +--Capability: Extended message support capability +--Type: Extended message support capability (6) +--Length: 0 BGP-receiver thread created! =20 =20 =20 From: Idr on behalf of Susan Hares = Date: Tuesday, January 29, 2019 at 11:43 AM To: "bruno.decraene@orange.com" Cc: "idr@ietf.org" Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Bruno: =20 Thank you for your comments on this topic =E2=80=93 as I think=20 =20 I did receive reports privately that we have 1 full implementations of = draft-ietf-idr-bgp-extended-messages off list which is not listed in = this report. I hope those implementers will volunteer this information = on the list. If not, I will share this information with Alvaro and the = IESG. =20 =20 The SIDR work did define draft-ietf-bgp-extended-messages as a = requirement and only moved to not specifying it when we could not = quickly pass this through WG LC.=20 =20 The real needs are a growing BGP-LS that may run out of BGP message = space. As my previous email to IDR indicates, I was hoping this handles = an BGP message whose length is bigger than 4096 bytes. Thank you for = the correction of:=20 =20 =E2=80=9CThe issue is not specific to attributes bigger than 4096 = octets, but to BGP message whose length is bigger than 4096, = irrespective of the size of each attribute.=E2=80=9D =20 =20 As to your comment:=20 =20 =E2=80=9CWhy is this limited to future specifications? A priori, using = existing BGP mechanism (AFI/SAFI, attributes, * communities) one could = exceed the size of 4096 octets. How does the BGP speaker supposed to = behave in this case? This should be described in this specification. = Note that this is not a case of error handling, as every BGP speaker is = behaving as specified.=E2=80=9D =20 This problem has been true for years, and thus as co-chairs had hoped to = have the draft-ietf-bgp-extended-messages passed years ago. As BGP-LS = attributes grow use and in number, the potential of exceeding the BGP = message limit increases. It seems like a good direction to prevent = issues.=20 =20 I hope the authors will comment on the changes you suggested to the = text.=20 =20 Cheers,=20 Susan Hares=20 =20 =20 =20 From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Sent: Tuesday, January 29, 2019 8:33 AM To: Susan Hares Cc: idr@ietf.org Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Hi WG, =20 Please find below some comments. As of today, I don=E2=80=99t believe this specification is ready to be = progressed to IESG/RFC, especially for a document updating RFC 4271 = (core BGP spec). =20 > The WG chairs intend to forward this draft to the IESG with the = current level of implementation. =20 =20 https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations = = says : 5a=20 Does not send Extended Message capability=20 Yes=20 Yes=20 Yes=20 =20 I may be misunderstanding the implementation report, but my reading of = the above is that none of the reported implementations sends the = capability hence no implementation supports = draft-ietf-idr-bgp-extended-messages.. Here this document is updating = RFC 4271, so it is not a minor extension for a niche use case. So I = don=E2=80=99t see the arguments for not requiring the IDR=E2=80=99s = usual two interoperable implementations. =20 ---- =C2=A7 1 =E2=80=9C As BGP is extended to support newer AFI/SAFIs and newer capabilities (e.g., [ = I-D.ietf-sidr-bgpsec-protocol]), there is a need to extend the maximum message size beyond 4096 octets. = =E2=80=9C =20 https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on-1 = =20 =20 =20 [ = I-D.ietf-sidr-bgpsec-protocol is now RFC 8205 (thanks = for updating the reference). It has removed the normative/any reference = to draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not = need draft-ietf-idr-bgp-extended-messages. Can we have an update on this? Can the introduction of draft-ietf-idr-bgp-extended-messages be updated = to introduce on the real reasons/needs? =20 ---- =C2=A74 =C2=A73 says =E2=80=9CA peer which does not advertise this capability = MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.=E2=80=9D =20 Fine. Text in =C2=A74 should probably be aligned with the above ..e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. =20 NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and = received the Extended Message Capability to and from that peer. =20 ---- =E2=80=9C Applications generating information which might be = encapsulated within BGP messages MUST limit the size of their payload to take the maximum message size into account.=E2=80=9D =20 I don=E2=80=99t see what new behavior is been defined here. If there is = none, I would suggest to remove this sentence =20 ---- A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. =20 =20 The issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than 4096, irrespective of the size = of each attribute. Please elaborate on what you mean by =E2=80=9Can attribute which can not = be decomposed to 4096 octets=E2=80=9D =20 --- =E2=80=9C It is RECOMMENDED that BGP protocol developers and = implementers are conservative in their application and use of Extended = Messages.=E2=80=9D =20 What does this mean exactly? That they don=E2=80=99t use this extension? = That they don=E2=80=99t use this extension unless XX_TO BE SPECIFIED_XX? =20 --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages. =20 Why is this limited to future specifications? A priori, using existing = BGP mechanism (AFI/SAFI, attributes, * communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = case? This should be described in this specification. Note that this is = not a case of error handling, as every BGP speaker is behaving as = specified. =20 =20 ---- Depending on the above specification, a section describing the = operational consequences in a network (such as the Internet, BGP Enabled = ServiceS/VPN networks) is probably needed. Possible consequences could = be BGP NLRI being removed in the middle of such network, or (extended) = community (such as Route Targets) been removed. Both having significant = consequences on the availability provided by the network. =20 --- =C2=A74 OLD: The Extended Message Capability only applies to all messages except = for the OPEN message.=20 Probably NEW: The Extended Message Capability applies to all message types except = for the OPEN message (type 1).=20 ---- =C2=A78 =E2=80=9CThis extension to BGP does not change BGP's underlying security = issues =C2=BB Before evaluating this, I think this document should first specified how = a BGP messages bigger than 4096 octets is handled when it needs to be = sent to a received not supporting this extension. =20 Nits: OLD : to reduce compexity NEW : to reduce complexity =20 Thanks, --Bruno =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org Subject: [Idr] WG Last Call on Extened Message Support =20 =20 This begins a 2 week WG LC on Extended Message Support for BGP = (draft-ietf-idr-bgp-extended-messages-27). You can access the draft at: = =20 = = https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ =20 The authors should indicate whether they know of any IPR. Implementers = are encouraged to update the implementation data at:=20 =20 = = = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations =20 The draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages. BGP message space is running = short for all of the potential attributes or additions proposed by = BGP-LS features. =20 =20 The WG chairs intend to forward this draft to the IESG with the current = level of implementation. =20 =20 As you comment on the draft, please consider if: a) the technology is = mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for = publication. =20 =20 Sue Hares (WG Chair, Shepherd)=20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. ------=_NextPart_000_00E3_01D4BA15.4BEC6490 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

JIe, Bruno and Oliver:

 

Thank you for your input.=C2=A0=C2=A0 You are correct that the error = handling behavior was unclear based on the questions in the chart. = =C2=A0=C2=A0The purpose of the chart is to provide other BGP WGs (Bess, = SPRING, LSVR) a clear indication of changes to the base BGP = specification.

 

I=E2=80=99ve reformatted sections 4 and 5 of the chart.=C2=A0 =

 

To section 4 I=E2=80=99ve added:

4c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Does send Extended Message =C2=A0- with a yes from all implementations = (based on their email)

 

Section 5, I=E2=80=99ve alter to be:

5=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Error = handing=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =

5a=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Accepts Extended message without receiving

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0BGP Extended Message Capability [Section 5 paragraph 1 = MAY]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =

5b=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If = receives Extended Message without BGP extended message = support,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0follows RFC4271 handling and sends Bad message length Notification =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= [section 5 paragraph 2 MUST]

 

Oliver =E2=80=93 if you would read the current text and let me know = the updated message. =C2=A0I believe the answer for all 3 = implementations is =E2=80=9Cyes=E2=80=9D due to 4b.=C2=A0=C2=A0 Please = let me know and I will update the information in the chart. =

 

To follow-up on Jie=E2=80=99s comments, the text did not accurately = represent the error handling.=C2=A0 =C2=A0Section 5, paragraph 1 has a = =E2=80=9CSHOULD NOT=E2=80=9D modified by a =E2=80=9CMAY=E2=80=9D, which = results in simply a =E2=80=9CMAY=E2=80=9D.=C2=A0 =C2=A0For readability, = I think the =E2=80=9CSHOULD NOT=E2=80=9D provides useful = information=C2=A0 to the implementer, =C2=A0but it cannot be tested = accurately when combined with the =E2=80=9CMAY=E2=80=9D.=C2=A0 = =C2=A0=C2=A0

 

Let me give you an example of that:

If the peer did not send a BGP Extended Message capability, and it = accepts the extended message (with a length of 10,000 bytes), it could = have a liberal policy of MAY as a default in the implementation. = =C2=A0=C2=A0The =E2=80=9Con-wire=E2=80=9D observations cannot tell = =E2=80=93 only the implementation=E2=80=99s policy (default + = configured).=C2=A0=C2=A0=C2=A0

 

I also broke out the management information away from the = specification information.=C2=A0

 

Sue Hares =C2=A0

 

From:= = Dongjie (Jimmy) [mailto:jie.dong@huawei.com]
Sent: Wednesday, = January 30, 2019 8:53 PM
To: Borchert, Oliver (Fed); Susan = Hares; bruno.decraene@orange.com; Borchert, Oliver (Fed)
Cc: = idr@ietf.org
Subject: RE: [Idr] WG Last Call on Extened = Message Support

 

Hi Oliver, Bruno and = Sue,

 

To my understanding, bullet 5/5a/5b in the = implementation report is corresponding to the second paragraph in = section 5 =E2=80=9CError Handling=E2=80=9D:

 

A BGP speaker that does not advertise the = BGP Extended Messages

   capability might also = genuinely not support Extended Messages.  = Such

   a speaker MUST follow the = error handling procedures of [RFC4271] if

   it receives an Extended = Message.  Similarly, any speaker that = treats

   an improper Extended Message = as a fatal error, MUST treat it

   = similarly.

 

Thus it is to describe the error handling = behavior of an implementation version which does not support extended = message.

 

While I agree this could be misleading for = a report of implementation which supports extended message capability, = maybe it could be used to verify the behavior of an old version which = does not support this capability?

 

Best regards,

Jie

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of = Borchert, Oliver (Fed)
Sent: Wednesday, January 30, 2019 = 4:35 AM
To: Susan Hares <shares@ndzh.com>; = bruno.decraene@orange.com; Borchert, Oliver (Fed) = <oliver.borchert@nist.gov>
Cc: = idr@ietf.org
Subject: Re: [Idr] WG Last Call on Extened = Message Support

 

Bruno and Susan,

 

I cannot speak for the ExaBGP Implementation but for = BGPSEC-IO and QuaggaSRx.

I believe when I compiled the report, I mis-read 5a and = overlooked the =E2=80=9Cnot=E2=80=9D and read instead: =E2=80=9CDoes = send Extended Message Capability=E2=80=9D.

Therefore the implementation report for section 5a must = be corrected from =E2=80=9CYes=E2=80=9D into =E2=80=9CNo=E2=80=9D for = both BGPSEC-IO and QuaggaSRx

 

BGPSEC-IO and QuaggaSRx, both do send the extended = message capability if so configured.

I just checked the code and run it again. I copy/pasted = the relevant output generated by BGPSEC-IO,

 

Oliver

 

-----  output of BGPSEC-IO  = -------

 

=EF=BB=BF./bgpsecio -f bgpsecio.test.cfg.qsrx =

Starting bgpsecio 0.2.0.25...

Send:  (Open message send from BGPSEC-IO to = QuaggaSRx)

OPEN Message

  +--marker: = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

=E2=80=A6

     +--Optional Parameter: = Capability

     |  +--Type: Capability = (2)

     |  +--Length: = 2

     |  +--Capability: Extended = message support capability

     |     = +--Type: Extended message support capability (6)

     |     = +--Length: 0

=E2=80=A6

 

Received: (Open message send from QuaggaSRx and received = by BGPSEC-IO)

OPEN Message

  +--marker: = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

=E2=80=A6

     +--Optional Parameter: = Capability

        +--Type: = Capability (2)

        +--Length: = 2

        = +--Capability: Extended message support = capability

         &nb= sp; +--Type: Extended message support capability = (6)

         &nb= sp; +--Length: 0

BGP-receiver thread created!

 

 

 

From: Idr <idr-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
Date: = Tuesday, January 29, 2019 at 11:43 AM
To: "bruno.decraene@orange.com&q= uot; <bruno.decraene@orange.com&g= t;
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: = [Idr] WG Last Call on Extened Message = Support

 

Bruno:

 

Thank you for your = comments on this topic =E2=80=93 as I think

 

I did receive reports = privately that we have 1 full implementations of = draft-ietf-idr-bgp-extended-messages off list which is not listed in = this report.   I hope those implementers will volunteer this = information on the list.   If not, I will share this = information with Alvaro and the IESG.   

 

The SIDR work did define = draft-ietf-bgp-extended-messages as a requirement and only moved to not = specifying it when we could not quickly pass this through WG LC. =

 

The real needs are a = growing BGP-LS that may run out of BGP message space.  As my = previous email to IDR indicates, I was hoping this handles an BGP = message whose length is bigger than 4096 bytes.   Thank you = for the correction of:

 

=E2=80=9CThe issue is not = specific to attributes bigger than 4096 octets, but to BGP message whose = length is bigger than 4096, irrespective of the size of each = attribute.=E2=80=9D

 

 

As to your comment: =

 

=E2=80=9CWhy is this limited to future = specifications? A priori, using existing BGP mechanism (AFI/SAFI, = attributes, * communities) one could exceed the size of 4096 octets. How = does the BGP speaker supposed to behave in this case? This should be = described in this specification. Note that this is not a case of error = handling, as every BGP speaker is behaving as = specified.=E2=80=9D

 

This problem has been true for years, = and thus as co-chairs had hoped to have the = draft-ietf-bgp-extended-messages passed years ago.   As BGP-LS = attributes grow use and in number, the potential of exceeding the BGP = message limit increases.  It seems like a good direction to prevent = issues.

 

I hope the authors will comment on the = changes you suggested to the text.

 

Cheers,

Susan Hares

 

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.co= m]
Sent: Tuesday, January 29, 2019 8:33 AM
To: = Susan Hares
Cc: idr@ietf.org
Subject: RE: = [Idr] WG Last Call on Extened Message Support

 

Hi WG,

 

Please find below some comments.

As of today, I don=E2=80=99t believe this specification is = ready to be progressed to IESG/RFC, especially for a document updating = RFC 4271 (core BGP spec).

 

> The WG chairs intend to forward this = draft to the IESG with the current level of implementation.  =

 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bg= p-extended-implementations says : 5a

Does not = send Extended Message capability

Yes =

Yes

Yes =

 

I may be misunderstanding the implementation report, but = my reading of the above is that none of the reported implementations = sends the capability hence no implementation supports = draft-ietf-idr-bgp-extended-messages.. Here this document is updating = RFC 4271, so it is not a minor extension for a niche use case. So I = don=E2=80=99t see the arguments for not requiring the IDR=E2=80=99s = usual two interoperable implementations.

 

----

=C2=A7 1

=E2=80=9C As BGP is extended to support = newer AFI/SAFIs and

   newer capabilities (e.g., = [I-D.ietf-sidr-bgpsec-protocol]), there is

   a need to extend the = maximum message size beyond 4096 octets.  =E2=80=9C

 

https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-mes= sages-27#section-1

 

 

[I-D.ietf-sidr-bgpsec-protocol is now RFC 8205 (thanks for updating the reference). It = has removed the normative/any reference to = draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not = need draft-ietf-idr-bgp-extended-messages.

Can we have an update on this?

Can the introduction of draft-ietf-idr-bgp-extended-messages be updated to = introduce on the real reasons/needs?

 

----

=C2=A74

=C2=A73 says =E2=80=9CA peer which does not advertise this =
capability MUST NOT send BGP

   Extended Messages, and BGP = Extended Messages MUST NOT be sent to it.=E2=80=9D

 

Fine. Text in =C2=A74 should probably be = aligned with the above ..e.g.

OLD: A BGP speaker

   MAY send Extended Messages = to its peer only if it has received the

   Extended Message = Capability from that peer.

 

NEW:

A BGP speaker

   MAY send Extended Messages = to its peer only if it has sent and received the

   Extended Message = Capability to and from that peer.

 

----

=E2=80=9C   Applications generating =
information which might be encapsulated

   within BGP messages MUST = limit the size of their payload to take the

   maximum message size into = account.=E2=80=9D

 

I don=E2=80=99t see what new behavior is been defined = here. If there is none, I would suggest to remove this = sentence

 

----

   A BGP announcement will, = in the normal case, propagate throughout the

   BGP speaking Internet; and = there will undoubtedly be BGP speakers

   which do not have the = Extended Message capability.  Therefore,

   putting an attribute which = can not be decomposed to 4096 octets or

   less in an Extended = Message is a likely path to routing failure.

 

 

The issue is not specific to attributes bigger = than 4096 octets, but to BGP message whose length is bigger than 4096, = irrespective of the size of each attribute.

Please elaborate on what you mean by = =E2=80=9Can attribute which can not be = decomposed to 4096 octets=E2=80=9D

 

---

=E2=80=9C   It is RECOMMENDED = that BGP protocol developers and implementers are

   conservative in their = application and use of Extended Messages.=E2=80=9D

 

What does this mean exactly? That they don=E2=80=99t use = this extension? That they don=E2=80=99t use this extension unless XX_TO = BE SPECIFIED_XX?

 

---

  Future protocol specifications = will need to describe how to handle

   peers which can only = accommodate 4096 octet messages.

 

Why is this limited to future specifications? A priori, = using existing BGP mechanism (AFI/SAFI, attributes, * communities) one = could exceed the size of 4096 octets. How does the BGP speaker supposed = to behave in this case? This should be described in this specification. = Note that this is not a case of error handling, as every BGP speaker is = behaving as specified.

 

 

----

Depending on the above specification, a = section describing the operational consequences in a network (such as = the Internet, BGP Enabled ServiceS/VPN networks) is probably needed. = Possible consequences could be BGP NLRI being removed in the middle of = such network, or (extended) community (such as Route Targets) been = removed. Both having significant consequences on the availability = provided by the network.

 

---

=C2=A74

OLD: The Extended Message Capability = only applies to all messages except for the OPEN message.

Probably

NEW: The Extended Message Capability = applies to all message types except for the OPEN message (type 1). =

----

=C2=A78

=E2=80=9CThis extension to BGP does not =
change BGP's underlying security issues =C2=BB
Before evaluating this, I think this =
document should first specified how a BGP messages bigger than 4096 =
octets is handled when it needs to be sent to a received not supporting =
this extension.

 

Nits:

OLD : to reduce = compexity

NEW : to reduce = complexity

 

Thanks,

--Bruno

 

From: Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Tuesday, January 29, = 2019 12:33 PM
To: idr@ietf.org
Subject: [Idr] = WG Last Call on Extened Message Support

 

 

This begins a 2 week WG LC on Extended Message = Support for BGP (draft-ietf-idr-bgp-extended-messages-27).  You can = access the draft at:

 

https://datat= racker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/=

 

The authors should indicate whether they know = of any IPR.   Implementers are encouraged to update the  = implementation data at:

 

https://trac.= ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations=

 

The draft provides a means for expanding the = BGP message to 65535 octets for all messages except OPEN messages.  = BGP message space is running short for all of the potential attributes = or additions proposed by BGP-LS features. 

 

The WG chairs intend to forward this draft to = the IESG with the current level of implementation. 

 

As you comment on the draft, please consider = if: a) the technology is mature, b) the additional space in a BGP = message would be helpful for those deploying BGP-LS or SR, and c) if the = specification is ready for publication. 

 

Sue Hares (WG Chair, Shepherd)

 

 

_______________________________________________________________________=
__________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or =
privileged information that may be protected by law;
they should not be distributed, used or copied without =
authorisation.
If you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
------=_NextPart_000_00E3_01D4BA15.4BEC6490-- From nobody Fri Feb 1 22:45:24 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C5A130EB8 for ; Fri, 1 Feb 2019 22:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjpFcjrWhRKO for ; Fri, 1 Feb 2019 22:45:18 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BC3130ECF for ; Fri, 1 Feb 2019 22:45:17 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6862AA4E0D2BE9122CF1 for ; Sat, 2 Feb 2019 06:45:15 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 2 Feb 2019 06:45:14 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.153]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Sat, 2 Feb 2019 14:45:08 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , "'Borchert, Oliver (Fed)'" , "bruno.decraene@orange.com" , "'Borchert, Oliver (Fed)'" CC: "idr@ietf.org" Thread-Topic: [Idr] WG Last Call on Extened Message Support Thread-Index: AQHUt9dKmADwclSnFUaw4UkRxVToD6XF7V8AgABA9ACAAm24gIAB7JIAgAFYtkA= Date: Sat, 2 Feb 2019 06:45:07 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927C32AEB75@NKGEML515-MBS.china.huawei.com> References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <009501d4b7f1$962d0080$c2870180$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927C3286B43@NKGEML515-MBX.china.huawei.com> <00e201d4ba3f$34bb67b0$9e323710$@ndzh.com> In-Reply-To: <00e201d4ba3f$34bb67b0$9e323710$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927C32AEB75NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 06:45:22 -0000 --_000_76CD132C3ADEF848BD84D028D243C927C32AEB75NKGEML515MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlLA0KDQpUaGFua3MgZm9yIHVwZGF0aW5nIHRoZSBpbXBsZW1lbnRhdGlvbiByZXBvcnQu DQoNCk15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgYnVsbGV0IDQgd2FzIHRvIGNvdmVyIHRoZSBi ZWhhdmlvciBvZiBzZWN0aW9uIDUgcGFyYWdyYXBoIDEsIGJ1bGxldCA1IHdhcyB0byBjb3ZlciB0 aGUgYmVoYXZpb3Igb2Ygc2VjdGlvbiA1IHBhcmFncmFwaCAyLg0KDQpCdXQgYWZ0ZXIgcmVyZWFk aW5nIHNlY3Rpb24gNSwgSSByZWFsaXplIHRoYXQgYm90aCBwYXJhZ3JhcGggMSBhbmQgMiBhcmUg dGFsa2luZyBhYm91dCB0aGUgYmVoYXZpb3Igb2YgYSBCR1Agc3BlYWtlciB3aGljaCBkb2VzIG5v dCBhZHZlcnRpc2UgdGhlIGV4dGVuZGVkIG1lc3NhZ2UgY2FwYWJpbGl0eSB0byBpdHMgcGVlciwg c28gcGVyaGFwcyBidWxsZXRzIDQgYW5kIDUgaW4gdGhlIGltcGxlbWVudGF0aW9uIHJlcG9ydCBj b3VsZCBiZSBtZXJnZWQgYXMgYmVsb3c6DQoNCjQuIFdoZW4gcmVjZWl2ZXMgYW4gZXh0ZW5kZWQg bWVzc2FnZSB3aXRob3V0IGFkdmVydGlzaW5nIHRoZSBCR1AgRXh0ZW5kZWQgTWVzc2FnZSBDYXBh YmlsaXR5IHRvIHRoaXMgcGVlciAoRXJyb3IgSGFuZGxpbmcpLg0KNGEuIEFjY2VwdHMgdGhlIGV4 dGVuZGVkIG1lc3NhZ2UgaWYgdGhlIEJHUCBzcGVha2VyIGlzIGFibGUgdG8gcHJvY2VzcyBleHRl bmRlZCBtZXNzYWdlIChidXQgd2FzIGNvbmZpZ3VyZWQgbm90IHRvIGFkdmVydGlzZSB0aGUgY2Fw YWJpbGl0eSkgICBbU2VjdGlvbiA1LCBwYXJhZ3JhcGggMSBNQVldDQo0Yi4gRG9lcyBub3QgYWNj ZXB0IHRoZSBleHRlbmRlZCBtZXNzYWdlLCBmb2xsb3dzIFJGQzQyNzEgaGFuZGxpbmcgYW5kIHNl bmRzIEJhZCBNZXNzYWdlIExlbmd0aCBOb3RpZmljYXRpb24gW1NlY3Rpb24gNSwgcGFyYWdyYXBo IDEgU0hPVUxEIE5PVCwgYW5kIHBhcmFncmFwaCAyIE1VU1QpDQoNCkhvcGUgdGhpcyBoZWxwcyB0 byByZWR1Y2UgdGhlIGNvbmZ1c2lvbi4NCg0KQmVzdCByZWdhcmRzLA0KSmllDQoNCg0KRnJvbTog U3VzYW4gSGFyZXMgW21haWx0bzpzaGFyZXNAbmR6aC5jb21dDQpTZW50OiBGcmlkYXksIEZlYnJ1 YXJ5IDAxLCAyMDE5IDExOjAzIFBNDQpUbzogRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0BodWF3 ZWkuY29tPjsgJ0JvcmNoZXJ0LCBPbGl2ZXIgKEZlZCknIDxvbGl2ZXIuYm9yY2hlcnQ9NDBuaXN0 LmdvdkBkbWFyYy5pZXRmLm9yZz47IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb207ICdCb3JjaGVy dCwgT2xpdmVyIChGZWQpJyA8b2xpdmVyLmJvcmNoZXJ0QG5pc3QuZ292Pg0KQ2M6IGlkckBpZXRm Lm9yZw0KU3ViamVjdDogUkU6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2Ug U3VwcG9ydA0KDQpKSWUsIEJydW5vIGFuZCBPbGl2ZXI6DQoNClRoYW5rIHlvdSBmb3IgeW91ciBp bnB1dC4gICBZb3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgZXJyb3IgaGFuZGxpbmcgYmVoYXZpb3Ig d2FzIHVuY2xlYXIgYmFzZWQgb24gdGhlIHF1ZXN0aW9ucyBpbiB0aGUgY2hhcnQuICAgVGhlIHB1 cnBvc2Ugb2YgdGhlIGNoYXJ0IGlzIHRvIHByb3ZpZGUgb3RoZXIgQkdQIFdHcyAoQmVzcywgU1BS SU5HLCBMU1ZSKSBhIGNsZWFyIGluZGljYXRpb24gb2YgY2hhbmdlcyB0byB0aGUgYmFzZSBCR1Ag c3BlY2lmaWNhdGlvbi4NCg0KSeKAmXZlIHJlZm9ybWF0dGVkIHNlY3Rpb25zIDQgYW5kIDUgb2Yg dGhlIGNoYXJ0Lg0KDQpUbyBzZWN0aW9uIDQgSeKAmXZlIGFkZGVkOg0KNGMgICAgICAgICAgICBE b2VzIHNlbmQgRXh0ZW5kZWQgTWVzc2FnZSAgLSB3aXRoIGEgeWVzIGZyb20gYWxsIGltcGxlbWVu dGF0aW9ucyAoYmFzZWQgb24gdGhlaXIgZW1haWwpDQoNClNlY3Rpb24gNSwgSeKAmXZlIGFsdGVy IHRvIGJlOg0KNSAgICAgICAgICAgICAgRXJyb3IgaGFuZGluZw0KNWEgICAgICAgICAgIEFjY2Vw dHMgRXh0ZW5kZWQgbWVzc2FnZSB3aXRob3V0IHJlY2VpdmluZw0KICAgICAgICAgICAgIEJHUCBF eHRlbmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgW1NlY3Rpb24gNSBwYXJhZ3JhcGggMSBNQVldDQoN CjViICAgICAgICAgICBJZiByZWNlaXZlcyBFeHRlbmRlZCBNZXNzYWdlIHdpdGhvdXQgQkdQIGV4 dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCwNCiAgICAgICAgICAgICBmb2xsb3dzIFJGQzQyNzEgaGFu ZGxpbmcgYW5kIHNlbmRzIEJhZCBtZXNzYWdlIGxlbmd0aCBOb3RpZmljYXRpb24NCiAgICAgICAg ICAgIFtzZWN0aW9uIDUgcGFyYWdyYXBoIDIgTVVTVF0NCg0KT2xpdmVyIOKAkyBpZiB5b3Ugd291 bGQgcmVhZCB0aGUgY3VycmVudCB0ZXh0IGFuZCBsZXQgbWUga25vdyB0aGUgdXBkYXRlZCBtZXNz YWdlLiAgSSBiZWxpZXZlIHRoZSBhbnN3ZXIgZm9yIGFsbCAzIGltcGxlbWVudGF0aW9ucyBpcyDi gJx5ZXPigJ0gZHVlIHRvIDRiLiAgIFBsZWFzZSBsZXQgbWUga25vdyBhbmQgSSB3aWxsIHVwZGF0 ZSB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIGNoYXJ0Lg0KDQpUbyBmb2xsb3ctdXAgb24gSmll4oCZ cyBjb21tZW50cywgdGhlIHRleHQgZGlkIG5vdCBhY2N1cmF0ZWx5IHJlcHJlc2VudCB0aGUgZXJy b3IgaGFuZGxpbmcuICAgU2VjdGlvbiA1LCBwYXJhZ3JhcGggMSBoYXMgYSDigJxTSE9VTEQgTk9U 4oCdIG1vZGlmaWVkIGJ5IGEg4oCcTUFZ4oCdLCB3aGljaCByZXN1bHRzIGluIHNpbXBseSBhIOKA nE1BWeKAnS4gICBGb3IgcmVhZGFiaWxpdHksIEkgdGhpbmsgdGhlIOKAnFNIT1VMRCBOT1TigJ0g cHJvdmlkZXMgdXNlZnVsIGluZm9ybWF0aW9uICB0byB0aGUgaW1wbGVtZW50ZXIsICBidXQgaXQg Y2Fubm90IGJlIHRlc3RlZCBhY2N1cmF0ZWx5IHdoZW4gY29tYmluZWQgd2l0aCB0aGUg4oCcTUFZ 4oCdLg0KDQpMZXQgbWUgZ2l2ZSB5b3UgYW4gZXhhbXBsZSBvZiB0aGF0Og0KSWYgdGhlIHBlZXIg ZGlkIG5vdCBzZW5kIGEgQkdQIEV4dGVuZGVkIE1lc3NhZ2UgY2FwYWJpbGl0eSwgYW5kIGl0IGFj Y2VwdHMgdGhlIGV4dGVuZGVkIG1lc3NhZ2UgKHdpdGggYSBsZW5ndGggb2YgMTAsMDAwIGJ5dGVz KSwgaXQgY291bGQgaGF2ZSBhIGxpYmVyYWwgcG9saWN5IG9mIE1BWSBhcyBhIGRlZmF1bHQgaW4g dGhlIGltcGxlbWVudGF0aW9uLiAgIFRoZSDigJxvbi13aXJl4oCdIG9ic2VydmF0aW9ucyBjYW5u b3QgdGVsbCDigJMgb25seSB0aGUgaW1wbGVtZW50YXRpb27igJlzIHBvbGljeSAoZGVmYXVsdCAr IGNvbmZpZ3VyZWQpLg0KDQpJIGFsc28gYnJva2Ugb3V0IHRoZSBtYW5hZ2VtZW50IGluZm9ybWF0 aW9uIGF3YXkgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbiBpbmZvcm1hdGlvbi4NCg0KU3VlIEhhcmVz DQoNCkZyb206IERvbmdqaWUgKEppbW15KSBbbWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb21dDQpT ZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMzAsIDIwMTkgODo1MyBQTQ0KVG86IEJvcmNoZXJ0LCBP bGl2ZXIgKEZlZCk7IFN1c2FuIEhhcmVzOyBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0 bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPjsgQm9yY2hlcnQsIE9saXZlciAoRmVkKQ0KQ2M6 IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtJZHJdIFdH IExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydA0KDQpIaSBPbGl2ZXIsIEJydW5v IGFuZCBTdWUsDQoNClRvIG15IHVuZGVyc3RhbmRpbmcsIGJ1bGxldCA1LzVhLzViIGluIHRoZSBp bXBsZW1lbnRhdGlvbiByZXBvcnQgaXMgY29ycmVzcG9uZGluZyB0byB0aGUgc2Vjb25kIHBhcmFn cmFwaCBpbiBzZWN0aW9uIDUg4oCcRXJyb3IgSGFuZGxpbmfigJ06DQoNCkEgQkdQIHNwZWFrZXIg dGhhdCBkb2VzIG5vdCBhZHZlcnRpc2UgdGhlIEJHUCBFeHRlbmRlZCBNZXNzYWdlcw0KICAgY2Fw YWJpbGl0eSBtaWdodCBhbHNvIGdlbnVpbmVseSBub3Qgc3VwcG9ydCBFeHRlbmRlZCBNZXNzYWdl cy4gIFN1Y2gNCiAgIGEgc3BlYWtlciBNVVNUIGZvbGxvdyB0aGUgZXJyb3IgaGFuZGxpbmcgcHJv Y2VkdXJlcyBvZiBbUkZDNDI3MV0gaWYNCiAgIGl0IHJlY2VpdmVzIGFuIEV4dGVuZGVkIE1lc3Nh Z2UuICBTaW1pbGFybHksIGFueSBzcGVha2VyIHRoYXQgdHJlYXRzDQogICBhbiBpbXByb3BlciBF eHRlbmRlZCBNZXNzYWdlIGFzIGEgZmF0YWwgZXJyb3IsIE1VU1QgdHJlYXQgaXQNCiAgIHNpbWls YXJseS4NCg0KVGh1cyBpdCBpcyB0byBkZXNjcmliZSB0aGUgZXJyb3IgaGFuZGxpbmcgYmVoYXZp b3Igb2YgYW4gaW1wbGVtZW50YXRpb24gdmVyc2lvbiB3aGljaCBkb2VzIG5vdCBzdXBwb3J0IGV4 dGVuZGVkIG1lc3NhZ2UuDQoNCldoaWxlIEkgYWdyZWUgdGhpcyBjb3VsZCBiZSBtaXNsZWFkaW5n IGZvciBhIHJlcG9ydCBvZiBpbXBsZW1lbnRhdGlvbiB3aGljaCBzdXBwb3J0cyBleHRlbmRlZCBt ZXNzYWdlIGNhcGFiaWxpdHksIG1heWJlIGl0IGNvdWxkIGJlIHVzZWQgdG8gdmVyaWZ5IHRoZSBi ZWhhdmlvciBvZiBhbiBvbGQgdmVyc2lvbiB3aGljaCBkb2VzIG5vdCBzdXBwb3J0IHRoaXMgY2Fw YWJpbGl0eT8NCg0KQmVzdCByZWdhcmRzLA0KSmllDQoNCkZyb206IElkciBbbWFpbHRvOmlkci1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQm9yY2hlcnQsIE9saXZlciAoRmVkKQ0KU2Vu dDogV2VkbmVzZGF5LCBKYW51YXJ5IDMwLCAyMDE5IDQ6MzUgQU0NClRvOiBTdXNhbiBIYXJlcyA8 c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+PjsgYnJ1bm8uZGVjcmFlbmVA b3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT47IEJvcmNoZXJ0LCBP bGl2ZXIgKEZlZCkgPG9saXZlci5ib3JjaGVydEBuaXN0LmdvdjxtYWlsdG86b2xpdmVyLmJvcmNo ZXJ0QG5pc3QuZ292Pj4NCkNjOiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbSWRyXSBXRyBMYXN0IENhbGwgb24gRXh0ZW5lZCBNZXNzYWdlIFN1cHBvcnQN Cg0KQnJ1bm8gYW5kIFN1c2FuLA0KDQpJIGNhbm5vdCBzcGVhayBmb3IgdGhlIEV4YUJHUCBJbXBs ZW1lbnRhdGlvbiBidXQgZm9yIEJHUFNFQy1JTyBhbmQgUXVhZ2dhU1J4Lg0KSSBiZWxpZXZlIHdo ZW4gSSBjb21waWxlZCB0aGUgcmVwb3J0LCBJIG1pcy1yZWFkIDVhIGFuZCBvdmVybG9va2VkIHRo ZSDigJxub3TigJ0gYW5kIHJlYWQgaW5zdGVhZDog4oCcRG9lcyBzZW5kIEV4dGVuZGVkIE1lc3Nh Z2UgQ2FwYWJpbGl0eeKAnS4NClRoZXJlZm9yZSB0aGUgaW1wbGVtZW50YXRpb24gcmVwb3J0IGZv ciBzZWN0aW9uIDVhIG11c3QgYmUgY29ycmVjdGVkIGZyb20g4oCcWWVz4oCdIGludG8g4oCcTm/i gJ0gZm9yIGJvdGggQkdQU0VDLUlPIGFuZCBRdWFnZ2FTUngNCg0KQkdQU0VDLUlPIGFuZCBRdWFn Z2FTUngsIGJvdGggZG8gc2VuZCB0aGUgZXh0ZW5kZWQgbWVzc2FnZSBjYXBhYmlsaXR5IGlmIHNv IGNvbmZpZ3VyZWQuDQpJIGp1c3QgY2hlY2tlZCB0aGUgY29kZSBhbmQgcnVuIGl0IGFnYWluLiBJ IGNvcHkvcGFzdGVkIHRoZSByZWxldmFudCBvdXRwdXQgZ2VuZXJhdGVkIGJ5IEJHUFNFQy1JTywN Cg0KT2xpdmVyDQoNCi0tLS0tICBvdXRwdXQgb2YgQkdQU0VDLUlPICAtLS0tLS0tDQoNCu+7vy4v Ymdwc2VjaW8gLWYgYmdwc2VjaW8udGVzdC5jZmcucXNyeA0KU3RhcnRpbmcgYmdwc2VjaW8gMC4y LjAuMjUuLi4NClNlbmQ6ICAoT3BlbiBtZXNzYWdlIHNlbmQgZnJvbSBCR1BTRUMtSU8gdG8gUXVh Z2dhU1J4KQ0KT1BFTiBNZXNzYWdlDQogICstLW1hcmtlcjogRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCuKApg0KICAgICArLS1PcHRpb25hbCBQYXJhbWV0ZXI6IENhcGFiaWxpdHkN CiAgICAgfCAgKy0tVHlwZTogQ2FwYWJpbGl0eSAoMikNCiAgICAgfCAgKy0tTGVuZ3RoOiAyDQog ICAgIHwgICstLUNhcGFiaWxpdHk6IEV4dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCBjYXBhYmlsaXR5 DQogICAgIHwgICAgICstLVR5cGU6IEV4dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCBjYXBhYmlsaXR5 ICg2KQ0KICAgICB8ICAgICArLS1MZW5ndGg6IDANCuKApg0KDQpSZWNlaXZlZDogKE9wZW4gbWVz c2FnZSBzZW5kIGZyb20gUXVhZ2dhU1J4IGFuZCByZWNlaXZlZCBieSBCR1BTRUMtSU8pDQpPUEVO IE1lc3NhZ2UNCiAgKy0tbWFya2VyOiBGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRg0K 4oCmDQogICAgICstLU9wdGlvbmFsIFBhcmFtZXRlcjogQ2FwYWJpbGl0eQ0KICAgICAgICArLS1U eXBlOiBDYXBhYmlsaXR5ICgyKQ0KICAgICAgICArLS1MZW5ndGg6IDINCiAgICAgICAgKy0tQ2Fw YWJpbGl0eTogRXh0ZW5kZWQgbWVzc2FnZSBzdXBwb3J0IGNhcGFiaWxpdHkNCiAgICAgICAgICAg Ky0tVHlwZTogRXh0ZW5kZWQgbWVzc2FnZSBzdXBwb3J0IGNhcGFiaWxpdHkgKDYpDQogICAgICAg ICAgICstLUxlbmd0aDogMA0KQkdQLXJlY2VpdmVyIHRocmVhZCBjcmVhdGVkIQ0KDQoNCg0KRnJv bTogSWRyIDxpZHItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc+ PiBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVz QG5kemguY29tPj4NCkRhdGU6IFR1ZXNkYXksIEphbnVhcnkgMjksIDIwMTkgYXQgMTE6NDMgQU0N ClRvOiAiYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3Jh bmdlLmNvbT4iIDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVu ZUBvcmFuZ2UuY29tPj4NCkNjOiAiaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+IiA8 aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZHJdIFdH IExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydA0KDQpCcnVubzoNCg0KVGhhbmsg eW91IGZvciB5b3VyIGNvbW1lbnRzIG9uIHRoaXMgdG9waWMg4oCTIGFzIEkgdGhpbmsNCg0KSSBk aWQgcmVjZWl2ZSByZXBvcnRzIHByaXZhdGVseSB0aGF0IHdlIGhhdmUgMSBmdWxsIGltcGxlbWVu dGF0aW9ucyBvZiBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMgb2ZmIGxpc3Qg d2hpY2ggaXMgbm90IGxpc3RlZCBpbiB0aGlzIHJlcG9ydC4gICBJIGhvcGUgdGhvc2UgaW1wbGVt ZW50ZXJzIHdpbGwgdm9sdW50ZWVyIHRoaXMgaW5mb3JtYXRpb24gb24gdGhlIGxpc3QuICAgSWYg bm90LCBJIHdpbGwgc2hhcmUgdGhpcyBpbmZvcm1hdGlvbiB3aXRoIEFsdmFybyBhbmQgdGhlIElF U0cuDQoNClRoZSBTSURSIHdvcmsgZGlkIGRlZmluZSBkcmFmdC1pZXRmLWJncC1leHRlbmRlZC1t ZXNzYWdlcyBhcyBhIHJlcXVpcmVtZW50IGFuZCBvbmx5IG1vdmVkIHRvIG5vdCBzcGVjaWZ5aW5n IGl0IHdoZW4gd2UgY291bGQgbm90IHF1aWNrbHkgcGFzcyB0aGlzIHRocm91Z2ggV0cgTEMuDQoN ClRoZSByZWFsIG5lZWRzIGFyZSBhIGdyb3dpbmcgQkdQLUxTIHRoYXQgbWF5IHJ1biBvdXQgb2Yg QkdQIG1lc3NhZ2Ugc3BhY2UuICBBcyBteSBwcmV2aW91cyBlbWFpbCB0byBJRFIgaW5kaWNhdGVz LCBJIHdhcyBob3BpbmcgdGhpcyBoYW5kbGVzIGFuIEJHUCBtZXNzYWdlIHdob3NlIGxlbmd0aCBp cyBiaWdnZXIgdGhhbiA0MDk2IGJ5dGVzLiAgIFRoYW5rIHlvdSBmb3IgdGhlIGNvcnJlY3Rpb24g b2Y6DQoNCuKAnFRoZSBpc3N1ZSBpcyBub3Qgc3BlY2lmaWMgdG8gYXR0cmlidXRlcyBiaWdnZXIg dGhhbiA0MDk2IG9jdGV0cywgYnV0IHRvIEJHUCBtZXNzYWdlIHdob3NlIGxlbmd0aCBpcyBiaWdn ZXIgdGhhbiA0MDk2LCBpcnJlc3BlY3RpdmUgb2YgdGhlIHNpemUgb2YgZWFjaCBhdHRyaWJ1dGUu 4oCdDQoNCg0KQXMgdG8geW91ciBjb21tZW50Og0KDQrigJxXaHkgaXMgdGhpcyBsaW1pdGVkIHRv IGZ1dHVyZSBzcGVjaWZpY2F0aW9ucz8gQSBwcmlvcmksIHVzaW5nIGV4aXN0aW5nIEJHUCBtZWNo YW5pc20gKEFGSS9TQUZJLCBhdHRyaWJ1dGVzLCAqIGNvbW11bml0aWVzKSBvbmUgY291bGQgZXhj ZWVkIHRoZSBzaXplIG9mIDQwOTYgb2N0ZXRzLiBIb3cgZG9lcyB0aGUgQkdQIHNwZWFrZXIgc3Vw cG9zZWQgdG8gYmVoYXZlIGluIHRoaXMgY2FzZT8gVGhpcyBzaG91bGQgYmUgZGVzY3JpYmVkIGlu IHRoaXMgc3BlY2lmaWNhdGlvbi4gTm90ZSB0aGF0IHRoaXMgaXMgbm90IGEgY2FzZSBvZiBlcnJv ciBoYW5kbGluZywgYXMgZXZlcnkgQkdQIHNwZWFrZXIgaXMgYmVoYXZpbmcgYXMgc3BlY2lmaWVk LuKAnQ0KDQpUaGlzIHByb2JsZW0gaGFzIGJlZW4gdHJ1ZSBmb3IgeWVhcnMsIGFuZCB0aHVzIGFz IGNvLWNoYWlycyBoYWQgaG9wZWQgdG8gaGF2ZSB0aGUgZHJhZnQtaWV0Zi1iZ3AtZXh0ZW5kZWQt bWVzc2FnZXMgcGFzc2VkIHllYXJzIGFnby4gICBBcyBCR1AtTFMgYXR0cmlidXRlcyBncm93IHVz ZSBhbmQgaW4gbnVtYmVyLCB0aGUgcG90ZW50aWFsIG9mIGV4Y2VlZGluZyB0aGUgQkdQIG1lc3Nh Z2UgbGltaXQgaW5jcmVhc2VzLiAgSXQgc2VlbXMgbGlrZSBhIGdvb2QgZGlyZWN0aW9uIHRvIHBy ZXZlbnQgaXNzdWVzLg0KDQpJIGhvcGUgdGhlIGF1dGhvcnMgd2lsbCBjb21tZW50IG9uIHRoZSBj aGFuZ2VzIHlvdSBzdWdnZXN0ZWQgdG8gdGhlIHRleHQuDQoNCkNoZWVycywNClN1c2FuIEhhcmVz DQoNCg0KDQpGcm9tOiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNy YWVuZUBvcmFuZ2UuY29tPiBbbWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb21dDQpTZW50 OiBUdWVzZGF5LCBKYW51YXJ5IDI5LCAyMDE5IDg6MzMgQU0NClRvOiBTdXNhbiBIYXJlcw0KQ2M6 IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtJZHJdIFdH IExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydA0KDQpIaSBXRywNCg0KUGxlYXNl IGZpbmQgYmVsb3cgc29tZSBjb21tZW50cy4NCkFzIG9mIHRvZGF5LCBJIGRvbuKAmXQgYmVsaWV2 ZSB0aGlzIHNwZWNpZmljYXRpb24gaXMgcmVhZHkgdG8gYmUgcHJvZ3Jlc3NlZCB0byBJRVNHL1JG QywgZXNwZWNpYWxseSBmb3IgYSBkb2N1bWVudCB1cGRhdGluZyBSRkMgNDI3MSAoY29yZSBCR1Ag c3BlYykuDQoNCj4gVGhlIFdHIGNoYWlycyBpbnRlbmQgdG8gZm9yd2FyZCB0aGlzIGRyYWZ0IHRv IHRoZSBJRVNHIHdpdGggdGhlIGN1cnJlbnQgbGV2ZWwgb2YgaW1wbGVtZW50YXRpb24uDQoNCmh0 dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncC1leHRl bmRlZC1pbXBsZW1lbnRhdGlvbnM8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0cmFjLmlldGYub3JnJTJGdHJhYyUyRmlkciUy Rndpa2klMkZkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtaW1wbGVtZW50YXRpb25zJmRhdGE9 MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDNDBiYjhhOTQzZTYxNGIxNjM3 ZjMwOGQ2ODYwOGQ2Y2QlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0Mw JTdDNjM2ODQzNzY5ODU5MTY1MDQzJnNkYXRhPWhYQmJPWHF3dlhxdENWJTJCOVBiUCUyRjdJRTZX SmpXVUEyYm9NMzNLZHMlMkJnaDQlM0QmcmVzZXJ2ZWQ9MD4gc2F5cyA6IDVhDQoNCkRvZXMgbm90 IHNlbmQgRXh0ZW5kZWQgTWVzc2FnZSBjYXBhYmlsaXR5DQoNClllcw0KDQpZZXMNCg0KWWVzDQoN Cg0KSSBtYXkgYmUgbWlzdW5kZXJzdGFuZGluZyB0aGUgaW1wbGVtZW50YXRpb24gcmVwb3J0LCBi dXQgbXkgcmVhZGluZyBvZiB0aGUgYWJvdmUgaXMgdGhhdCBub25lIG9mIHRoZSByZXBvcnRlZCBp bXBsZW1lbnRhdGlvbnMgc2VuZHMgdGhlIGNhcGFiaWxpdHkgaGVuY2Ugbm8gaW1wbGVtZW50YXRp b24gc3VwcG9ydHMgZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLi4gSGVyZSB0 aGlzIGRvY3VtZW50IGlzIHVwZGF0aW5nIFJGQyA0MjcxLCBzbyBpdCBpcyBub3QgYSBtaW5vciBl eHRlbnNpb24gZm9yIGEgbmljaGUgdXNlIGNhc2UuIFNvIEkgZG9u4oCZdCBzZWUgdGhlIGFyZ3Vt ZW50cyBmb3Igbm90IHJlcXVpcmluZyB0aGUgSURS4oCZcyB1c3VhbCB0d28gaW50ZXJvcGVyYWJs ZSBpbXBsZW1lbnRhdGlvbnMuDQoNCi0tLS0NCsKnIDENCuKAnCBBcyBCR1AgaXMgZXh0ZW5kZWQg dG8gc3VwcG9ydCBuZXdlciBBRkkvU0FGSXMgYW5kDQogICBuZXdlciBjYXBhYmlsaXRpZXMgKGUu Zy4sIFtJLUQuaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbDxodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3Jn JTJGaHRtbCUyRmRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0yNyUyM3JlZi1J LUQuaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbCZkYXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hl cnQlNDBuaXN0LmdvdiU3QzQwYmI4YTk0M2U2MTRiMTYzN2YzMDhkNjg2MDhkNmNkJTdDMmFiNWQ4 MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjg0Mzc2OTg1OTE2NTA0MyZz ZGF0YT11WlMlMkJiTjl2NWNpcjJvNUwzVTNqUDJ4RlBiWTRUeiUyRk5uQlBmZEg3aURmMCUzRCZy ZXNlcnZlZD0wPl0pLCB0aGVyZSBpcw0KICAgYSBuZWVkIHRvIGV4dGVuZCB0aGUgbWF4aW11bSBt ZXNzYWdlIHNpemUgYmV5b25kIDQwOTYgb2N0ZXRzLiAg4oCcDQoNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMjcjc2VjdGlv bi0xPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1pZHItYmdwLWV4 dGVuZGVkLW1lc3NhZ2VzLTI3JTIzc2VjdGlvbi0xJmRhdGE9MDIlN0MwMSU3Q29saXZlci5ib3Jj aGVydCU0MG5pc3QuZ292JTdDNDBiYjhhOTQzZTYxNGIxNjM3ZjMwOGQ2ODYwOGQ2Y2QlN0MyYWI1 ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2ODQzNzY5ODU5MTY1MDQz JnNkYXRhPVlWV0hBRmJZUmpHJTJGbFdQYnB3MnJXOHVHUTZRWHNzM2R1Zm0lMkZxSGdSdkR3JTNE JnJlc2VydmVkPTA+DQoNCg0KW0ktRC5pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sPGh0dHBzOi8v bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG dG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3Nh Z2VzLTI3JTIzcmVmLUktRC5pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sJmRhdGE9MDIlN0MwMSU3 Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDNDBiYjhhOTQzZTYxNGIxNjM3ZjMwOGQ2ODYw OGQ2Y2QlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2ODQz NzY5ODU5MTY1MDQzJnNkYXRhPXVaUyUyQmJOOXY1Y2lyMm81TDNVM2pQMnhGUGJZNFR6JTJGTm5C UGZkSDdpRGYwJTNEJnJlc2VydmVkPTA+IGlzIG5vdyBSRkMgODIwNSAodGhhbmtzIGZvciB1cGRh dGluZyB0aGUgcmVmZXJlbmNlKS4gSXQgaGFzIHJlbW92ZWQgdGhlIG5vcm1hdGl2ZS9hbnkgcmVm ZXJlbmNlIHRvIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy4gU28gcHJlc3Vt YWJseSBCR1AgU2VjIGRvZXMgbm90IG5lZWQgZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1l c3NhZ2VzLg0KQ2FuIHdlIGhhdmUgYW4gdXBkYXRlIG9uIHRoaXM/DQpDYW4gdGhlIGludHJvZHVj dGlvbiBvZiBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMgYmUgdXBkYXRlZCB0 byBpbnRyb2R1Y2Ugb24gdGhlIHJlYWwgcmVhc29ucy9uZWVkcz8NCg0KLS0tLQ0Kwqc0DQoNCsKn MyBzYXlzIOKAnEEgcGVlciB3aGljaCBkb2VzIG5vdCBhZHZlcnRpc2UgdGhpcyBjYXBhYmlsaXR5 IE1VU1QgTk9UIHNlbmQgQkdQDQogICBFeHRlbmRlZCBNZXNzYWdlcywgYW5kIEJHUCBFeHRlbmRl ZCBNZXNzYWdlcyBNVVNUIE5PVCBiZSBzZW50IHRvIGl0LuKAnQ0KDQpGaW5lLiBUZXh0IGluIMKn NCBzaG91bGQgcHJvYmFibHkgYmUgYWxpZ25lZCB3aXRoIHRoZSBhYm92ZSAuLmUuZy4NCg0KT0xE OiBBIEJHUCBzcGVha2VyDQogICBNQVkgc2VuZCBFeHRlbmRlZCBNZXNzYWdlcyB0byBpdHMgcGVl ciBvbmx5IGlmIGl0IGhhcyByZWNlaXZlZCB0aGUNCiAgIEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJp bGl0eSBmcm9tIHRoYXQgcGVlci4NCg0KTkVXOg0KQSBCR1Agc3BlYWtlcg0KICAgTUFZIHNlbmQg RXh0ZW5kZWQgTWVzc2FnZXMgdG8gaXRzIHBlZXIgb25seSBpZiBpdCBoYXMgc2VudCBhbmQgcmVj ZWl2ZWQgdGhlDQogICBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgdG8gYW5kIGZyb20gdGhh dCBwZWVyLg0KDQotLS0tDQoNCuKAnCAgIEFwcGxpY2F0aW9ucyBnZW5lcmF0aW5nIGluZm9ybWF0 aW9uIHdoaWNoIG1pZ2h0IGJlIGVuY2Fwc3VsYXRlZA0KICAgd2l0aGluIEJHUCBtZXNzYWdlcyBN VVNUIGxpbWl0IHRoZSBzaXplIG9mIHRoZWlyIHBheWxvYWQgdG8gdGFrZSB0aGUNCiAgIG1heGlt dW0gbWVzc2FnZSBzaXplIGludG8gYWNjb3VudC7igJ0NCg0KSSBkb27igJl0IHNlZSB3aGF0IG5l dyBiZWhhdmlvciBpcyBiZWVuIGRlZmluZWQgaGVyZS4gSWYgdGhlcmUgaXMgbm9uZSwgSSB3b3Vs ZCBzdWdnZXN0IHRvIHJlbW92ZSB0aGlzIHNlbnRlbmNlDQoNCi0tLS0NCiAgIEEgQkdQIGFubm91 bmNlbWVudCB3aWxsLCBpbiB0aGUgbm9ybWFsIGNhc2UsIHByb3BhZ2F0ZSB0aHJvdWdob3V0IHRo ZQ0KICAgQkdQIHNwZWFraW5nIEludGVybmV0OyBhbmQgdGhlcmUgd2lsbCB1bmRvdWJ0ZWRseSBi ZSBCR1Agc3BlYWtlcnMNCiAgIHdoaWNoIGRvIG5vdCBoYXZlIHRoZSBFeHRlbmRlZCBNZXNzYWdl IGNhcGFiaWxpdHkuICBUaGVyZWZvcmUsDQogICBwdXR0aW5nIGFuIGF0dHJpYnV0ZSB3aGljaCBj YW4gbm90IGJlIGRlY29tcG9zZWQgdG8gNDA5NiBvY3RldHMgb3INCiAgIGxlc3MgaW4gYW4gRXh0 ZW5kZWQgTWVzc2FnZSBpcyBhIGxpa2VseSBwYXRoIHRvIHJvdXRpbmcgZmFpbHVyZS4NCg0KDQpU aGUgaXNzdWUgaXMgbm90IHNwZWNpZmljIHRvIGF0dHJpYnV0ZXMgYmlnZ2VyIHRoYW4gNDA5NiBv Y3RldHMsIGJ1dCB0byBCR1AgbWVzc2FnZSB3aG9zZSBsZW5ndGggaXMgYmlnZ2VyIHRoYW4gNDA5 NiwgaXJyZXNwZWN0aXZlIG9mIHRoZSBzaXplIG9mIGVhY2ggYXR0cmlidXRlLg0KUGxlYXNlIGVs YWJvcmF0ZSBvbiB3aGF0IHlvdSBtZWFuIGJ5IOKAnGFuIGF0dHJpYnV0ZSB3aGljaCBjYW4gbm90 IGJlIGRlY29tcG9zZWQgdG8gNDA5NiBvY3RldHPigJ0NCg0KLS0tDQrigJwgICBJdCBpcyBSRUNP TU1FTkRFRCB0aGF0IEJHUCBwcm90b2NvbCBkZXZlbG9wZXJzIGFuZCBpbXBsZW1lbnRlcnMgYXJl DQogICBjb25zZXJ2YXRpdmUgaW4gdGhlaXIgYXBwbGljYXRpb24gYW5kIHVzZSBvZiBFeHRlbmRl ZCBNZXNzYWdlcy7igJ0NCg0KV2hhdCBkb2VzIHRoaXMgbWVhbiBleGFjdGx5PyBUaGF0IHRoZXkg ZG9u4oCZdCB1c2UgdGhpcyBleHRlbnNpb24/IFRoYXQgdGhleSBkb27igJl0IHVzZSB0aGlzIGV4 dGVuc2lvbiB1bmxlc3MgWFhfVE8gQkUgU1BFQ0lGSUVEX1hYPw0KDQotLS0NCiAgRnV0dXJlIHBy b3RvY29sIHNwZWNpZmljYXRpb25zIHdpbGwgbmVlZCB0byBkZXNjcmliZSBob3cgdG8gaGFuZGxl DQogICBwZWVycyB3aGljaCBjYW4gb25seSBhY2NvbW1vZGF0ZSA0MDk2IG9jdGV0IG1lc3NhZ2Vz Lg0KDQpXaHkgaXMgdGhpcyBsaW1pdGVkIHRvIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucz8gQSBwcmlv cmksIHVzaW5nIGV4aXN0aW5nIEJHUCBtZWNoYW5pc20gKEFGSS9TQUZJLCBhdHRyaWJ1dGVzLCAq IGNvbW11bml0aWVzKSBvbmUgY291bGQgZXhjZWVkIHRoZSBzaXplIG9mIDQwOTYgb2N0ZXRzLiBI b3cgZG9lcyB0aGUgQkdQIHNwZWFrZXIgc3VwcG9zZWQgdG8gYmVoYXZlIGluIHRoaXMgY2FzZT8g VGhpcyBzaG91bGQgYmUgZGVzY3JpYmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4gTm90ZSB0aGF0 IHRoaXMgaXMgbm90IGEgY2FzZSBvZiBlcnJvciBoYW5kbGluZywgYXMgZXZlcnkgQkdQIHNwZWFr ZXIgaXMgYmVoYXZpbmcgYXMgc3BlY2lmaWVkLg0KDQoNCi0tLS0NCkRlcGVuZGluZyBvbiB0aGUg YWJvdmUgc3BlY2lmaWNhdGlvbiwgYSBzZWN0aW9uIGRlc2NyaWJpbmcgdGhlIG9wZXJhdGlvbmFs IGNvbnNlcXVlbmNlcyBpbiBhIG5ldHdvcmsgKHN1Y2ggYXMgdGhlIEludGVybmV0LCBCR1AgRW5h YmxlZCBTZXJ2aWNlUy9WUE4gbmV0d29ya3MpIGlzIHByb2JhYmx5IG5lZWRlZC4gUG9zc2libGUg Y29uc2VxdWVuY2VzIGNvdWxkIGJlIEJHUCBOTFJJIGJlaW5nIHJlbW92ZWQgaW4gdGhlIG1pZGRs ZSBvZiBzdWNoIG5ldHdvcmssIG9yIChleHRlbmRlZCkgY29tbXVuaXR5IChzdWNoIGFzIFJvdXRl IFRhcmdldHMpIGJlZW4gcmVtb3ZlZC4gQm90aCBoYXZpbmcgc2lnbmlmaWNhbnQgY29uc2VxdWVu Y2VzIG9uIHRoZSBhdmFpbGFiaWxpdHkgcHJvdmlkZWQgYnkgdGhlIG5ldHdvcmsuDQoNCi0tLQ0K wqc0DQpPTEQ6IFRoZSBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgb25seSBhcHBsaWVzIHRv IGFsbCBtZXNzYWdlcyBleGNlcHQgZm9yIHRoZSBPUEVOIG1lc3NhZ2UuDQpQcm9iYWJseQ0KTkVX OiBUaGUgRXh0ZW5kZWQgTWVzc2FnZSBDYXBhYmlsaXR5IGFwcGxpZXMgdG8gYWxsIG1lc3NhZ2Ug dHlwZXMgZXhjZXB0IGZvciB0aGUgT1BFTiBtZXNzYWdlICh0eXBlIDEpLg0KLS0tLQ0Kwqc4DQoN CuKAnFRoaXMgZXh0ZW5zaW9uIHRvIEJHUCBkb2VzIG5vdCBjaGFuZ2UgQkdQJ3MgdW5kZXJseWlu ZyBzZWN1cml0eSBpc3N1ZXMgwrsNCg0KQmVmb3JlIGV2YWx1YXRpbmcgdGhpcywgSSB0aGluayB0 aGlzIGRvY3VtZW50IHNob3VsZCBmaXJzdCBzcGVjaWZpZWQgaG93IGEgQkdQIG1lc3NhZ2VzIGJp Z2dlciB0aGFuIDQwOTYgb2N0ZXRzIGlzIGhhbmRsZWQgd2hlbiBpdCBuZWVkcyB0byBiZSBzZW50 IHRvIGEgcmVjZWl2ZWQgbm90IHN1cHBvcnRpbmcgdGhpcyBleHRlbnNpb24uDQoNCk5pdHM6DQpP TEQgOiB0byByZWR1Y2UgY29tcGV4aXR5DQpORVcgOiB0byByZWR1Y2UgY29tcGxleGl0eQ0KDQpU aGFua3MsDQotLUJydW5vDQoNCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgU3VzYW4gSGFyZXMNClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjksIDIw MTkgMTI6MzMgUE0NClRvOiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4NClN1Ympl Y3Q6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydA0KDQoNClRo aXMgYmVnaW5zIGEgMiB3ZWVrIFdHIExDIG9uIEV4dGVuZGVkIE1lc3NhZ2UgU3VwcG9ydCBmb3Ig QkdQIChkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMjcpLiAgWW91IGNhbiBh Y2Nlc3MgdGhlIGRyYWZ0IGF0Og0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMvPGh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIu aWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMlMkYm ZGF0YT0wMiU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJiOGE5NDNlNjE0 YjE2MzdmMzA4ZDY4NjA4ZDZjZCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdD MSU3QzAlN0M2MzY4NDM3Njk4NTkzMjEyODkmc2RhdGE9b2tqVGVMZTZEY1RhUlYyVVN5Mk15NkhY RFJ5bnVwbVhsQjBpN2dVd3luQSUzRCZyZXNlcnZlZD0wPg0KDQpUaGUgYXV0aG9ycyBzaG91bGQg aW5kaWNhdGUgd2hldGhlciB0aGV5IGtub3cgb2YgYW55IElQUi4gICBJbXBsZW1lbnRlcnMgYXJl IGVuY291cmFnZWQgdG8gdXBkYXRlIHRoZSAgaW1wbGVtZW50YXRpb24gZGF0YSBhdDoNCg0KaHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVu ZGVkLWltcGxlbWVudGF0aW9uczxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRyYWMuaWV0Zi5vcmclMkZ0cmFjJTJGaWRyJTJG d2lraSUyRmRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRhdGlvbnMmZGF0YT0w MiU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJiOGE5NDNlNjE0YjE2Mzdm MzA4ZDY4NjA4ZDZjZCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAl N0M2MzY4NDM3Njk4NTkzMjEyODkmc2RhdGE9UG9SeUZvZnMwNCUyRkMlMkYlMkZnYlhMMnp5RUQz U1c2TXJFU3BIaUlFMmU3cDRjQSUzRCZyZXNlcnZlZD0wPg0KDQpUaGUgZHJhZnQgcHJvdmlkZXMg YSBtZWFucyBmb3IgZXhwYW5kaW5nIHRoZSBCR1AgbWVzc2FnZSB0byA2NTUzNSBvY3RldHMgZm9y IGFsbCBtZXNzYWdlcyBleGNlcHQgT1BFTiBtZXNzYWdlcy4gIEJHUCBtZXNzYWdlIHNwYWNlIGlz IHJ1bm5pbmcgc2hvcnQgZm9yIGFsbCBvZiB0aGUgcG90ZW50aWFsIGF0dHJpYnV0ZXMgb3IgYWRk aXRpb25zIHByb3Bvc2VkIGJ5IEJHUC1MUyBmZWF0dXJlcy4NCg0KVGhlIFdHIGNoYWlycyBpbnRl bmQgdG8gZm9yd2FyZCB0aGlzIGRyYWZ0IHRvIHRoZSBJRVNHIHdpdGggdGhlIGN1cnJlbnQgbGV2 ZWwgb2YgaW1wbGVtZW50YXRpb24uDQoNCkFzIHlvdSBjb21tZW50IG9uIHRoZSBkcmFmdCwgcGxl YXNlIGNvbnNpZGVyIGlmOiBhKSB0aGUgdGVjaG5vbG9neSBpcyBtYXR1cmUsIGIpIHRoZSBhZGRp dGlvbmFsIHNwYWNlIGluIGEgQkdQIG1lc3NhZ2Ugd291bGQgYmUgaGVscGZ1bCBmb3IgdGhvc2Ug ZGVwbG95aW5nIEJHUC1MUyBvciBTUiwgYW5kIGMpIGlmIHRoZSBzcGVjaWZpY2F0aW9uIGlzIHJl YWR5IGZvciBwdWJsaWNhdGlvbi4NCg0KU3VlIEhhcmVzIChXRyBDaGFpciwgU2hlcGhlcmQpDQoN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4N Cg== --_000_76CD132C3ADEF848BD84D028D243C927C32AEB75NKGEML515MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1i b3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp Zjt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE 6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwg bGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFs Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QcmZvcm1hdEhU TUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJ Zm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KcC5QcmZvcm1hdEhUTUwsIGxpLlByZm9ybWF0SFRNTCwg ZGl2LlByZm9ybWF0SFRNTA0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwiOw0K CW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJl Zm9ybWF0dGVkLCBkaXYuSFRNTFByZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ cmVmb3JtYXR0ZWQiOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUy OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgt Q04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SGkgU3VlLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdXBkYXRpbmcgdGhl IGltcGxlbWVudGF0aW9uIHJlcG9ydC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NeSB1bmRlcnN0YW5kaW5nIHdh cyB0aGF0IGJ1bGxldCA0IHdhcyB0byBjb3ZlciB0aGUgYmVoYXZpb3Igb2Ygc2VjdGlvbiA1IHBh cmFncmFwaCAxLCBidWxsZXQgNSB3YXMgdG8gY292ZXIgdGhlIGJlaGF2aW9yIG9mIHNlY3Rpb24g NSBwYXJhZ3JhcGgNCiAyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdXQgYWZ0ZXIgcmVyZWFkaW5nIHNlY3Rpb24g NSwgSSByZWFsaXplIHRoYXQgYm90aCBwYXJhZ3JhcGggMSBhbmQgMiBhcmUgdGFsa2luZyBhYm91 dCB0aGUgYmVoYXZpb3Igb2YgYSBCR1Agc3BlYWtlciB3aGljaCBkb2VzIG5vdCBhZHZlcnRpc2Ug dGhlDQogZXh0ZW5kZWQgbWVzc2FnZSBjYXBhYmlsaXR5IHRvIGl0cyBwZWVyLCBzbyBwZXJoYXBz IGJ1bGxldHMgNCBhbmQgNSBpbiB0aGUgaW1wbGVtZW50YXRpb24gcmVwb3J0IGNvdWxkIGJlIG1l cmdlZCBhcyBiZWxvdzoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj40LiBXaGVuIHJlY2VpdmVzIGFuIGV4dGVuZGVk IG1lc3NhZ2Ugd2l0aG91dCBhZHZlcnRpc2luZyB0aGUgQkdQIEV4dGVuZGVkIE1lc3NhZ2UgQ2Fw YWJpbGl0eSB0byB0aGlzIHBlZXIgKEVycm9yIEhhbmRsaW5nKS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjRhLiBBY2NlcHRzIHRoZSBleHRlbmRlZCBtZXNzYWdlIGlmIHRoZSBCR1Ag c3BlYWtlciBpcyBhYmxlIHRvIHByb2Nlc3MgZXh0ZW5kZWQgbWVzc2FnZSAoYnV0IHdhcyBjb25m aWd1cmVkIG5vdCB0byBhZHZlcnRpc2UgdGhlIGNhcGFiaWxpdHkpICZuYnNwOyZuYnNwO1tTZWN0 aW9uDQogNSwgcGFyYWdyYXBoIDEgTUFZXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ NGIuIERvZXMgbm90IGFjY2VwdCB0aGUgZXh0ZW5kZWQgbWVzc2FnZSwgZm9sbG93cyBSRkM0Mjcx IGhhbmRsaW5nIGFuZCBzZW5kcyBCYWQgTWVzc2FnZSBMZW5ndGggTm90aWZpY2F0aW9uIFtTZWN0 aW9uIDUsIHBhcmFncmFwaCAxIFNIT1VMRCBOT1QsDQogYW5kIHBhcmFncmFwaCAyIE1VU1QpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkhvcGUgdGhpcyBoZWxwcyB0byByZWR1Y2UgdGhlIGNvbmZ1c2lvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SmllPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBTdXNhbiBIYXJlcyBbbWFpbHRvOnNoYXJlc0Bu ZHpoLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDAxLCAyMDE5IDEx OjAzIFBNPGJyPg0KPGI+VG86PC9iPiBEb25namllIChKaW1teSkgJmx0O2ppZS5kb25nQGh1YXdl aS5jb20mZ3Q7OyAnQm9yY2hlcnQsIE9saXZlciAoRmVkKScgJmx0O29saXZlci5ib3JjaGVydD00 MG5pc3QuZ292QGRtYXJjLmlldGYub3JnJmd0OzsgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTsg J0JvcmNoZXJ0LCBPbGl2ZXIgKEZlZCknICZsdDtvbGl2ZXIuYm9yY2hlcnRAbmlzdC5nb3YmZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBpZHJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtJ ZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KSWUsIEJydW5v IGFuZCBPbGl2ZXI6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91IGZvciB5b3VyIGlucHV0LiZuYnNw OyZuYnNwOyBZb3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgZXJyb3IgaGFuZGxpbmcgYmVoYXZpb3Ig d2FzIHVuY2xlYXIgYmFzZWQgb24gdGhlIHF1ZXN0aW9ucyBpbiB0aGUgY2hhcnQuICZuYnNwOyZu YnNwO1RoZSBwdXJwb3NlIG9mIHRoZQ0KIGNoYXJ0IGlzIHRvIHByb3ZpZGUgb3RoZXIgQkdQIFdH cyAoQmVzcywgU1BSSU5HLCBMU1ZSKSBhIGNsZWFyIGluZGljYXRpb24gb2YgY2hhbmdlcyB0byB0 aGUgYmFzZSBCR1Agc3BlY2lmaWNhdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J4oCZdmUgcmVmb3JtYXR0 ZWQgc2VjdGlvbnMgNCBhbmQgNSBvZiB0aGUgY2hhcnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG8g c2VjdGlvbiA0IEnigJl2ZSBhZGRlZDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ NGMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgRG9lcyBzZW5kIEV4dGVuZGVkIE1lc3NhZ2UgJm5ic3A7LSB3aXRoIGEgeWVz IGZyb20gYWxsIGltcGxlbWVudGF0aW9ucyAoYmFzZWQgb24gdGhlaXIgZW1haWwpDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+U2VjdGlvbiA1LCBJ4oCZdmUgYWx0ZXIgdG8gYmU6DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXJyb3IgaGFuZGluZyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj41YSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBY2NlcHRzIEV4dGVuZGVkIG1l c3NhZ2Ugd2l0aG91dCByZWNlaXZpbmcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QkdQIEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eSBbU2Vj dGlvbiA1IHBhcmFncmFwaCAxIE1BWV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj41YiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiByZWNlaXZlcyBFeHRlbmRlZCBN ZXNzYWdlIHdpdGhvdXQgQkdQIGV4dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtmb2xsb3dzIFJGQzQyNzEgaGFuZGxp bmcgYW5kIHNlbmRzIEJhZCBtZXNzYWdlIGxlbmd0aCBOb3RpZmljYXRpb24NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7W3NlY3Rpb24gNSBwYXJhZ3JhcGgg MiBNVVNUXQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9saXZlciDigJMgaWYgeW91IHdvdWxkIHJlYWQgdGhlIGN1 cnJlbnQgdGV4dCBhbmQgbGV0IG1lIGtub3cgdGhlIHVwZGF0ZWQgbWVzc2FnZS4gJm5ic3A7SSBi ZWxpZXZlIHRoZSBhbnN3ZXIgZm9yIGFsbCAzIGltcGxlbWVudGF0aW9ucyBpcyDigJx5ZXPigJ0g ZHVlIHRvDQogNGIuJm5ic3A7Jm5ic3A7IFBsZWFzZSBsZXQgbWUga25vdyBhbmQgSSB3aWxsIHVw ZGF0ZSB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIGNoYXJ0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG8gZm9sbG93 LXVwIG9uIEppZeKAmXMgY29tbWVudHMsIHRoZSB0ZXh0IGRpZCBub3QgYWNjdXJhdGVseSByZXBy ZXNlbnQgdGhlIGVycm9yIGhhbmRsaW5nLiZuYnNwOyAmbmJzcDtTZWN0aW9uIDUsIHBhcmFncmFw aCAxIGhhcyBhIOKAnFNIT1VMRCBOT1TigJ0gbW9kaWZpZWQgYnkNCiBhIOKAnE1BWeKAnSwgd2hp Y2ggcmVzdWx0cyBpbiBzaW1wbHkgYSDigJxNQVnigJ0uJm5ic3A7ICZuYnNwO0ZvciByZWFkYWJp bGl0eSwgSSB0aGluayB0aGUg4oCcU0hPVUxEIE5PVOKAnSBwcm92aWRlcyB1c2VmdWwgaW5mb3Jt YXRpb24mbmJzcDsgdG8gdGhlIGltcGxlbWVudGVyLCAmbmJzcDtidXQgaXQgY2Fubm90IGJlIHRl c3RlZCBhY2N1cmF0ZWx5IHdoZW4gY29tYmluZWQgd2l0aCB0aGUg4oCcTUFZ4oCdLiZuYnNwOyAm bmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TGV0IG1lIGdpdmUgeW91IGFuIGV4YW1wbGUgb2YgdGhh dDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPklmIHRoZSBwZWVyIGRpZCBub3Qgc2VuZCBhIEJHUCBFeHRlbmRlZCBNZXNzYWdlIGNhcGFi aWxpdHksIGFuZCBpdCBhY2NlcHRzIHRoZSBleHRlbmRlZCBtZXNzYWdlICh3aXRoIGEgbGVuZ3Ro IG9mIDEwLDAwMA0KIGJ5dGVzKSwgaXQgY291bGQgaGF2ZSBhIGxpYmVyYWwgcG9saWN5IG9mIE1B WSBhcyBhIGRlZmF1bHQgaW4gdGhlIGltcGxlbWVudGF0aW9uLiAmbmJzcDsmbmJzcDtUaGUg4oCc b24td2lyZeKAnSBvYnNlcnZhdGlvbnMgY2Fubm90IHRlbGwg4oCTIG9ubHkgdGhlIGltcGxlbWVu dGF0aW9u4oCZcyBwb2xpY3kgKGRlZmF1bHQgJiM0MzsgY29uZmlndXJlZCkuJm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbHNvIGJyb2tlIG91dCB0aGUgbWFuYWdlbWVudCBpbmZv cm1hdGlvbiBhd2F5IGZyb20gdGhlIHNwZWNpZmljYXRpb24gaW5mb3JtYXRpb24uJm5ic3A7DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+U3VlIEhhcmVzICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IERvbmdq aWUgKEppbW15KSBbPGEgaHJlZj0ibWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb20iPm1haWx0bzpq aWUuZG9uZ0BodWF3ZWkuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEph bnVhcnkgMzAsIDIwMTkgODo1MyBQTTxicj4NCjxiPlRvOjwvYj4gQm9yY2hlcnQsIE9saXZlciAo RmVkKTsgU3VzYW4gSGFyZXM7IDxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2Uu Y29tIj4NCmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+OyBCb3JjaGVydCwgT2xpdmVyIChG ZWQpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbSWRyXSBXRyBMYXN0IENhbGwgb24g RXh0ZW5lZCBNZXNzYWdlIFN1cHBvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgT2xpdmVyLCBCcnVubyBhbmQgU3VlLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UbyBteSB1bmRlcnN0YW5kaW5nLCBidWxsZXQgNS81YS81YiBpbiB0aGUgaW1wbGVt ZW50YXRpb24gcmVwb3J0IGlzIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHNlY29uZCBwYXJhZ3JhcGgg aW4gc2VjdGlvbiA1IOKAnEVycm9yIEhhbmRsaW5n4oCdOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtaW5kZW50OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5BIEJHUCBzcGVha2VyIHRoYXQgZG9lcyBub3QgYWR2ZXJ0aXNlIHRo ZSBCR1AgRXh0ZW5kZWQgTWVzc2FnZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyBjYXBhYmlsaXR5IG1pZ2h0IGFsc28gZ2VudWluZWx5IG5vdCBzdXBwb3J0IEV4 dGVuZGVkIE1lc3NhZ2VzLiZuYnNwOyBTdWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgYSBzcGVha2VyIE1VU1QgZm9sbG93IHRoZSBlcnJvciBoYW5kbGluZyBw cm9jZWR1cmVzIG9mIFtSRkM0MjcxXSBpZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7IGl0IHJlY2VpdmVzIGFuIEV4dGVuZGVkIE1lc3NhZ2UuJm5ic3A7IFNpbWls YXJseSwgYW55IHNwZWFrZXIgdGhhdCB0cmVhdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyBhbiBpbXByb3BlciBFeHRlbmRlZCBNZXNzYWdlIGFzIGEgZmF0YWwg ZXJyb3IsIE1VU1QgdHJlYXQgaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyBzaW1pbGFybHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRodXMgaXQgaXMgdG8gZGVzY3JpYmUgdGhl IGVycm9yIGhhbmRsaW5nIGJlaGF2aW9yIG9mIGFuIGltcGxlbWVudGF0aW9uIHZlcnNpb24gd2hp Y2ggZG9lcyBub3Qgc3VwcG9ydCBleHRlbmRlZCBtZXNzYWdlLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoaWxl IEkgYWdyZWUgdGhpcyBjb3VsZCBiZSBtaXNsZWFkaW5nIGZvciBhIHJlcG9ydCBvZiBpbXBsZW1l bnRhdGlvbiB3aGljaCBzdXBwb3J0cyBleHRlbmRlZCBtZXNzYWdlIGNhcGFiaWxpdHksIG1heWJl IGl0IGNvdWxkIGJlIHVzZWQgdG8gdmVyaWZ5DQogdGhlIGJlaGF2aW9yIG9mIGFuIG9sZCB2ZXJz aW9uIHdoaWNoIGRvZXMgbm90IHN1cHBvcnQgdGhpcyBjYXBhYmlsaXR5PzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5C ZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KaWU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJZHIgWzxhIGhyZWY9Im1h aWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPC9h Pl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Qm9yY2hlcnQsIE9saXZlciAoRmVkKTxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMzAsIDIwMTkgNDozNSBBTTxicj4NCjxiPlRvOjwv Yj4gU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJl c0BuZHpoLmNvbTwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3Jhbmdl LmNvbSI+DQpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPjsgQm9yY2hlcnQsIE9saXZlciAo RmVkKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9saXZlci5ib3JjaGVydEBuaXN0LmdvdiI+b2xpdmVy LmJvcmNoZXJ0QG5pc3QuZ292PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0 bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QnJ1bm8gYW5kIFN1c2FuLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgY2Fubm90IHNwZWFrIGZvciB0 aGUgRXhhQkdQIEltcGxlbWVudGF0aW9uIGJ1dCBmb3IgQkdQU0VDLUlPIGFuZCBRdWFnZ2FTUngu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+SSBiZWxpZXZlIHdoZW4gSSBjb21waWxlZCB0aGUgcmVwb3J0LCBJ IG1pcy1yZWFkIDVhIGFuZCBvdmVybG9va2VkIHRoZSDigJxub3TigJ0gYW5kIHJlYWQgaW5zdGVh ZDog4oCcRG9lcyBzZW5kIEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eeKAnS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5UaGVyZWZvcmUgdGhlIGltcGxlbWVudGF0aW9uIHJlcG9ydCBmb3Igc2VjdGlvbiA1 YSBtdXN0IGJlIGNvcnJlY3RlZCBmcm9tIOKAnFllc+KAnSBpbnRvIOKAnE5v4oCdIGZvciBib3Ro IEJHUFNFQy1JTyBhbmQgUXVhZ2dhU1J4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+QkdQU0VDLUlPIGFuZCBRdWFnZ2FTUngsIGJvdGggZG8gc2VuZCB0aGUgZXh0ZW5k ZWQgbWVzc2FnZSBjYXBhYmlsaXR5IGlmIHNvIGNvbmZpZ3VyZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ SSBqdXN0IGNoZWNrZWQgdGhlIGNvZGUgYW5kIHJ1biBpdCBhZ2Fpbi4gSSBjb3B5L3Bhc3RlZCB0 aGUgcmVsZXZhbnQgb3V0cHV0IGdlbmVyYXRlZCBieSBCR1BTRUMtSU8sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T2xpdmVyPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+LS0tLS0mbmJzcDsgb3V0cHV0IG9mIEJHUFNFQy1JTyZuYnNwOyAt LS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+77u/Li9iZ3Bz ZWNpbyAtZiBiZ3BzZWNpby50ZXN0LmNmZy5xc3J4DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdGFydGlu ZyBiZ3BzZWNpbyAwLjIuMC4yNS4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlbmQ6Jm5ic3A7IChPcGVu IG1lc3NhZ2Ugc2VuZCBmcm9tIEJHUFNFQy1JTyB0byBRdWFnZ2FTUngpDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5PUEVOIE1lc3NhZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgJiM0MzstLW1hcmtlcjog RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igKY8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLU9wdGlvbmFsIFBh cmFtZXRlcjogQ2FwYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7ICYjNDM7LS1UeXBlOiBDYXBhYmlsaXR5ICgyKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1MZW5ndGg6IDI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tQ2FwYWJp bGl0eTogRXh0ZW5kZWQgbWVzc2FnZSBzdXBwb3J0IGNhcGFiaWxpdHk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0tVHlwZTogRXh0ZW5kZWQgbWVzc2FnZSBzdXBwb3J0IGNhcGFiaWxpdHkgKDYpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJiM0MzstLUxlbmd0aDogMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKApjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlY2VpdmVkOiAoT3BlbiBtZXNzYWdlIHNlbmQgZnJv bSBRdWFnZ2FTUnggYW5kIHJlY2VpdmVkIGJ5IEJHUFNFQy1JTyk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5P UEVOIE1lc3NhZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgJiM0MzstLW1hcmtlcjogRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igKY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLU9wdGlvbmFsIFBhcmFtZXRl cjogQ2FwYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tVHlwZTogQ2FwYWJpbGl0eSAoMik8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLUxl bmd0aDogMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tQ2FwYWJpbGl0eTogRXh0ZW5kZWQgbWVzc2FnZSBzdXBwb3J0IGNh cGFiaWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLVR5cGU6IEV4dGVuZGVkIG1lc3Nh Z2Ugc3VwcG9ydCBjYXBhYmlsaXR5ICg2KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tTGVu Z3RoOiAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QkdQLXJlY2VpdmVyIHRocmVhZCBjcmVhdGVkITxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPklkciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9u IGJlaGFsZiBvZiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNv bSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgSmFu dWFyeSAyOSwgMjAxOSBhdCAxMTo0MyBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5j b208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVv dDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogW0lkcl0gV0cgTGFzdCBDYWxsIG9uIEV4dGVuZWQgTWVzc2Fn ZSBTdXBwb3J0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5CcnVubzo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgZm9yIHlvdXIgY29tbWVu dHMgb24gdGhpcyB0b3BpYyDigJMgYXMgSSB0aGluaw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkaWQgcmVjZWl2ZSByZXBvcnRzIHByaXZhdGVseSB0 aGF0IHdlIGhhdmUgMSBmdWxsIGltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1pZXRmLWlkci1iZ3At ZXh0ZW5kZWQtbWVzc2FnZXMgb2ZmIGxpc3Qgd2hpY2ggaXMNCiBub3QgbGlzdGVkIGluIHRoaXMg cmVwb3J0LiAmbmJzcDsmbmJzcDtJIGhvcGUgdGhvc2UgaW1wbGVtZW50ZXJzIHdpbGwgdm9sdW50 ZWVyIHRoaXMgaW5mb3JtYXRpb24gb24gdGhlIGxpc3QuICZuYnNwOyZuYnNwO0lmIG5vdCwgSSB3 aWxsIHNoYXJlIHRoaXMgaW5mb3JtYXRpb24gd2l0aCBBbHZhcm8gYW5kIHRoZSBJRVNHLiZuYnNw OyAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGUgU0lEUiB3b3JrIGRpZCBkZWZpbmUgZHJhZnQtaWV0Zi1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMg YXMgYSByZXF1aXJlbWVudCBhbmQgb25seSBtb3ZlZCB0byBub3Qgc3BlY2lmeWluZyBpdCB3aGVu IHdlIGNvdWxkDQogbm90IHF1aWNrbHkgcGFzcyB0aGlzIHRocm91Z2ggV0cgTEMuIDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSByZWFsIG5lZWRzIGFy ZSBhIGdyb3dpbmcgQkdQLUxTIHRoYXQgbWF5IHJ1biBvdXQgb2YgQkdQIG1lc3NhZ2Ugc3BhY2Uu Jm5ic3A7IEFzIG15IHByZXZpb3VzIGVtYWlsIHRvIElEUiBpbmRpY2F0ZXMsIEkgd2FzIGhvcGlu Zw0KIHRoaXMgaGFuZGxlcyBhbiBCR1AgbWVzc2FnZSB3aG9zZSBsZW5ndGggaXMgYmlnZ2VyIHRo YW4gNDA5NiBieXRlcy4mbmJzcDsgJm5ic3A7VGhhbmsgeW91IGZvciB0aGUgY29ycmVjdGlvbiBv ZjoNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj7igJxUaGUg aXNzdWUgaXMgbm90IHNwZWNpZmljIHRvIGF0dHJpYnV0ZXMgYmlnZ2VyIHRoYW4gNDA5NiBvY3Rl dHMsIGJ1dCB0byBCR1AgbWVzc2FnZSB3aG9zZSBsZW5ndGggaXMgYmlnZ2VyIHRoYW4gNDA5Niwg aXJyZXNwZWN0aXZlDQogb2YgdGhlIHNpemUgb2YgZWFjaCBhdHRyaWJ1dGUu4oCdPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+QXMgdG8geW91ciBjb21tZW50Og0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7i gJxXaHkgaXMgdGhpcyBsaW1pdGVkIHRvIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucz8gQSBwcmlvcmks IHVzaW5nIGV4aXN0aW5nIEJHUCBtZWNoYW5pc20gKEFGSS9TQUZJLCBhdHRyaWJ1dGVzLCAqIGNv bW11bml0aWVzKSBvbmUgY291bGQgZXhjZWVkDQogdGhlIHNpemUgb2YgNDA5NiBvY3RldHMuIEhv dyBkb2VzIHRoZSBCR1Agc3BlYWtlciBzdXBwb3NlZCB0byBiZWhhdmUgaW4gdGhpcyBjYXNlPyBU aGlzIHNob3VsZCBiZSBkZXNjcmliZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiBOb3RlIHRoYXQg dGhpcyBpcyBub3QgYSBjYXNlIG9mIGVycm9yIGhhbmRsaW5nLCBhcyBldmVyeSBCR1Agc3BlYWtl ciBpcyBiZWhhdmluZyBhcyBzcGVjaWZpZWQu4oCdPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGlzIHBy b2JsZW0gaGFzIGJlZW4gdHJ1ZSBmb3IgeWVhcnMsIGFuZCB0aHVzIGFzIGNvLWNoYWlycyBoYWQg aG9wZWQgdG8gaGF2ZSB0aGUgZHJhZnQtaWV0Zi1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMgcGFzc2Vk IHllYXJzIGFnby4gJm5ic3A7Jm5ic3A7QXMgQkdQLUxTDQogYXR0cmlidXRlcyBncm93IHVzZSBh bmQgaW4gbnVtYmVyLCB0aGUgcG90ZW50aWFsIG9mIGV4Y2VlZGluZyB0aGUgQkdQIG1lc3NhZ2Ug bGltaXQgaW5jcmVhc2VzLiAmbmJzcDtJdCBzZWVtcyBsaWtlIGEgZ29vZCBkaXJlY3Rpb24gdG8g cHJldmVudCBpc3N1ZXMuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgaG9wZSB0aGUgYXV0aG9ycyB3 aWxsIGNvbW1lbnQgb24gdGhlIGNoYW5nZXMgeW91IHN1Z2dlc3RlZCB0byB0aGUgdGV4dC4NCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Q2hlZXJzLA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1c2FuIEhhcmVzDQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4NCjxhIGhy ZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNyYWVuZUBvcmFu Z2UuY29tPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPm1h aWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBKYW51YXJ5IDI5LCAyMDE5IDg6MzMgQU08YnI+DQo8Yj5Ubzo8L2I+IFN1c2FuIEhh cmVzPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbSWRyXSBXRyBMYXN0IENhbGwgb24g RXh0ZW5lZCBNZXNzYWdlIFN1cHBvcnQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIFdHLDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPlBsZWFzZSBmaW5kIGJlbG93IHNvbWUgY29tbWVudHMuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ QXMgb2YgdG9kYXksIEkgZG9u4oCZdCBiZWxpZXZlIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyByZWFk eSB0byBiZSBwcm9ncmVzc2VkIHRvIElFU0cvUkZDLCBlc3BlY2lhbGx5IGZvciBhIGRvY3VtZW50 IHVwZGF0aW5nIFJGQyA0MjcxIChjb3JlDQogQkdQIHNwZWMpLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IFRoZSBXRyBjaGFpcnMgaW50ZW5kIHRvIGZvcndhcmQgdGhp cyBkcmFmdCB0byB0aGUgSUVTRyB3aXRoIHRoZSBjdXJyZW50IGxldmVsIG9mIGltcGxlbWVudGF0 aW9uLiZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw IiBjZWxscGFkZGluZz0iMCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIC4uNzVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ0cmFjLmlldGYub3JnJTJGdHJhYyUyRmlkciUyRndpa2klMkZkcmFmdC1pZXRmLWlkci1iZ3At ZXh0ZW5kZWQtaW1wbGVtZW50YXRpb25zJmFtcDtkYXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hl cnQlNDBuaXN0LmdvdiU3QzQwYmI4YTk0M2U2MTRiMTYzN2YzMDhkNjg2MDhkNmNkJTdDMmFiNWQ4 MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjg0Mzc2OTg1OTE2NTA0MyZh bXA7c2RhdGE9aFhCYk9YcXd2WHF0Q1YlMkI5UGJQJTJGN0lFNldKaldVQTJib00zM0tkcyUyQmdo NCUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kv ZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLWltcGxlbWVudGF0aW9uczwvYT4NCiBzYXlzIDog PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj41YSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3Rk Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Eb2VzIG5vdCBzZW5kIEV4dGVuZGVkIE1l c3NhZ2UgY2FwYWJpbGl0eQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHls ZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+WWVzIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8 dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlllcyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSAuLjc1cHQgLjc1cHQgLjc1 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlllcyA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JIG1heSBiZSBtaXN1bmRlcnN0YW5kaW5nIHRoZSBp bXBsZW1lbnRhdGlvbiByZXBvcnQsIGJ1dCBteSByZWFkaW5nIG9mIHRoZSBhYm92ZSBpcyB0aGF0 IG5vbmUgb2YgdGhlIHJlcG9ydGVkIGltcGxlbWVudGF0aW9ucyBzZW5kcyB0aGUNCiBjYXBhYmls aXR5IGhlbmNlIG5vIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIGRyYWZ0LWlldGYtaWRyLWJncC1l eHRlbmRlZC1tZXNzYWdlcy4uIEhlcmUgdGhpcyBkb2N1bWVudCBpcyB1cGRhdGluZyBSRkMgNDI3 MSwgc28gaXQgaXMgbm90IGEgbWlub3IgZXh0ZW5zaW9uIGZvciBhIG5pY2hlIHVzZSBjYXNlLiBT byBJIGRvbuKAmXQgc2VlIHRoZSBhcmd1bWVudHMgZm9yIG5vdCByZXF1aXJpbmcgdGhlIElEUuKA mXMgdXN1YWwgdHdvIGludGVyb3BlcmFibGUNCiBpbXBsZW1lbnRhdGlvbnMuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4tLS0tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+wqcgMTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJwgQXMgQkdQIGlzIGV4dGVuZGVk IHRvIHN1cHBvcnQgbmV3ZXIgQUZJL1NBRklzIGFuZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbmV3ZXIg Y2FwYWJpbGl0aWVzIChlLmcuLCBbPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0i aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5k ZWQtbWVzc2FnZXMtMjclMjNyZWYtSS1ELmlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2wmYW1wO2Rh dGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDNDBiYjhhOTQzZTYxNGIx NjM3ZjMwOGQ2ODYwOGQ2Y2QlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzEl N0MwJTdDNjM2ODQzNzY5ODU5MTY1MDQzJmFtcDtzZGF0YT11WlMlMkJiTjl2NWNpcjJvNUwzVTNq UDJ4RlBiWTRUeiUyRk5uQlBmZEg3aURmMCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGl0bGU9IiZxdW90 O0JHUFNFQyBQcm90b2NvbCBTcGVjaWZpY2F0aW9uJnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+ SS1ELmlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2w8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPl0pLA0KIHRoZXJlIGlzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBhIG5lZWQgdG8g ZXh0ZW5kIHRoZSBtYXhpbXVtIG1lc3NhZ2Ugc2l6ZSBiZXlvbmQgNDA5NiBvY3RldHMuJm5ic3A7 IOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUy Rmh0bWwlMkZkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMjclMjNzZWN0aW9u LTEmYW1wO2RhdGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDNDBiYjhh OTQzZTYxNGIxNjM3ZjMwOGQ2ODYwOGQ2Y2QlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2 MWRlYyU3QzElN0MwJTdDNjM2ODQzNzY5ODU5MTY1MDQzJmFtcDtzZGF0YT1ZVldIQUZiWVJqRyUy RmxXUGJwdzJyVzh1R1E2UVhzczNkdWZtJTJGcUhnUnZEdyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNz YWdlcy0yNyNzZWN0aW9uLTE8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5bPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xz LmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0y NyUyM3JlZi1JLUQuaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbCZhbXA7ZGF0YT0wMiU3QzAxJTdD b2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJiOGE5NDNlNjE0YjE2MzdmMzA4ZDY4NjA4 ZDZjZCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2MzY4NDM3 Njk4NTkxNjUwNDMmYW1wO3NkYXRhPXVaUyUyQmJOOXY1Y2lyMm81TDNVM2pQMnhGUGJZNFR6JTJG Tm5CUGZkSDdpRGYwJTNEJmFtcDtyZXNlcnZlZD0wIiB0aXRsZT0iJnF1b3Q7QkdQU0VDIFByb3Rv Y29sIFNwZWNpZmljYXRpb24mcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5JLUQuaWV0Zi1zaWRy LWJncHNlYy1wcm90b2NvbDwvc3Bhbj48L2E+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPmlzIG5vdyBSRkMgODIwNSAodGhhbmtzIGZvciB1cGRhdGluZyB0aGUgcmVmZXJlbmNl KS4gSXQgaGFzIHJlbW92ZWQgdGhlIG5vcm1hdGl2ZS9hbnkgcmVmZXJlbmNlIHRvIGRyYWZ0LWll dGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy4gU28gcHJlc3VtYWJseSBCR1AgU2VjIGRvZXMg bm90IG5lZWQgZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PkNhbiB3ZSBoYXZlIGFuIHVwZGF0ZSBvbiB0aGlzPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkNhbiB0aGUgaW50cm9k dWN0aW9uIG9mDQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmRyYWZ0LWlldGYtaWRyLWJncC1l eHRlbmRlZC1tZXNzYWdlcyBiZSB1cGRhdGVkIHRvIGludHJvZHVjZSBvbiB0aGUgcmVhbCByZWFz b25zL25lZWRzPzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0t LTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPsKnNDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+wqczIHNheXMg4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QSBw ZWVyIHdoaWNoIGRvZXMgbm90IGFkdmVydGlzZSB0aGlzIGNhcGFiaWxpdHkgTVVTVCBOT1Qgc2Vu ZCBCR1A8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7ICZuYnNwO0V4dGVuZGVkIE1lc3NhZ2VzLCBhbmQgQkdQIEV4dGVuZGVkIE1lc3Nh Z2VzIE1VU1QgTk9UIGJlIHNlbnQgdG8gaXQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5GaW5lLiBUZXh0IGluIMKnNCBzaG91bGQgcHJvYmFibHkgYmUgYWxpZ25lZCB3aXRoIHRo ZSBhYm92ZSAuLmUuZy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPk9MRDogPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ QSBCR1Agc3BlYWtlcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgTUFZIHNlbmQgRXh0ZW5kZWQgTWVzc2FnZXMgdG8gaXRz IHBlZXIgb25seSBpZiBpdCBoYXMgcmVjZWl2ZWQgdGhlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBFeHRl bmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgZnJvbSB0aGF0IHBlZXIuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TkVXOjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BIEJHUCBzcGVh a2VyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBNQVkgc2VuZCBFeHRlbmRlZCBNZXNzYWdlcyB0byBpdHMg cGVlciBvbmx5IGlmIGl0IGhhcyBzZW50IGFuZCByZWNlaXZlZCB0aGU8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eSB0byBhbmQgZnJvbSB0aGF0IHBlZXIuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4tLS0tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgQXBwbGljYXRpb25zIGdlbmVyYXRpbmcgaW5mb3JtYXRpb24gd2hp Y2ggbWlnaHQgYmUgZW5jYXBzdWxhdGVkPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB3aXRoaW4gQkdQIG1lc3NhZ2VzIE1V U1QgbGltaXQgdGhlIHNpemUgb2YgdGhlaXIgcGF5bG9hZCB0byB0YWtlIHRoZTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgbWF4aW11bSBtZXNzYWdlIHNpemUgaW50byBhY2NvdW50LuKAnTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5JIGRvbuKAmXQgc2VlIHdoYXQgbmV3IGJlaGF2aW9yIGlzIGJlZW4gZGVm aW5lZCBoZXJlLiBJZiB0aGVyZSBpcyBub25lLCBJIHdvdWxkIHN1Z2dlc3QgdG8gcmVtb3ZlIHRo aXMgc2VudGVuY2U8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4tLS0tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBBIEJHUCBhbm5vdW5jZW1lbnQgd2lsbCwg aW4gdGhlIG5vcm1hbCBjYXNlLCBwcm9wYWdhdGUgdGhyb3VnaG91dCB0aGU8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IEJHUCBzcGVha2luZyBJbnRlcm5ldDsgYW5kIHRoZXJlIHdpbGwgdW5kb3VidGVkbHkg YmUgQkdQIHNwZWFrZXJzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB3aGljaCBkbyBub3QgaGF2ZSB0aGUg RXh0ZW5kZWQgTWVzc2FnZSBjYXBhYmlsaXR5LiZuYnNwOyBUaGVyZWZvcmUsPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBwdXR0aW5nIGFuIGF0dHJpYnV0ZSB3aGljaCBjYW4gbm90IGJlIGRlY29tcG9zZWQg dG8gNDA5NiBvY3RldHMgb3I8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGxlc3MgaW4gYW4gRXh0ZW5kZWQg TWVzc2FnZSBpcyBhIGxpa2VseSBwYXRoIHRvIHJvdXRpbmcgZmFpbHVyZS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5UaGUgaXNzdWUgaXMgbm90IHNwZWNpZmljIHRvIGF0dHJpYnV0ZXMgYmln Z2VyIHRoYW4gNDA5NiBvY3RldHMsIGJ1dCB0byBCR1AgbWVzc2FnZSB3aG9zZSBsZW5ndGggaXMg YmlnZ2VyIHRoYW4gNDA5NiwgaXJyZXNwZWN0aXZlDQogb2YgdGhlIHNpemUgb2YgZWFjaCBhdHRy aWJ1dGUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UGxlYXNlIGVsYWJvcmF0ZSBvbiB3aGF0IHlv dSBtZWFuIGJ5IOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmFuIGF0dHJpYnV0ZQ0K IHdoaWNoIGNhbiBub3QgYmUgZGVjb21wb3NlZCB0byA0MDk2IG9jdGV0c+KAnTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPi0tLTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJwm bmJzcDsmbmJzcDsgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBCR1AgcHJvdG9jb2wgZGV2ZWxvcGVy cyBhbmQgaW1wbGVtZW50ZXJzIGFyZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY29uc2VydmF0aXZlIGlu IHRoZWlyIGFwcGxpY2F0aW9uIGFuZCB1c2Ugb2YgRXh0ZW5kZWQgTWVzc2FnZXMu4oCdPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgZG9lcyB0aGlzIG1lYW4gZXhhY3RseT8gVGhhdCB0aGV5 IGRvbuKAmXQgdXNlIHRoaXMgZXh0ZW5zaW9uPyBUaGF0IHRoZXkgZG9u4oCZdCB1c2UgdGhpcyBl eHRlbnNpb24gdW5sZXNzIFhYX1RPIEJFIFNQRUNJRklFRF9YWD88L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4tLS08L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IEZ1dHVy ZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucyB3aWxsIG5lZWQgdG8gZGVzY3JpYmUgaG93IHRvIGhh bmRsZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcGVlcnMgd2hpY2ggY2FuIG9ubHkgYWNjb21tb2RhdGUg NDA5NiBvY3RldCBtZXNzYWdlcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5XaHkgaXMgdGhpcyBsaW1pdGVkIHRvIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucz8gQSBwcmlv cmksIHVzaW5nIGV4aXN0aW5nIEJHUCBtZWNoYW5pc20gKEFGSS9TQUZJLCBhdHRyaWJ1dGVzLCAq IGNvbW11bml0aWVzKSBvbmUgY291bGQgZXhjZWVkDQogdGhlIHNpemUgb2YgNDA5NiBvY3RldHMu IEhvdyBkb2VzIHRoZSBCR1Agc3BlYWtlciBzdXBwb3NlZCB0byBiZWhhdmUgaW4gdGhpcyBjYXNl PyBUaGlzIHNob3VsZCBiZSBkZXNjcmliZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiBOb3RlIHRo YXQgdGhpcyBpcyBub3QgYSBjYXNlIG9mIGVycm9yIGhhbmRsaW5nLCBhcyBldmVyeSBCR1Agc3Bl YWtlciBpcyBiZWhhdmluZyBhcyBzcGVjaWZpZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+LS0tLTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkRlcGVuZGluZyBvbiB0aGUgYWJvdmUg c3BlY2lmaWNhdGlvbiwgYSBzZWN0aW9uIGRlc2NyaWJpbmcgdGhlIG9wZXJhdGlvbmFsIGNvbnNl cXVlbmNlcyBpbiBhIG5ldHdvcmsgKHN1Y2ggYXMgdGhlIEludGVybmV0LA0KIEJHUCBFbmFibGVk IFNlcnZpY2VTL1ZQTiBuZXR3b3JrcykgaXMgcHJvYmFibHkgbmVlZGVkLiBQb3NzaWJsZSBjb25z ZXF1ZW5jZXMgY291bGQgYmUgQkdQIE5MUkkgYmVpbmcgcmVtb3ZlZCBpbiB0aGUgbWlkZGxlIG9m IHN1Y2ggbmV0d29yaywgb3IgKGV4dGVuZGVkKSBjb21tdW5pdHkgKHN1Y2ggYXMgUm91dGUgVGFy Z2V0cykgYmVlbiByZW1vdmVkLiBCb3RoIGhhdmluZyBzaWduaWZpY2FudCBjb25zZXF1ZW5jZXMg b24gdGhlIGF2YWlsYWJpbGl0eQ0KIHByb3ZpZGVkIGJ5IHRoZSBuZXR3b3JrLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPi0tLTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPsKnNDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PTEQ6IFRoZSBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxp dHkgb25seSBhcHBsaWVzIHRvIGFsbCBtZXNzYWdlcyBleGNlcHQgZm9yIHRoZSBPUEVOIG1lc3Nh Z2UuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+UHJvYmFibHk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TkVXOiBUaGUgRXh0ZW5kZWQgTWVzc2FnZSBDYXBh YmlsaXR5IGFwcGxpZXMgdG8gYWxsIG1lc3NhZ2UgdHlwZXMgZXhjZXB0IGZvciB0aGUgT1BFTiBt ZXNzYWdlICh0eXBlIDEpLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+wqc4PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCcVGhpcyBleHRlbnNpb24gdG8gQkdQIGRv ZXMgbm90IGNoYW5nZSBCR1AncyB1bmRlcmx5aW5nIHNlY3VyaXR5IGlzc3VlcyZuYnNwO8K7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDb25zb2xhcyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QmVmb3JlIGV2YWx1YXRpbmcgdGhp cywgSSB0aGluayB0aGlzIGRvY3VtZW50IHNob3VsZCBmaXJzdCBzcGVjaWZpZWQgaG93IGEgQkdQ IG1lc3NhZ2VzIGJpZ2dlciB0aGFuIDQwOTYgb2N0ZXRzIGlzIGhhbmRsZWQgd2hlbiBpdCBuZWVk cyB0byBiZSBzZW50IHRvIGEgcmVjZWl2ZWQgbm90IHN1cHBvcnRpbmcgdGhpcyBleHRlbnNpb24u PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDb25zb2xhcyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk5pdHM6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9MRCZuYnNwOzogdG8gcmVk dWNlIGNvbXBleGl0eTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5ORVcmbmJzcDs6IHRvIHJlZHVjZSBjb21wbGV4aXR5PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoYW5rcyw8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4tLUJydW5vPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IElkciBbPGEgaHJlZj0i bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TdXNhbiBIYXJlczxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBKYW51YXJ5IDI5LCAyMDE5IDEyOjMzIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVm PSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkZSIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5UaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBMQyBvbiBFeHRlbmRlZCBNZXNzYWdl IFN1cHBvcnQgZm9yIEJHUCAoZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTI3 KS4mbmJzcDsgWW91IGNhbiBhY2Nlc3MNCiB0aGUgZHJhZnQgYXQ6IDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZk b2MlMkZkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMlMkYmYW1wO2RhdGE9MDIl N0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDNDBiYjhhOTQzZTYxNGIxNjM3ZjMw OGQ2ODYwOGQ2Y2QlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdD NjM2ODQzNzY5ODU5MzIxMjg5JmFtcDtzZGF0YT1va2pUZUxlNkRjVGFSVjJVU3kyTXk2SFhEUnlu dXBtWGxCMGk3Z1V3eW5BJTNEJmFtcDtyZXNlcnZlZD0wIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVz c2FnZXMvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIGF1dGhvcnMg c2hvdWxkIGluZGljYXRlIHdoZXRoZXIgdGhleSBrbm93IG9mIGFueSBJUFIuJm5ic3A7Jm5ic3A7 IEltcGxlbWVudGVycyBhcmUgZW5jb3VyYWdlZCB0byB1cGRhdGUgdGhlJm5ic3A7IGltcGxlbWVu dGF0aW9uIGRhdGENCiBhdDogPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJl Zj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ0cmFjLmlldGYub3JnJTJGdHJhYyUyRmlkciUyRndpa2klMkZkcmFmdC1pZXRm LWlkci1iZ3AtZXh0ZW5kZWQtaW1wbGVtZW50YXRpb25zJmFtcDtkYXRhPTAyJTdDMDElN0NvbGl2 ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3QzQwYmI4YTk0M2U2MTRiMTYzN2YzMDhkNjg2MDhkNmNk JTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjg0Mzc2OTg1 OTMyMTI4OSZhbXA7c2RhdGE9UG9SeUZvZnMwNCUyRkMlMkYlMkZnYlhMMnp5RUQzU1c2TXJFU3BI aUlFMmU3cDRjQSUzRCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly90cmFj LmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLWltcGxl bWVudGF0aW9uczwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBkcmFm dCBwcm92aWRlcyBhIG1lYW5zIGZvciBleHBhbmRpbmcgdGhlIEJHUCBtZXNzYWdlIHRvIDY1NTM1 IG9jdGV0cyBmb3IgYWxsIG1lc3NhZ2VzIGV4Y2VwdCBPUEVOIG1lc3NhZ2VzLiZuYnNwOyBCR1Ag bWVzc2FnZQ0KIHNwYWNlIGlzIHJ1bm5pbmcgc2hvcnQgZm9yIGFsbCBvZiB0aGUgcG90ZW50aWFs IGF0dHJpYnV0ZXMgb3IgYWRkaXRpb25zIHByb3Bvc2VkIGJ5IEJHUC1MUyBmZWF0dXJlcy4mbmJz cDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PlRoZSBXRyBjaGFpcnMgaW50ZW5kIHRvIGZvcndhcmQgdGhpcyBkcmFmdCB0byB0aGUgSUVTRyB3 aXRoIHRoZSBjdXJyZW50IGxldmVsIG9mIGltcGxlbWVudGF0aW9uLiZuYnNwOw0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QXMgeW91IGNvbW1l bnQgb24gdGhlIGRyYWZ0LCBwbGVhc2UgY29uc2lkZXIgaWY6IGEpIHRoZSB0ZWNobm9sb2d5IGlz IG1hdHVyZSwgYikgdGhlIGFkZGl0aW9uYWwgc3BhY2UgaW4gYSBCR1AgbWVzc2FnZSB3b3VsZA0K IGJlIGhlbHBmdWwgZm9yIHRob3NlIGRlcGxveWluZyBCR1AtTFMgb3IgU1IsIGFuZCBjKSBpZiB0 aGUgc3BlY2lmaWNhdGlvbiBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uJm5ic3A7DQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TdWUgSGFyZXMg KFdHIENoYWlyLCBTaGVwaGVyZCkNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Q2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDb25zb2xhcyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcyI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5hIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXMiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5UaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ozwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMi PnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzIj5UaGFuayB5b3UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_76CD132C3ADEF848BD84D028D243C927C32AEB75NKGEML515MBSchi_-- From nobody Mon Feb 4 12:14:06 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D9A124C04 for ; Mon, 4 Feb 2019 12:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.653 X-Spam-Level: X-Spam-Status: No, score=-12.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_vuIkq31zm9 for ; Mon, 4 Feb 2019 12:13:59 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F7B1200D7 for ; Mon, 4 Feb 2019 12:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=118830; q=dns/txt; s=iport; t=1549311238; x=1550520838; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=woM5a0iZ8nXR1pGuABjmsSA4KWEqnT7p80esC6LHGro=; b=b1GSlUNBM65UANpzaeWU+DgqO0tG05vFbrT57gJdeblIEJlLv9vrW9nw VJvqgXUbl2Ge4bGWzokP/RcevN9r6DNirnITS/9aNIveHyIDTDIOxmX0K GR5dGtXrK0un6aYPE35vCe8FlF9QCeecFEwwHkDedf7bQJjcALQSICfmt 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAACJnFhc/4ENJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ12Z4EDJwqDeYFfhjuLdYINfJcTFIF?= =?us-ascii?q?nCwEBIoEPXYJeAheDCSI0CQ0BAwEBAgEBAm0cDIVKAQEBAQIBGgEICkwFCwI?= =?us-ascii?q?BCBEDAQEBFgsBBgMCAgIwFAkIAgQBDQUIDIMJBAKBHUwDDQgPqwaBL4QvARN?= =?us-ascii?q?BgwYDgiMFjEEXgUA/gRABgl0HLoMeAQECAQEWgQISAQsBBgEHLwkGBgoJgkq?= =?us-ascii?q?CVwKJXRgBCgcghWiHA4tgCQKHMIsAIYFsgXODTmmCVIdaiiOBDIQjjAYCERS?= =?us-ascii?q?BJx84DVhxcBU7gmwTgWUtAwUSg0uFFIU/QTEBAQEBi3UBDheBCDJtAQE?= X-IronPort-AV: E=Sophos;i="5.56,560,1539648000"; d="scan'208,217";a="512847004" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2019 20:13:56 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x14KDurd030132 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Feb 2019 20:13:56 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 4 Feb 2019 14:13:55 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1395.000; Mon, 4 Feb 2019 14:13:55 -0600 From: "Jakob Heitz (jheitz)" To: "Dongjie (Jimmy)" , Susan Hares , "'Borchert, Oliver (Fed)'" , "bruno.decraene@orange.com" , "'Borchert, Oliver (Fed)'" CC: "idr@ietf.org" Thread-Topic: [Idr] WG Last Call on Extened Message Support Thread-Index: AdS3xjQ/tSoF1syoSCC0lUpnr5BmnQACO/8QABUu6QAACB5qAAA9Z2KAAE3h5wAAIOhfgABz6gyA Date: Mon, 4 Feb 2019 20:13:55 +0000 Message-ID: References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <009501d4b7f1$962d0080$c2870180$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927C3286B43@NKGEML515-MBX.china.huawei.com> <00e201d4ba3f$34bb67b0$9e323710$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927C32AEB75@NKGEML515-MBS.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927C32AEB75@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.160.238] Content-Type: multipart/alternative; boundary="_000_ba5ddfd47a7c42db8e3ad1fba72fd18aXCHALN014ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 20:14:04 -0000 --_000_ba5ddfd47a7c42db8e3ad1fba72fd18aXCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QkdQU2VjIGRyb3BwZWQgdGhlIHJlcXVpcmVtZW50IGZvciBleHRlbmRlZCBtZXNzYWdlcyBiZWNh dXNlIHRoZQ0Kc2lnbmF0dXJlIHdhcyBjaGFuZ2VkIGZyb20gUlNBLTIwNDggKDI1NiBieXRlIHNp ZykgdG8gRUNEU0EgUC0yNTYgKDY0IGJ5dGUgc2lnKS4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvc2lkci9MUkhQdU81TUYwdS12V3VoTkFWZVZOXzhmSVUNCg0KVGhlcmUg aXMgbm8gbWVudGlvbiBvZiBleHRlbmRlZCBtZXNzYWdlcyBpbiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjODIwNQ0KQWxsIG1lbnRpb24gb2YgaXQgd2FzIHN0cnVjayBvdXQgaW46DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNpZHItYmdwc2Vj LXByb3RvY29sLTIzLnR4dA0KDQpSZWdhcmRzLA0KSmFrb2IuDQoNCkZyb206IElkciA8aWRyLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBEb25namllIChKaW1teSkNClNlbnQ6IEZyaWRh eSwgRmVicnVhcnkgMSwgMjAxOSAxMDo0NSBQTQ0KVG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6 aC5jb20+OyAnQm9yY2hlcnQsIE9saXZlciAoRmVkKScgPG9saXZlci5ib3JjaGVydD00MG5pc3Qu Z292QGRtYXJjLmlldGYub3JnPjsgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTsgJ0JvcmNoZXJ0 LCBPbGl2ZXIgKEZlZCknIDxvbGl2ZXIuYm9yY2hlcnRAbmlzdC5nb3Y+DQpDYzogaWRyQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0lkcl0gV0cgTGFzdCBDYWxsIG9uIEV4dGVuZWQgTWVzc2FnZSBT dXBwb3J0DQoNCkhpIFN1ZSwNCg0KVGhhbmtzIGZvciB1cGRhdGluZyB0aGUgaW1wbGVtZW50YXRp b24gcmVwb3J0Lg0KDQpNeSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IGJ1bGxldCA0IHdhcyB0byBj b3ZlciB0aGUgYmVoYXZpb3Igb2Ygc2VjdGlvbiA1IHBhcmFncmFwaCAxLCBidWxsZXQgNSB3YXMg dG8gY292ZXIgdGhlIGJlaGF2aW9yIG9mIHNlY3Rpb24gNSBwYXJhZ3JhcGggMi4NCg0KQnV0IGFm dGVyIHJlcmVhZGluZyBzZWN0aW9uIDUsIEkgcmVhbGl6ZSB0aGF0IGJvdGggcGFyYWdyYXBoIDEg YW5kIDIgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGJlaGF2aW9yIG9mIGEgQkdQIHNwZWFrZXIgd2hp Y2ggZG9lcyBub3QgYWR2ZXJ0aXNlIHRoZSBleHRlbmRlZCBtZXNzYWdlIGNhcGFiaWxpdHkgdG8g aXRzIHBlZXIsIHNvIHBlcmhhcHMgYnVsbGV0cyA0IGFuZCA1IGluIHRoZSBpbXBsZW1lbnRhdGlv biByZXBvcnQgY291bGQgYmUgbWVyZ2VkIGFzIGJlbG93Og0KDQo0LiBXaGVuIHJlY2VpdmVzIGFu IGV4dGVuZGVkIG1lc3NhZ2Ugd2l0aG91dCBhZHZlcnRpc2luZyB0aGUgQkdQIEV4dGVuZGVkIE1l c3NhZ2UgQ2FwYWJpbGl0eSB0byB0aGlzIHBlZXIgKEVycm9yIEhhbmRsaW5nKS4NCjRhLiBBY2Nl cHRzIHRoZSBleHRlbmRlZCBtZXNzYWdlIGlmIHRoZSBCR1Agc3BlYWtlciBpcyBhYmxlIHRvIHBy b2Nlc3MgZXh0ZW5kZWQgbWVzc2FnZSAoYnV0IHdhcyBjb25maWd1cmVkIG5vdCB0byBhZHZlcnRp c2UgdGhlIGNhcGFiaWxpdHkpICAgW1NlY3Rpb24gNSwgcGFyYWdyYXBoIDEgTUFZXQ0KNGIuIERv ZXMgbm90IGFjY2VwdCB0aGUgZXh0ZW5kZWQgbWVzc2FnZSwgZm9sbG93cyBSRkM0MjcxIGhhbmRs aW5nIGFuZCBzZW5kcyBCYWQgTWVzc2FnZSBMZW5ndGggTm90aWZpY2F0aW9uIFtTZWN0aW9uIDUs IHBhcmFncmFwaCAxIFNIT1VMRCBOT1QsIGFuZCBwYXJhZ3JhcGggMiBNVVNUKQ0KDQpIb3BlIHRo aXMgaGVscHMgdG8gcmVkdWNlIHRoZSBjb25mdXNpb24uDQoNCkJlc3QgcmVnYXJkcywNCkppZQ0K DQoNCkZyb206IFN1c2FuIEhhcmVzIFttYWlsdG86c2hhcmVzQG5kemguY29tXQ0KU2VudDogRnJp ZGF5LCBGZWJydWFyeSAwMSwgMjAxOSAxMTowMyBQTQ0KVG86IERvbmdqaWUgKEppbW15KSA8amll LmRvbmdAaHVhd2VpLmNvbTxtYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbT4+OyAnQm9yY2hlcnQs IE9saXZlciAoRmVkKScgPG9saXZlci5ib3JjaGVydD00MG5pc3QuZ292QGRtYXJjLmlldGYub3Jn PG1haWx0bzpvbGl2ZXIuYm9yY2hlcnQ9NDBuaXN0LmdvdkBkbWFyYy5pZXRmLm9yZz4+OyBicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPjsg J0JvcmNoZXJ0LCBPbGl2ZXIgKEZlZCknIDxvbGl2ZXIuYm9yY2hlcnRAbmlzdC5nb3Y8bWFpbHRv Om9saXZlci5ib3JjaGVydEBuaXN0Lmdvdj4+DQpDYzogaWRyQGlldGYub3JnPG1haWx0bzppZHJA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0lkcl0gV0cgTGFzdCBDYWxsIG9uIEV4dGVuZWQgTWVz c2FnZSBTdXBwb3J0DQoNCkpJZSwgQnJ1bm8gYW5kIE9saXZlcjoNCg0KVGhhbmsgeW91IGZvciB5 b3VyIGlucHV0LiAgIFlvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBlcnJvciBoYW5kbGluZyBiZWhh dmlvciB3YXMgdW5jbGVhciBiYXNlZCBvbiB0aGUgcXVlc3Rpb25zIGluIHRoZSBjaGFydC4gICBU aGUgcHVycG9zZSBvZiB0aGUgY2hhcnQgaXMgdG8gcHJvdmlkZSBvdGhlciBCR1AgV0dzIChCZXNz LCBTUFJJTkcsIExTVlIpIGEgY2xlYXIgaW5kaWNhdGlvbiBvZiBjaGFuZ2VzIHRvIHRoZSBiYXNl IEJHUCBzcGVjaWZpY2F0aW9uLg0KDQpJ4oCZdmUgcmVmb3JtYXR0ZWQgc2VjdGlvbnMgNCBhbmQg NSBvZiB0aGUgY2hhcnQuDQoNClRvIHNlY3Rpb24gNCBJ4oCZdmUgYWRkZWQ6DQo0YyAgICAgICAg ICAgIERvZXMgc2VuZCBFeHRlbmRlZCBNZXNzYWdlICAtIHdpdGggYSB5ZXMgZnJvbSBhbGwgaW1w bGVtZW50YXRpb25zIChiYXNlZCBvbiB0aGVpciBlbWFpbCkNCg0KU2VjdGlvbiA1LCBJ4oCZdmUg YWx0ZXIgdG8gYmU6DQo1ICAgICAgICAgICAgICBFcnJvciBoYW5kaW5nDQo1YSAgICAgICAgICAg QWNjZXB0cyBFeHRlbmRlZCBtZXNzYWdlIHdpdGhvdXQgcmVjZWl2aW5nDQogICAgICAgICAgICAg QkdQIEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eSBbU2VjdGlvbiA1IHBhcmFncmFwaCAxIE1B WV0NCg0KNWIgICAgICAgICAgIElmIHJlY2VpdmVzIEV4dGVuZGVkIE1lc3NhZ2Ugd2l0aG91dCBC R1AgZXh0ZW5kZWQgbWVzc2FnZSBzdXBwb3J0LA0KICAgICAgICAgICAgIGZvbGxvd3MgUkZDNDI3 MSBoYW5kbGluZyBhbmQgc2VuZHMgQmFkIG1lc3NhZ2UgbGVuZ3RoIE5vdGlmaWNhdGlvbg0KICAg ICAgICAgICAgW3NlY3Rpb24gNSBwYXJhZ3JhcGggMiBNVVNUXQ0KDQpPbGl2ZXIg4oCTIGlmIHlv dSB3b3VsZCByZWFkIHRoZSBjdXJyZW50IHRleHQgYW5kIGxldCBtZSBrbm93IHRoZSB1cGRhdGVk IG1lc3NhZ2UuICBJIGJlbGlldmUgdGhlIGFuc3dlciBmb3IgYWxsIDMgaW1wbGVtZW50YXRpb25z IGlzIOKAnHllc+KAnSBkdWUgdG8gNGIuICAgUGxlYXNlIGxldCBtZSBrbm93IGFuZCBJIHdpbGwg dXBkYXRlIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgY2hhcnQuDQoNClRvIGZvbGxvdy11cCBvbiBK aWXigJlzIGNvbW1lbnRzLCB0aGUgdGV4dCBkaWQgbm90IGFjY3VyYXRlbHkgcmVwcmVzZW50IHRo ZSBlcnJvciBoYW5kbGluZy4gICBTZWN0aW9uIDUsIHBhcmFncmFwaCAxIGhhcyBhIOKAnFNIT1VM RCBOT1TigJ0gbW9kaWZpZWQgYnkgYSDigJxNQVnigJ0sIHdoaWNoIHJlc3VsdHMgaW4gc2ltcGx5 IGEg4oCcTUFZ4oCdLiAgIEZvciByZWFkYWJpbGl0eSwgSSB0aGluayB0aGUg4oCcU0hPVUxEIE5P VOKAnSBwcm92aWRlcyB1c2VmdWwgaW5mb3JtYXRpb24gIHRvIHRoZSBpbXBsZW1lbnRlciwgIGJ1 dCBpdCBjYW5ub3QgYmUgdGVzdGVkIGFjY3VyYXRlbHkgd2hlbiBjb21iaW5lZCB3aXRoIHRoZSDi gJxNQVnigJ0uDQoNCkxldCBtZSBnaXZlIHlvdSBhbiBleGFtcGxlIG9mIHRoYXQ6DQpJZiB0aGUg cGVlciBkaWQgbm90IHNlbmQgYSBCR1AgRXh0ZW5kZWQgTWVzc2FnZSBjYXBhYmlsaXR5LCBhbmQg aXQgYWNjZXB0cyB0aGUgZXh0ZW5kZWQgbWVzc2FnZSAod2l0aCBhIGxlbmd0aCBvZiAxMCwwMDAg Ynl0ZXMpLCBpdCBjb3VsZCBoYXZlIGEgbGliZXJhbCBwb2xpY3kgb2YgTUFZIGFzIGEgZGVmYXVs dCBpbiB0aGUgaW1wbGVtZW50YXRpb24uICAgVGhlIOKAnG9uLXdpcmXigJ0gb2JzZXJ2YXRpb25z IGNhbm5vdCB0ZWxsIOKAkyBvbmx5IHRoZSBpbXBsZW1lbnRhdGlvbuKAmXMgcG9saWN5IChkZWZh dWx0ICsgY29uZmlndXJlZCkuDQoNCkkgYWxzbyBicm9rZSBvdXQgdGhlIG1hbmFnZW1lbnQgaW5m b3JtYXRpb24gYXdheSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uIGluZm9ybWF0aW9uLg0KDQpTdWUg SGFyZXMNCg0KRnJvbTogRG9uZ2ppZSAoSmltbXkpIFttYWlsdG86amllLmRvbmdAaHVhd2VpLmNv bV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAzMCwgMjAxOSA4OjUzIFBNDQpUbzogQm9yY2hl cnQsIE9saXZlciAoRmVkKTsgU3VzYW4gSGFyZXM7IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208 bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+OyBCb3JjaGVydCwgT2xpdmVyIChGZWQp DQpDYzogaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0lk cl0gV0cgTGFzdCBDYWxsIG9uIEV4dGVuZWQgTWVzc2FnZSBTdXBwb3J0DQoNCkhpIE9saXZlciwg QnJ1bm8gYW5kIFN1ZSwNCg0KVG8gbXkgdW5kZXJzdGFuZGluZywgYnVsbGV0IDUvNWEvNWIgaW4g dGhlIGltcGxlbWVudGF0aW9uIHJlcG9ydCBpcyBjb3JyZXNwb25kaW5nIHRvIHRoZSBzZWNvbmQg cGFyYWdyYXBoIGluIHNlY3Rpb24gNSDigJxFcnJvciBIYW5kbGluZ+KAnToNCg0KQSBCR1Agc3Bl YWtlciB0aGF0IGRvZXMgbm90IGFkdmVydGlzZSB0aGUgQkdQIEV4dGVuZGVkIE1lc3NhZ2VzDQog ICBjYXBhYmlsaXR5IG1pZ2h0IGFsc28gZ2VudWluZWx5IG5vdCBzdXBwb3J0IEV4dGVuZGVkIE1l c3NhZ2VzLiAgU3VjaA0KICAgYSBzcGVha2VyIE1VU1QgZm9sbG93IHRoZSBlcnJvciBoYW5kbGlu ZyBwcm9jZWR1cmVzIG9mIFtSRkM0MjcxXSBpZg0KICAgaXQgcmVjZWl2ZXMgYW4gRXh0ZW5kZWQg TWVzc2FnZS4gIFNpbWlsYXJseSwgYW55IHNwZWFrZXIgdGhhdCB0cmVhdHMNCiAgIGFuIGltcHJv cGVyIEV4dGVuZGVkIE1lc3NhZ2UgYXMgYSBmYXRhbCBlcnJvciwgTVVTVCB0cmVhdCBpdA0KICAg c2ltaWxhcmx5Lg0KDQpUaHVzIGl0IGlzIHRvIGRlc2NyaWJlIHRoZSBlcnJvciBoYW5kbGluZyBi ZWhhdmlvciBvZiBhbiBpbXBsZW1lbnRhdGlvbiB2ZXJzaW9uIHdoaWNoIGRvZXMgbm90IHN1cHBv cnQgZXh0ZW5kZWQgbWVzc2FnZS4NCg0KV2hpbGUgSSBhZ3JlZSB0aGlzIGNvdWxkIGJlIG1pc2xl YWRpbmcgZm9yIGEgcmVwb3J0IG9mIGltcGxlbWVudGF0aW9uIHdoaWNoIHN1cHBvcnRzIGV4dGVu ZGVkIG1lc3NhZ2UgY2FwYWJpbGl0eSwgbWF5YmUgaXQgY291bGQgYmUgdXNlZCB0byB2ZXJpZnkg dGhlIGJlaGF2aW9yIG9mIGFuIG9sZCB2ZXJzaW9uIHdoaWNoIGRvZXMgbm90IHN1cHBvcnQgdGhp cyBjYXBhYmlsaXR5Pw0KDQpCZXN0IHJlZ2FyZHMsDQpKaWUNCg0KRnJvbTogSWRyIFttYWlsdG86 aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCb3JjaGVydCwgT2xpdmVyIChGZWQp DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMzAsIDIwMTkgNDozNSBBTQ0KVG86IFN1c2FuIEhh cmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+OyBicnVuby5kZWNy YWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPjsgQm9yY2hl cnQsIE9saXZlciAoRmVkKSA8b2xpdmVyLmJvcmNoZXJ0QG5pc3QuZ292PG1haWx0bzpvbGl2ZXIu Ym9yY2hlcnRAbmlzdC5nb3Y+Pg0KQ2M6IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3Vw cG9ydA0KDQpCcnVubyBhbmQgU3VzYW4sDQoNCkkgY2Fubm90IHNwZWFrIGZvciB0aGUgRXhhQkdQ IEltcGxlbWVudGF0aW9uIGJ1dCBmb3IgQkdQU0VDLUlPIGFuZCBRdWFnZ2FTUnguDQpJIGJlbGll dmUgd2hlbiBJIGNvbXBpbGVkIHRoZSByZXBvcnQsIEkgbWlzLXJlYWQgNWEgYW5kIG92ZXJsb29r ZWQgdGhlIOKAnG5vdOKAnSBhbmQgcmVhZCBpbnN0ZWFkOiDigJxEb2VzIHNlbmQgRXh0ZW5kZWQg TWVzc2FnZSBDYXBhYmlsaXR54oCdLg0KVGhlcmVmb3JlIHRoZSBpbXBsZW1lbnRhdGlvbiByZXBv cnQgZm9yIHNlY3Rpb24gNWEgbXVzdCBiZSBjb3JyZWN0ZWQgZnJvbSDigJxZZXPigJ0gaW50byDi gJxOb+KAnSBmb3IgYm90aCBCR1BTRUMtSU8gYW5kIFF1YWdnYVNSeA0KDQpCR1BTRUMtSU8gYW5k IFF1YWdnYVNSeCwgYm90aCBkbyBzZW5kIHRoZSBleHRlbmRlZCBtZXNzYWdlIGNhcGFiaWxpdHkg aWYgc28gY29uZmlndXJlZC4NCkkganVzdCBjaGVja2VkIHRoZSBjb2RlIGFuZCBydW4gaXQgYWdh aW4uIEkgY29weS9wYXN0ZWQgdGhlIHJlbGV2YW50IG91dHB1dCBnZW5lcmF0ZWQgYnkgQkdQU0VD LUlPLA0KDQpPbGl2ZXINCg0KLS0tLS0gIG91dHB1dCBvZiBCR1BTRUMtSU8gIC0tLS0tLS0NCg0K 77u/Li9iZ3BzZWNpbyAtZiBiZ3BzZWNpby50ZXN0LmNmZy5xc3J4DQpTdGFydGluZyBiZ3BzZWNp byAwLjIuMC4yNS4uLg0KU2VuZDogIChPcGVuIG1lc3NhZ2Ugc2VuZCBmcm9tIEJHUFNFQy1JTyB0 byBRdWFnZ2FTUngpDQpPUEVOIE1lc3NhZ2UNCiAgKy0tbWFya2VyOiBGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRg0K4oCmDQogICAgICstLU9wdGlvbmFsIFBhcmFtZXRlcjogQ2FwYWJp bGl0eQ0KICAgICB8ICArLS1UeXBlOiBDYXBhYmlsaXR5ICgyKQ0KICAgICB8ICArLS1MZW5ndGg6 IDINCiAgICAgfCAgKy0tQ2FwYWJpbGl0eTogRXh0ZW5kZWQgbWVzc2FnZSBzdXBwb3J0IGNhcGFi aWxpdHkNCiAgICAgfCAgICAgKy0tVHlwZTogRXh0ZW5kZWQgbWVzc2FnZSBzdXBwb3J0IGNhcGFi aWxpdHkgKDYpDQogICAgIHwgICAgICstLUxlbmd0aDogMA0K4oCmDQoNClJlY2VpdmVkOiAoT3Bl biBtZXNzYWdlIHNlbmQgZnJvbSBRdWFnZ2FTUnggYW5kIHJlY2VpdmVkIGJ5IEJHUFNFQy1JTykN Ck9QRU4gTWVzc2FnZQ0KICArLS1tYXJrZXI6IEZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGDQrigKYNCiAgICAgKy0tT3B0aW9uYWwgUGFyYW1ldGVyOiBDYXBhYmlsaXR5DQogICAgICAg ICstLVR5cGU6IENhcGFiaWxpdHkgKDIpDQogICAgICAgICstLUxlbmd0aDogMg0KICAgICAgICAr LS1DYXBhYmlsaXR5OiBFeHRlbmRlZCBtZXNzYWdlIHN1cHBvcnQgY2FwYWJpbGl0eQ0KICAgICAg ICAgICArLS1UeXBlOiBFeHRlbmRlZCBtZXNzYWdlIHN1cHBvcnQgY2FwYWJpbGl0eSAoNikNCiAg ICAgICAgICAgKy0tTGVuZ3RoOiAwDQpCR1AtcmVjZWl2ZXIgdGhyZWFkIGNyZWF0ZWQhDQoNCg0K DQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNlc0BpZXRm Lm9yZz4+IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpz aGFyZXNAbmR6aC5jb20+Pg0KRGF0ZTogVHVlc2RheSwgSmFudWFyeSAyOSwgMjAxOSBhdCAxMTo0 MyBBTQ0KVG86ICJicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVu ZUBvcmFuZ2UuY29tPiIgPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRl Y3JhZW5lQG9yYW5nZS5jb20+Pg0KQ2M6ICJpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9y Zz4iIDxpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lk cl0gV0cgTGFzdCBDYWxsIG9uIEV4dGVuZWQgTWVzc2FnZSBTdXBwb3J0DQoNCkJydW5vOg0KDQpU aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMgb24gdGhpcyB0b3BpYyDigJMgYXMgSSB0aGluaw0K DQpJIGRpZCByZWNlaXZlIHJlcG9ydHMgcHJpdmF0ZWx5IHRoYXQgd2UgaGF2ZSAxIGZ1bGwgaW1w bGVtZW50YXRpb25zIG9mIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcyBvZmYg bGlzdCB3aGljaCBpcyBub3QgbGlzdGVkIGluIHRoaXMgcmVwb3J0LiAgIEkgaG9wZSB0aG9zZSBp bXBsZW1lbnRlcnMgd2lsbCB2b2x1bnRlZXIgdGhpcyBpbmZvcm1hdGlvbiBvbiB0aGUgbGlzdC4g ICBJZiBub3QsIEkgd2lsbCBzaGFyZSB0aGlzIGluZm9ybWF0aW9uIHdpdGggQWx2YXJvIGFuZCB0 aGUgSUVTRy4NCg0KVGhlIFNJRFIgd29yayBkaWQgZGVmaW5lIGRyYWZ0LWlldGYtYmdwLWV4dGVu ZGVkLW1lc3NhZ2VzIGFzIGEgcmVxdWlyZW1lbnQgYW5kIG9ubHkgbW92ZWQgdG8gbm90IHNwZWNp ZnlpbmcgaXQgd2hlbiB3ZSBjb3VsZCBub3QgcXVpY2tseSBwYXNzIHRoaXMgdGhyb3VnaCBXRyBM Qy4NCg0KVGhlIHJlYWwgbmVlZHMgYXJlIGEgZ3Jvd2luZyBCR1AtTFMgdGhhdCBtYXkgcnVuIG91 dCBvZiBCR1AgbWVzc2FnZSBzcGFjZS4gIEFzIG15IHByZXZpb3VzIGVtYWlsIHRvIElEUiBpbmRp Y2F0ZXMsIEkgd2FzIGhvcGluZyB0aGlzIGhhbmRsZXMgYW4gQkdQIG1lc3NhZ2Ugd2hvc2UgbGVu Z3RoIGlzIGJpZ2dlciB0aGFuIDQwOTYgYnl0ZXMuICAgVGhhbmsgeW91IGZvciB0aGUgY29ycmVj dGlvbiBvZjoNCg0K4oCcVGhlIGlzc3VlIGlzIG5vdCBzcGVjaWZpYyB0byBhdHRyaWJ1dGVzIGJp Z2dlciB0aGFuIDQwOTYgb2N0ZXRzLCBidXQgdG8gQkdQIG1lc3NhZ2Ugd2hvc2UgbGVuZ3RoIGlz IGJpZ2dlciB0aGFuIDQwOTYsIGlycmVzcGVjdGl2ZSBvZiB0aGUgc2l6ZSBvZiBlYWNoIGF0dHJp YnV0ZS7igJ0NCg0KDQpBcyB0byB5b3VyIGNvbW1lbnQ6DQoNCuKAnFdoeSBpcyB0aGlzIGxpbWl0 ZWQgdG8gZnV0dXJlIHNwZWNpZmljYXRpb25zPyBBIHByaW9yaSwgdXNpbmcgZXhpc3RpbmcgQkdQ IG1lY2hhbmlzbSAoQUZJL1NBRkksIGF0dHJpYnV0ZXMsICogY29tbXVuaXRpZXMpIG9uZSBjb3Vs ZCBleGNlZWQgdGhlIHNpemUgb2YgNDA5NiBvY3RldHMuIEhvdyBkb2VzIHRoZSBCR1Agc3BlYWtl ciBzdXBwb3NlZCB0byBiZWhhdmUgaW4gdGhpcyBjYXNlPyBUaGlzIHNob3VsZCBiZSBkZXNjcmli ZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiBOb3RlIHRoYXQgdGhpcyBpcyBub3QgYSBjYXNlIG9m IGVycm9yIGhhbmRsaW5nLCBhcyBldmVyeSBCR1Agc3BlYWtlciBpcyBiZWhhdmluZyBhcyBzcGVj aWZpZWQu4oCdDQoNClRoaXMgcHJvYmxlbSBoYXMgYmVlbiB0cnVlIGZvciB5ZWFycywgYW5kIHRo dXMgYXMgY28tY2hhaXJzIGhhZCBob3BlZCB0byBoYXZlIHRoZSBkcmFmdC1pZXRmLWJncC1leHRl bmRlZC1tZXNzYWdlcyBwYXNzZWQgeWVhcnMgYWdvLiAgIEFzIEJHUC1MUyBhdHRyaWJ1dGVzIGdy b3cgdXNlIGFuZCBpbiBudW1iZXIsIHRoZSBwb3RlbnRpYWwgb2YgZXhjZWVkaW5nIHRoZSBCR1Ag bWVzc2FnZSBsaW1pdCBpbmNyZWFzZXMuICBJdCBzZWVtcyBsaWtlIGEgZ29vZCBkaXJlY3Rpb24g dG8gcHJldmVudCBpc3N1ZXMuDQoNCkkgaG9wZSB0aGUgYXV0aG9ycyB3aWxsIGNvbW1lbnQgb24g dGhlIGNoYW5nZXMgeW91IHN1Z2dlc3RlZCB0byB0aGUgdGV4dC4NCg0KQ2hlZXJzLA0KU3VzYW4g SGFyZXMNCg0KDQoNCkZyb206IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5v LmRlY3JhZW5lQG9yYW5nZS5jb20+IFttYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbV0N ClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjksIDIwMTkgODozMyBBTQ0KVG86IFN1c2FuIEhhcmVz DQpDYzogaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0lk cl0gV0cgTGFzdCBDYWxsIG9uIEV4dGVuZWQgTWVzc2FnZSBTdXBwb3J0DQoNCkhpIFdHLA0KDQpQ bGVhc2UgZmluZCBiZWxvdyBzb21lIGNvbW1lbnRzLg0KQXMgb2YgdG9kYXksIEkgZG9u4oCZdCBi ZWxpZXZlIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyByZWFkeSB0byBiZSBwcm9ncmVzc2VkIHRvIElF U0cvUkZDLCBlc3BlY2lhbGx5IGZvciBhIGRvY3VtZW50IHVwZGF0aW5nIFJGQyA0MjcxIChjb3Jl IEJHUCBzcGVjKS4NCg0KPiBUaGUgV0cgY2hhaXJzIGludGVuZCB0byBmb3J3YXJkIHRoaXMgZHJh ZnQgdG8gdGhlIElFU0cgd2l0aCB0aGUgY3VycmVudCBsZXZlbCBvZiBpbXBsZW1lbnRhdGlvbi4N Cg0KaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdw LWV4dGVuZGVkLWltcGxlbWVudGF0aW9uczxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRyYWMuaWV0Zi5vcmclMkZ0cmFjJTJG aWRyJTJGd2lraSUyRmRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRhdGlvbnMm ZGF0YT0wMiU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJiOGE5NDNlNjE0 YjE2MzdmMzA4ZDY4NjA4ZDZjZCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdD MSU3QzAlN0M2MzY4NDM3Njk4NTkxNjUwNDMmc2RhdGE9aFhCYk9YcXd2WHF0Q1YlMkI5UGJQJTJG N0lFNldKaldVQTJib00zM0tkcyUyQmdoNCUzRCZyZXNlcnZlZD0wPiBzYXlzIDogNWENCg0KRG9l cyBub3Qgc2VuZCBFeHRlbmRlZCBNZXNzYWdlIGNhcGFiaWxpdHkNCg0KWWVzDQoNClllcw0KDQpZ ZXMNCg0KDQpJIG1heSBiZSBtaXN1bmRlcnN0YW5kaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiByZXBv cnQsIGJ1dCBteSByZWFkaW5nIG9mIHRoZSBhYm92ZSBpcyB0aGF0IG5vbmUgb2YgdGhlIHJlcG9y dGVkIGltcGxlbWVudGF0aW9ucyBzZW5kcyB0aGUgY2FwYWJpbGl0eSBoZW5jZSBubyBpbXBsZW1l bnRhdGlvbiBzdXBwb3J0cyBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMuLiBI ZXJlIHRoaXMgZG9jdW1lbnQgaXMgdXBkYXRpbmcgUkZDIDQyNzEsIHNvIGl0IGlzIG5vdCBhIG1p bm9yIGV4dGVuc2lvbiBmb3IgYSBuaWNoZSB1c2UgY2FzZS4gU28gSSBkb27igJl0IHNlZSB0aGUg YXJndW1lbnRzIGZvciBub3QgcmVxdWlyaW5nIHRoZSBJRFLigJlzIHVzdWFsIHR3byBpbnRlcm9w ZXJhYmxlIGltcGxlbWVudGF0aW9ucy4NCg0KLS0tLQ0KwqcgMQ0K4oCcIEFzIEJHUCBpcyBleHRl bmRlZCB0byBzdXBwb3J0IG5ld2VyIEFGSS9TQUZJcyBhbmQNCiAgIG5ld2VyIGNhcGFiaWxpdGll cyAoZS5nLiwgW0ktRC5pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sPGh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0 Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTI3JTIz cmVmLUktRC5pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sJmRhdGE9MDIlN0MwMSU3Q29saXZlci5i b3JjaGVydCU0MG5pc3QuZ292JTdDNDBiYjhhOTQzZTYxNGIxNjM3ZjMwOGQ2ODYwOGQ2Y2QlN0My YWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2ODQzNzY5ODU5MTY1 MDQzJnNkYXRhPXVaUyUyQmJOOXY1Y2lyMm81TDNVM2pQMnhGUGJZNFR6JTJGTm5CUGZkSDdpRGYw JTNEJnJlc2VydmVkPTA+XSksIHRoZXJlIGlzDQogICBhIG5lZWQgdG8gZXh0ZW5kIHRoZSBtYXhp bXVtIG1lc3NhZ2Ugc2l6ZSBiZXlvbmQgNDA5NiBvY3RldHMuICDigJwNCg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0yNyNz ZWN0aW9uLTE8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLWlkci1i Z3AtZXh0ZW5kZWQtbWVzc2FnZXMtMjclMjNzZWN0aW9uLTEmZGF0YT0wMiU3QzAxJTdDb2xpdmVy LmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJiOGE5NDNlNjE0YjE2MzdmMzA4ZDY4NjA4ZDZjZCU3 QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2MzY4NDM3Njk4NTkx NjUwNDMmc2RhdGE9WVZXSEFGYllSakclMkZsV1BicHcyclc4dUdRNlFYc3MzZHVmbSUyRnFIZ1J2 RHclM0QmcmVzZXJ2ZWQ9MD4NCg0KDQpbSS1ELmlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2w8aHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQt bWVzc2FnZXMtMjclMjNyZWYtSS1ELmlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2wmZGF0YT0wMiU3 QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJiOGE5NDNlNjE0YjE2MzdmMzA4 ZDY4NjA4ZDZjZCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2 MzY4NDM3Njk4NTkxNjUwNDMmc2RhdGE9dVpTJTJCYk45djVjaXIybzVMM1UzalAyeEZQYlk0VHol MkZObkJQZmRIN2lEZjAlM0QmcmVzZXJ2ZWQ9MD4gaXMgbm93IFJGQyA4MjA1ICh0aGFua3MgZm9y IHVwZGF0aW5nIHRoZSByZWZlcmVuY2UpLiBJdCBoYXMgcmVtb3ZlZCB0aGUgbm9ybWF0aXZlL2Fu eSByZWZlcmVuY2UgdG8gZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLiBTbyBw cmVzdW1hYmx5IEJHUCBTZWMgZG9lcyBub3QgbmVlZCBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5k ZWQtbWVzc2FnZXMuDQpDYW4gd2UgaGF2ZSBhbiB1cGRhdGUgb24gdGhpcz8NCkNhbiB0aGUgaW50 cm9kdWN0aW9uIG9mIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcyBiZSB1cGRh dGVkIHRvIGludHJvZHVjZSBvbiB0aGUgcmVhbCByZWFzb25zL25lZWRzPw0KDQotLS0tDQrCpzQN Cg0KwqczIHNheXMg4oCcQSBwZWVyIHdoaWNoIGRvZXMgbm90IGFkdmVydGlzZSB0aGlzIGNhcGFi aWxpdHkgTVVTVCBOT1Qgc2VuZCBCR1ANCiAgIEV4dGVuZGVkIE1lc3NhZ2VzLCBhbmQgQkdQIEV4 dGVuZGVkIE1lc3NhZ2VzIE1VU1QgTk9UIGJlIHNlbnQgdG8gaXQu4oCdDQoNCkZpbmUuIFRleHQg aW4gwqc0IHNob3VsZCBwcm9iYWJseSBiZSBhbGlnbmVkIHdpdGggdGhlIGFib3ZlIC4uZS5nLg0K DQpPTEQ6IEEgQkdQIHNwZWFrZXINCiAgIE1BWSBzZW5kIEV4dGVuZGVkIE1lc3NhZ2VzIHRvIGl0 cyBwZWVyIG9ubHkgaWYgaXQgaGFzIHJlY2VpdmVkIHRoZQ0KICAgRXh0ZW5kZWQgTWVzc2FnZSBD YXBhYmlsaXR5IGZyb20gdGhhdCBwZWVyLg0KDQpORVc6DQpBIEJHUCBzcGVha2VyDQogICBNQVkg c2VuZCBFeHRlbmRlZCBNZXNzYWdlcyB0byBpdHMgcGVlciBvbmx5IGlmIGl0IGhhcyBzZW50IGFu ZCByZWNlaXZlZCB0aGUNCiAgIEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eSB0byBhbmQgZnJv bSB0aGF0IHBlZXIuDQoNCi0tLS0NCg0K4oCcICAgQXBwbGljYXRpb25zIGdlbmVyYXRpbmcgaW5m b3JtYXRpb24gd2hpY2ggbWlnaHQgYmUgZW5jYXBzdWxhdGVkDQogICB3aXRoaW4gQkdQIG1lc3Nh Z2VzIE1VU1QgbGltaXQgdGhlIHNpemUgb2YgdGhlaXIgcGF5bG9hZCB0byB0YWtlIHRoZQ0KICAg bWF4aW11bSBtZXNzYWdlIHNpemUgaW50byBhY2NvdW50LuKAnQ0KDQpJIGRvbuKAmXQgc2VlIHdo YXQgbmV3IGJlaGF2aW9yIGlzIGJlZW4gZGVmaW5lZCBoZXJlLiBJZiB0aGVyZSBpcyBub25lLCBJ IHdvdWxkIHN1Z2dlc3QgdG8gcmVtb3ZlIHRoaXMgc2VudGVuY2UNCg0KLS0tLQ0KICAgQSBCR1Ag YW5ub3VuY2VtZW50IHdpbGwsIGluIHRoZSBub3JtYWwgY2FzZSwgcHJvcGFnYXRlIHRocm91Z2hv dXQgdGhlDQogICBCR1Agc3BlYWtpbmcgSW50ZXJuZXQ7IGFuZCB0aGVyZSB3aWxsIHVuZG91YnRl ZGx5IGJlIEJHUCBzcGVha2Vycw0KICAgd2hpY2ggZG8gbm90IGhhdmUgdGhlIEV4dGVuZGVkIE1l c3NhZ2UgY2FwYWJpbGl0eS4gIFRoZXJlZm9yZSwNCiAgIHB1dHRpbmcgYW4gYXR0cmlidXRlIHdo aWNoIGNhbiBub3QgYmUgZGVjb21wb3NlZCB0byA0MDk2IG9jdGV0cyBvcg0KICAgbGVzcyBpbiBh biBFeHRlbmRlZCBNZXNzYWdlIGlzIGEgbGlrZWx5IHBhdGggdG8gcm91dGluZyBmYWlsdXJlLg0K DQoNClRoZSBpc3N1ZSBpcyBub3Qgc3BlY2lmaWMgdG8gYXR0cmlidXRlcyBiaWdnZXIgdGhhbiA0 MDk2IG9jdGV0cywgYnV0IHRvIEJHUCBtZXNzYWdlIHdob3NlIGxlbmd0aCBpcyBiaWdnZXIgdGhh biA0MDk2LCBpcnJlc3BlY3RpdmUgb2YgdGhlIHNpemUgb2YgZWFjaCBhdHRyaWJ1dGUuDQpQbGVh c2UgZWxhYm9yYXRlIG9uIHdoYXQgeW91IG1lYW4gYnkg4oCcYW4gYXR0cmlidXRlIHdoaWNoIGNh biBub3QgYmUgZGVjb21wb3NlZCB0byA0MDk2IG9jdGV0c+KAnQ0KDQotLS0NCuKAnCAgIEl0IGlz IFJFQ09NTUVOREVEIHRoYXQgQkdQIHByb3RvY29sIGRldmVsb3BlcnMgYW5kIGltcGxlbWVudGVy cyBhcmUNCiAgIGNvbnNlcnZhdGl2ZSBpbiB0aGVpciBhcHBsaWNhdGlvbiBhbmQgdXNlIG9mIEV4 dGVuZGVkIE1lc3NhZ2VzLuKAnQ0KDQpXaGF0IGRvZXMgdGhpcyBtZWFuIGV4YWN0bHk/IFRoYXQg dGhleSBkb27igJl0IHVzZSB0aGlzIGV4dGVuc2lvbj8gVGhhdCB0aGV5IGRvbuKAmXQgdXNlIHRo aXMgZXh0ZW5zaW9uIHVubGVzcyBYWF9UTyBCRSBTUEVDSUZJRURfWFg/DQoNCi0tLQ0KICBGdXR1 cmUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMgd2lsbCBuZWVkIHRvIGRlc2NyaWJlIGhvdyB0byBo YW5kbGUNCiAgIHBlZXJzIHdoaWNoIGNhbiBvbmx5IGFjY29tbW9kYXRlIDQwOTYgb2N0ZXQgbWVz c2FnZXMuDQoNCldoeSBpcyB0aGlzIGxpbWl0ZWQgdG8gZnV0dXJlIHNwZWNpZmljYXRpb25zPyBB IHByaW9yaSwgdXNpbmcgZXhpc3RpbmcgQkdQIG1lY2hhbmlzbSAoQUZJL1NBRkksIGF0dHJpYnV0 ZXMsICogY29tbXVuaXRpZXMpIG9uZSBjb3VsZCBleGNlZWQgdGhlIHNpemUgb2YgNDA5NiBvY3Rl dHMuIEhvdyBkb2VzIHRoZSBCR1Agc3BlYWtlciBzdXBwb3NlZCB0byBiZWhhdmUgaW4gdGhpcyBj YXNlPyBUaGlzIHNob3VsZCBiZSBkZXNjcmliZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiBOb3Rl IHRoYXQgdGhpcyBpcyBub3QgYSBjYXNlIG9mIGVycm9yIGhhbmRsaW5nLCBhcyBldmVyeSBCR1Ag c3BlYWtlciBpcyBiZWhhdmluZyBhcyBzcGVjaWZpZWQuDQoNCg0KLS0tLQ0KRGVwZW5kaW5nIG9u IHRoZSBhYm92ZSBzcGVjaWZpY2F0aW9uLCBhIHNlY3Rpb24gZGVzY3JpYmluZyB0aGUgb3BlcmF0 aW9uYWwgY29uc2VxdWVuY2VzIGluIGEgbmV0d29yayAoc3VjaCBhcyB0aGUgSW50ZXJuZXQsIEJH UCBFbmFibGVkIFNlcnZpY2VTL1ZQTiBuZXR3b3JrcykgaXMgcHJvYmFibHkgbmVlZGVkLiBQb3Nz aWJsZSBjb25zZXF1ZW5jZXMgY291bGQgYmUgQkdQIE5MUkkgYmVpbmcgcmVtb3ZlZCBpbiB0aGUg bWlkZGxlIG9mIHN1Y2ggbmV0d29yaywgb3IgKGV4dGVuZGVkKSBjb21tdW5pdHkgKHN1Y2ggYXMg Um91dGUgVGFyZ2V0cykgYmVlbiByZW1vdmVkLiBCb3RoIGhhdmluZyBzaWduaWZpY2FudCBjb25z ZXF1ZW5jZXMgb24gdGhlIGF2YWlsYWJpbGl0eSBwcm92aWRlZCBieSB0aGUgbmV0d29yay4NCg0K LS0tDQrCpzQNCk9MRDogVGhlIEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eSBvbmx5IGFwcGxp ZXMgdG8gYWxsIG1lc3NhZ2VzIGV4Y2VwdCBmb3IgdGhlIE9QRU4gbWVzc2FnZS4NClByb2JhYmx5 DQpORVc6IFRoZSBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgYXBwbGllcyB0byBhbGwgbWVz c2FnZSB0eXBlcyBleGNlcHQgZm9yIHRoZSBPUEVOIG1lc3NhZ2UgKHR5cGUgMSkuDQotLS0tDQrC pzgNCg0K4oCcVGhpcyBleHRlbnNpb24gdG8gQkdQIGRvZXMgbm90IGNoYW5nZSBCR1AncyB1bmRl cmx5aW5nIHNlY3VyaXR5IGlzc3VlcyDCuw0KDQpCZWZvcmUgZXZhbHVhdGluZyB0aGlzLCBJIHRo aW5rIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGZpcnN0IHNwZWNpZmllZCBob3cgYSBCR1AgbWVzc2Fn ZXMgYmlnZ2VyIHRoYW4gNDA5NiBvY3RldHMgaXMgaGFuZGxlZCB3aGVuIGl0IG5lZWRzIHRvIGJl IHNlbnQgdG8gYSByZWNlaXZlZCBub3Qgc3VwcG9ydGluZyB0aGlzIGV4dGVuc2lvbi4NCg0KTml0 czoNCk9MRCA6IHRvIHJlZHVjZSBjb21wZXhpdHkNCk5FVyA6IHRvIHJlZHVjZSBjb21wbGV4aXR5 DQoNClRoYW5rcywNCi0tQnJ1bm8NCg0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXNhbiBIYXJlcw0KU2VudDogVHVlc2RheSwgSmFudWFyeSAy OSwgMjAxOSAxMjozMyBQTQ0KVG86IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0K U3ViamVjdDogW0lkcl0gV0cgTGFzdCBDYWxsIG9uIEV4dGVuZWQgTWVzc2FnZSBTdXBwb3J0DQoN Cg0KVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgTEMgb24gRXh0ZW5kZWQgTWVzc2FnZSBTdXBwb3J0 IGZvciBCR1AgKGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0yNykuICBZb3Ug Y2FuIGFjY2VzcyB0aGUgZHJhZnQgYXQ6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy88aHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdl cyUyRiZkYXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3QzQwYmI4YTk0 M2U2MTRiMTYzN2YzMDhkNjg2MDhkNmNkJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFk ZWMlN0MxJTdDMCU3QzYzNjg0Mzc2OTg1OTMyMTI4OSZzZGF0YT1va2pUZUxlNkRjVGFSVjJVU3ky TXk2SFhEUnludXBtWGxCMGk3Z1V3eW5BJTNEJnJlc2VydmVkPTA+DQoNClRoZSBhdXRob3JzIHNo b3VsZCBpbmRpY2F0ZSB3aGV0aGVyIHRoZXkga25vdyBvZiBhbnkgSVBSLiAgIEltcGxlbWVudGVy cyBhcmUgZW5jb3VyYWdlZCB0byB1cGRhdGUgdGhlICBpbXBsZW1lbnRhdGlvbiBkYXRhIGF0Og0K DQpodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9pZHIvd2lraS9kcmFmdC1pZXRmLWlkci1iZ3At ZXh0ZW5kZWQtaW1wbGVtZW50YXRpb25zPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdHJhYy5pZXRmLm9yZyUyRnRyYWMlMkZp ZHIlMkZ3aWtpJTJGZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLWltcGxlbWVudGF0aW9ucyZk YXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3QzQwYmI4YTk0M2U2MTRi MTYzN2YzMDhkNjg2MDhkNmNkJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0Mx JTdDMCU3QzYzNjg0Mzc2OTg1OTMyMTI4OSZzZGF0YT1Qb1J5Rm9mczA0JTJGQyUyRiUyRmdiWEwy enlFRDNTVzZNckVTcEhpSUUyZTdwNGNBJTNEJnJlc2VydmVkPTA+DQoNClRoZSBkcmFmdCBwcm92 aWRlcyBhIG1lYW5zIGZvciBleHBhbmRpbmcgdGhlIEJHUCBtZXNzYWdlIHRvIDY1NTM1IG9jdGV0 cyBmb3IgYWxsIG1lc3NhZ2VzIGV4Y2VwdCBPUEVOIG1lc3NhZ2VzLiAgQkdQIG1lc3NhZ2Ugc3Bh Y2UgaXMgcnVubmluZyBzaG9ydCBmb3IgYWxsIG9mIHRoZSBwb3RlbnRpYWwgYXR0cmlidXRlcyBv ciBhZGRpdGlvbnMgcHJvcG9zZWQgYnkgQkdQLUxTIGZlYXR1cmVzLg0KDQpUaGUgV0cgY2hhaXJz IGludGVuZCB0byBmb3J3YXJkIHRoaXMgZHJhZnQgdG8gdGhlIElFU0cgd2l0aCB0aGUgY3VycmVu dCBsZXZlbCBvZiBpbXBsZW1lbnRhdGlvbi4NCg0KQXMgeW91IGNvbW1lbnQgb24gdGhlIGRyYWZ0 LCBwbGVhc2UgY29uc2lkZXIgaWY6IGEpIHRoZSB0ZWNobm9sb2d5IGlzIG1hdHVyZSwgYikgdGhl IGFkZGl0aW9uYWwgc3BhY2UgaW4gYSBCR1AgbWVzc2FnZSB3b3VsZCBiZSBoZWxwZnVsIGZvciB0 aG9zZSBkZXBsb3lpbmcgQkdQLUxTIG9yIFNSLCBhbmQgYykgaWYgdGhlIHNwZWNpZmljYXRpb24g aXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLg0KDQpTdWUgSGFyZXMgKFdHIENoYWlyLCBTaGVwaGVy ZCkNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsg eW91Lg0K --_000_ba5ddfd47a7c42db8e3ad1fba72fd18aXCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5Q cmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KcC5QcmZvcm1hdEhUTUwsIGxpLlByZm9y bWF0SFRNTCwgZGl2LlByZm9ybWF0SFRNTA0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOp IEhUTUwiOw0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5IVE1MLCBsaS5IVE1MLCBkaXYu SFRNTA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8iOw0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE 6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJs YWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVt YWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMzDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 IzcwMzBBMDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+QkdQU2VjIGRyb3Bw ZWQgdGhlIHJlcXVpcmVtZW50IGZvciBleHRlbmRlZCBtZXNzYWdlcyBiZWNhdXNlIHRoZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3 MDMwQTAiPnNpZ25hdHVyZSB3YXMgY2hhbmdlZCBmcm9tIFJTQS0yMDQ4ICgyNTYgYnl0ZSBzaWcp IHRvIEVDRFNBIFAtMjU2ICg2NCBieXRlIHNpZykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+PGEgaHJlZj0iaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zaWRyL0xSSFB1TzVNRjB1LXZXdWhOQVZl Vk5fOGZJVSI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zaWRyL0xSSFB1 TzVNRjB1LXZXdWhOQVZlVk5fOGZJVTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5U aGVyZSBpcyBubyBtZW50aW9uIG9mIGV4dGVuZGVkIG1lc3NhZ2VzIGluDQo8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODIwNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzgyMDU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+QWxsIG1lbnRpb24gb2YgaXQgd2FzIHN0cnVjayBv dXQgaW46PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzcwMzBBMCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbC0yMy50eHQiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2wt MjMudHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiM3MDMwQTAiPkpha29iLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IElkciAmbHQ7aWRyLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkRvbmdqaWUgKEppbW15KTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDEsIDIw MTkgMTA6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IFN1c2FuIEhhcmVzICZsdDtzaGFyZXNAbmR6aC5j b20mZ3Q7OyAnQm9yY2hlcnQsIE9saXZlciAoRmVkKScgJmx0O29saXZlci5ib3JjaGVydD00MG5p c3QuZ292QGRtYXJjLmlldGYub3JnJmd0OzsgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTsgJ0Jv cmNoZXJ0LCBPbGl2ZXIgKEZlZCknICZsdDtvbGl2ZXIuYm9yY2hlcnRAbmlzdC5nb3YmZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBpZHJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJd IFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5IaSBTdWUsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoYW5rcyBmb3IgdXBkYXRpbmcgdGhlIGltcGxlbWVudGF0aW9uIHJlcG9ydC4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TXkgdW5kZXJzdGFuZGluZyB3YXMg dGhhdCBidWxsZXQgNCB3YXMgdG8gY292ZXIgdGhlIGJlaGF2aW9yIG9mIHNlY3Rpb24gNSBwYXJh Z3JhcGggMSwgYnVsbGV0IDUgd2FzIHRvIGNvdmVyIHRoZSBiZWhhdmlvciBvZiBzZWN0aW9uIDUg cGFyYWdyYXBoIDIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5C dXQgYWZ0ZXIgcmVyZWFkaW5nIHNlY3Rpb24gNSwgSSByZWFsaXplIHRoYXQgYm90aCBwYXJhZ3Jh cGggMSBhbmQgMiBhcmUgdGFsa2luZyBhYm91dCB0aGUgYmVoYXZpb3Igb2YgYSBCR1Agc3BlYWtl ciB3aGljaCBkb2VzIG5vdCBhZHZlcnRpc2UgdGhlIGV4dGVuZGVkIG1lc3NhZ2UNCiBjYXBhYmls aXR5IHRvIGl0cyBwZWVyLCBzbyBwZXJoYXBzIGJ1bGxldHMgNCBhbmQgNSBpbiB0aGUgaW1wbGVt ZW50YXRpb24gcmVwb3J0IGNvdWxkIGJlIG1lcmdlZCBhcyBiZWxvdzoNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+NC4gV2hlbiByZWNlaXZlcyBhbiBleHRlbmRl ZCBtZXNzYWdlIHdpdGhvdXQgYWR2ZXJ0aXNpbmcgdGhlIEJHUCBFeHRlbmRlZCBNZXNzYWdlIENh cGFiaWxpdHkgdG8gdGhpcyBwZWVyIChFcnJvciBIYW5kbGluZykuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjRhLiBBY2NlcHRzIHRoZSBleHRlbmRlZCBtZXNzYWdlIGlmIHRoZSBCR1Agc3BlYWtlciBpcyBh YmxlIHRvIHByb2Nlc3MgZXh0ZW5kZWQgbWVzc2FnZSAoYnV0IHdhcyBjb25maWd1cmVkIG5vdCB0 byBhZHZlcnRpc2UgdGhlIGNhcGFiaWxpdHkpICZuYnNwOyZuYnNwO1tTZWN0aW9uIDUsIHBhcmFn cmFwaA0KIDEgTUFZXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj40Yi4gRG9lcyBub3QgYWNjZXB0IHRoZSBl eHRlbmRlZCBtZXNzYWdlLCBmb2xsb3dzIFJGQzQyNzEgaGFuZGxpbmcgYW5kIHNlbmRzIEJhZCBN ZXNzYWdlIExlbmd0aCBOb3RpZmljYXRpb24gW1NlY3Rpb24gNSwgcGFyYWdyYXBoIDEgU0hPVUxE IE5PVCwgYW5kIHBhcmFncmFwaA0KIDIgTVVTVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkhvcGUgdGhpcyBoZWxwcyB0byByZWR1Y2UgdGhlIGNvbmZ1c2lvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SmllPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IFN1c2FuIEhhcmVzIFs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5tYWlsdG86c2hh cmVzQG5kemguY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDAx LCAyMDE5IDExOjAzIFBNPGJyPg0KPGI+VG86PC9iPiBEb25namllIChKaW1teSkgJmx0OzxhIGhy ZWY9Im1haWx0bzpqaWUuZG9uZ0BodWF3ZWkuY29tIj5qaWUuZG9uZ0BodWF3ZWkuY29tPC9hPiZn dDs7ICdCb3JjaGVydCwgT2xpdmVyIChGZWQpJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9saXZlci5i b3JjaGVydD00MG5pc3QuZ292QGRtYXJjLmlldGYub3JnIj5vbGl2ZXIuYm9yY2hlcnQ9NDBuaXN0 LmdvdkBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb20iPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+OyAnQm9yY2hlcnQs IE9saXZlciAoRmVkKScgJmx0OzxhIGhyZWY9Im1haWx0bzpvbGl2ZXIuYm9yY2hlcnRAbmlzdC5n b3YiPm9saXZlci5ib3JjaGVydEBuaXN0LmdvdjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBo cmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJFOiBbSWRyXSBXRyBMYXN0IENhbGwgb24gRXh0ZW5lZCBNZXNzYWdlIFN1cHBvcnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SkllLCBCcnVubyBhbmQgT2xpdmVyOg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgZm9yIHlvdXIgaW5wdXQu Jm5ic3A7Jm5ic3A7IFlvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBlcnJvciBoYW5kbGluZyBiZWhh dmlvciB3YXMgdW5jbGVhciBiYXNlZCBvbiB0aGUgcXVlc3Rpb25zIGluIHRoZSBjaGFydC4gJm5i c3A7Jm5ic3A7VGhlIHB1cnBvc2Ugb2YgdGhlIGNoYXJ0IGlzIHRvDQogcHJvdmlkZSBvdGhlciBC R1AgV0dzIChCZXNzLCBTUFJJTkcsIExTVlIpIGEgY2xlYXIgaW5kaWNhdGlvbiBvZiBjaGFuZ2Vz IHRvIHRoZSBiYXNlIEJHUCBzcGVjaWZpY2F0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5J4oCZdmUgcmVmb3JtYXR0ZWQgc2VjdGlvbnMgNCBhbmQgNSBv ZiB0aGUgY2hhcnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlRvIHNlY3Rpb24gNCBJ4oCZdmUgYWRkZWQ6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+NGMm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgRG9lcyBzZW5kIEV4dGVuZGVkIE1lc3NhZ2UgJm5ic3A7LSB3aXRoIGEgeWVzIGZy b20gYWxsIGltcGxlbWVudGF0aW9ucyAoYmFzZWQgb24gdGhlaXIgZW1haWwpDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gNSwgSeKAmXZlIGFsdGVy IHRvIGJlOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXJyb3Ig aGFuZGluZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjVhJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFjY2VwdHMgRXh0ZW5kZWQg bWVzc2FnZSB3aXRob3V0IHJlY2VpdmluZw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO0JHUCBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgW1NlY3Rpb24gNSBwYXJh Z3JhcGggMSBNQVldPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjViJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElm IHJlY2VpdmVzIEV4dGVuZGVkIE1lc3NhZ2Ugd2l0aG91dCBCR1AgZXh0ZW5kZWQgbWVzc2FnZSBz dXBwb3J0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Zm9sbG93cyBSRkM0Mjcx IGhhbmRsaW5nIGFuZCBzZW5kcyBCYWQgbWVzc2FnZSBsZW5ndGggTm90aWZpY2F0aW9uDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7W3NlY3Rpb24gNSBwYXJhZ3JhcGggMiBNVVNU XQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbGl2ZXIg4oCT IGlmIHlvdSB3b3VsZCByZWFkIHRoZSBjdXJyZW50IHRleHQgYW5kIGxldCBtZSBrbm93IHRoZSB1 cGRhdGVkIG1lc3NhZ2UuICZuYnNwO0kgYmVsaWV2ZSB0aGUgYW5zd2VyIGZvciBhbGwgMyBpbXBs ZW1lbnRhdGlvbnMgaXMg4oCceWVz4oCdIGR1ZSB0byA0Yi4mbmJzcDsmbmJzcDsgUGxlYXNlDQog bGV0IG1lIGtub3cgYW5kIEkgd2lsbCB1cGRhdGUgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBjaGFy dC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UbyBmb2xsb3ct dXAgb24gSmll4oCZcyBjb21tZW50cywgdGhlIHRleHQgZGlkIG5vdCBhY2N1cmF0ZWx5IHJlcHJl c2VudCB0aGUgZXJyb3IgaGFuZGxpbmcuJm5ic3A7ICZuYnNwO1NlY3Rpb24gNSwgcGFyYWdyYXBo IDEgaGFzIGEg4oCcU0hPVUxEIE5PVOKAnSBtb2RpZmllZCBieSBhIOKAnE1BWeKAnSwgd2hpY2gN CiByZXN1bHRzIGluIHNpbXBseSBhIOKAnE1BWeKAnS4mbmJzcDsgJm5ic3A7Rm9yIHJlYWRhYmls aXR5LCBJIHRoaW5rIHRoZSDigJxTSE9VTEQgTk9U4oCdIHByb3ZpZGVzIHVzZWZ1bCBpbmZvcm1h dGlvbiZuYnNwOyB0byB0aGUgaW1wbGVtZW50ZXIsICZuYnNwO2J1dCBpdCBjYW5ub3QgYmUgdGVz dGVkIGFjY3VyYXRlbHkgd2hlbiBjb21iaW5lZCB3aXRoIHRoZSDigJxNQVnigJ0uJm5ic3A7ICZu YnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TGV0 IG1lIGdpdmUgeW91IGFuIGV4YW1wbGUgb2YgdGhhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoZSBwZWVyIGRpZCBub3Qgc2VuZCBhIEJHUCBFeHRlbmRl ZCBNZXNzYWdlIGNhcGFiaWxpdHksIGFuZCBpdCBhY2NlcHRzIHRoZSBleHRlbmRlZCBtZXNzYWdl ICh3aXRoIGEgbGVuZ3RoIG9mIDEwLDAwMCBieXRlcyksIGl0IGNvdWxkDQogaGF2ZSBhIGxpYmVy YWwgcG9saWN5IG9mIE1BWSBhcyBhIGRlZmF1bHQgaW4gdGhlIGltcGxlbWVudGF0aW9uLiAmbmJz cDsmbmJzcDtUaGUg4oCcb24td2lyZeKAnSBvYnNlcnZhdGlvbnMgY2Fubm90IHRlbGwg4oCTIG9u bHkgdGhlIGltcGxlbWVudGF0aW9u4oCZcyBwb2xpY3kgKGRlZmF1bHQgJiM0MzsgY29uZmlndXJl ZCkuJm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkkgYWxzbyBicm9rZSBvdXQgdGhlIG1hbmFnZW1lbnQgaW5mb3JtYXRpb24gYXdh eSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uIGluZm9ybWF0aW9uLiZuYnNwOw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TdWUgSGFyZXMgJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gRG9uZ2ppZSAoSmltbXkpIFs8YSBocmVm PSJtYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbSI+bWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb208 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAzMCwgMjAxOSA4OjUz IFBNPGJyPg0KPGI+VG86PC9iPiBCb3JjaGVydCwgT2xpdmVyIChGZWQpOyBTdXNhbiBIYXJlczsg PGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPg0KYnJ1bm8uZGVjcmFl bmVAb3JhbmdlLmNvbTwvYT47IEJvcmNoZXJ0LCBPbGl2ZXIgKEZlZCk8YnI+DQo8Yj5DYzo8L2I+ IDxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3Vw cG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBPbGl2ZXIsIEJydW5vIGFuZCBTdWUsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UbyBteSB1bmRlcnN0YW5kaW5n LCBidWxsZXQgNS81YS81YiBpbiB0aGUgaW1wbGVtZW50YXRpb24gcmVwb3J0IGlzIGNvcnJlc3Bv bmRpbmcgdG8gdGhlIHNlY29uZCBwYXJhZ3JhcGggaW4gc2VjdGlvbiA1IOKAnEVycm9yIEhhbmRs aW5n4oCdOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+QSBCR1Agc3BlYWtlciB0aGF0IGRvZXMgbm90IGFkdmVydGlz ZSB0aGUgQkdQIEV4dGVuZGVkIE1lc3NhZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyBjYXBhYmlsaXR5IG1pZ2h0IGFsc28gZ2VudWluZWx5IG5vdCBzdXBwb3J0IEV4dGVuZGVkIE1l c3NhZ2VzLiZuYnNwOyBTdWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBhIHNwZWFr ZXIgTVVTVCBmb2xsb3cgdGhlIGVycm9yIGhhbmRsaW5nIHByb2NlZHVyZXMgb2YgW1JGQzQyNzFd IGlmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBpdCByZWNlaXZlcyBhbiBFeHRlbmRl ZCBNZXNzYWdlLiZuYnNwOyBTaW1pbGFybHksIGFueSBzcGVha2VyIHRoYXQgdHJlYXRzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBhbiBpbXByb3BlciBFeHRlbmRlZCBNZXNzYWdlIGFz IGEgZmF0YWwgZXJyb3IsIE1VU1QgdHJlYXQgaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7IHNpbWlsYXJseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRodXMgaXQgaXMgdG8gZGVzY3JpYmUgdGhlIGVycm9yIGhhbmRsaW5nIGJlaGF2aW9yIG9mIGFu IGltcGxlbWVudGF0aW9uIHZlcnNpb24gd2hpY2ggZG9lcyBub3Qgc3VwcG9ydCBleHRlbmRlZCBt ZXNzYWdlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGls ZSBJIGFncmVlIHRoaXMgY291bGQgYmUgbWlzbGVhZGluZyBmb3IgYSByZXBvcnQgb2YgaW1wbGVt ZW50YXRpb24gd2hpY2ggc3VwcG9ydHMgZXh0ZW5kZWQgbWVzc2FnZSBjYXBhYmlsaXR5LCBtYXli ZSBpdCBjb3VsZCBiZSB1c2VkIHRvIHZlcmlmeSB0aGUgYmVoYXZpb3INCiBvZiBhbiBvbGQgdmVy c2lvbiB3aGljaCBkb2VzIG5vdCBzdXBwb3J0IHRoaXMgY2FwYWJpbGl0eT88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SmllPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gSWRyIFs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkJvcmNoZXJ0LCBPbGl2ZXIgKEZlZCk8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBK YW51YXJ5IDMwLCAyMDE5IDQ6MzUgQU08YnI+DQo8Yj5Ubzo8L2I+IFN1c2FuIEhhcmVzICZsdDs8 YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0Ozsg PGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPg0KYnJ1bm8uZGVjcmFl bmVAb3JhbmdlLmNvbTwvYT47IEJvcmNoZXJ0LCBPbGl2ZXIgKEZlZCkgJmx0OzxhIGhyZWY9Im1h aWx0bzpvbGl2ZXIuYm9yY2hlcnRAbmlzdC5nb3YiPm9saXZlci5ib3JjaGVydEBuaXN0Lmdvdjwv YT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWRyXSBXRyBMYXN0IENhbGwg b24gRXh0ZW5lZCBNZXNzYWdlIFN1cHBvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJydW5vIGFuZCBTdXNhbiw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+SSBjYW5ub3Qgc3BlYWsgZm9yIHRoZSBFeGFCR1AgSW1wbGVtZW50YXRpb24gYnV0 IGZvciBCR1BTRUMtSU8gYW5kIFF1YWdnYVNSeC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYmVsaWV2ZSB3aGVuIEkgY29tcGls ZWQgdGhlIHJlcG9ydCwgSSBtaXMtcmVhZCA1YSBhbmQgb3Zlcmxvb2tlZCB0aGUg4oCcbm904oCd IGFuZCByZWFkIGluc3RlYWQ6IOKAnERvZXMgc2VuZCBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxp dHnigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5UaGVyZWZvcmUgdGhlIGltcGxlbWVudGF0aW9uIHJlcG9ydCBmb3Igc2VjdGlv biA1YSBtdXN0IGJlIGNvcnJlY3RlZCBmcm9tIOKAnFllc+KAnSBpbnRvIOKAnE5v4oCdIGZvciBi b3RoIEJHUFNFQy1JTyBhbmQgUXVhZ2dhU1J4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJHUFNFQy1JTyBhbmQg UXVhZ2dhU1J4LCBib3RoIGRvIHNlbmQgdGhlIGV4dGVuZGVkIG1lc3NhZ2UgY2FwYWJpbGl0eSBp ZiBzbyBjb25maWd1cmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+SSBqdXN0IGNoZWNrZWQgdGhlIGNvZGUgYW5kIHJ1biBpdCBh Z2Fpbi4gSSBjb3B5L3Bhc3RlZCB0aGUgcmVsZXZhbnQgb3V0cHV0IGdlbmVyYXRlZCBieSBCR1BT RUMtSU8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9saXZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tLS0tLSZuYnNwOyBv dXRwdXQgb2YgQkdQU0VDLUlPJm5ic3A7IC0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+77u/Li9iZ3Bz ZWNpbyAtZiBiZ3BzZWNpby50ZXN0LmNmZy5xc3J4DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlN0YXJ0aW5nIGJncHNlY2lvIDAu Mi4wLjI1Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5TZW5kOiZuYnNwOyAoT3BlbiBtZXNzYWdlIHNlbmQgZnJvbSBCR1BTRUMt SU8gdG8gUXVhZ2dhU1J4KQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PUEVOIE1lc3NhZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyAmIzQzOy0tbWFy a2VyOiBGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCmPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLU9wdGlvbmFsIFBhcmFtZXRlcjogQ2FwYWJpbGl0eTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLVR5cGU6IENhcGFiaWxp dHkgKDIpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tTGVuZ3Ro OiAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tQ2FwYWJpbGl0 eTogRXh0ZW5kZWQgbWVzc2FnZSBzdXBwb3J0IGNhcGFiaWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1UeXBlOiBFeHRlbmRl ZCBtZXNzYWdlIHN1cHBvcnQgY2FwYWJpbGl0eSAoNik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1MZW5ndGg6IDA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKApjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5SZWNlaXZlZDogKE9wZW4gbWVzc2FnZSBzZW5kIGZyb20gUXVhZ2dhU1J4 IGFuZCByZWNlaXZlZCBieSBCR1BTRUMtSU8pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PUEVOIE1lc3NhZ2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyAm IzQzOy0tbWFya2VyOiBGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCmPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLU9wdGlvbmFsIFBhcmFtZXRlcjogQ2Fw YWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7LS1UeXBlOiBDYXBhYmlsaXR5ICgyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1MZW5ndGg6IDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tQ2FwYWJpbGl0eTogRXh0ZW5kZWQgbWVzc2Fn ZSBzdXBwb3J0IGNhcGFiaWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tVHlwZTogRXh0ZW5kZWQgbWVzc2Fn ZSBzdXBwb3J0IGNhcGFiaWxpdHkgKDYpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLUxlbmd0aDogMDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QkdQ LXJlY2VpdmVyIHRocmVhZCBjcmVhdGVkITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PklkciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+VHVlc2RheSwgSmFudWFyeSAyOSwgMjAxOSBhdCAxMTo0MyBBTTxicj4NCjxiPlRv OiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPmJy dW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1 bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJA aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0lkcl0gV0cgTGFzdCBD YWxsIG9uIEV4dGVuZWQgTWVzc2FnZSBTdXBwb3J0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5CcnVubzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo YW5rIHlvdSBmb3IgeW91ciBjb21tZW50cyBvbiB0aGlzIHRvcGljIOKAkyBhcyBJIHRoaW5rDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZGlkIHJlY2VpdmUgcmVwb3J0cyBwcml2YXRlbHkgdGhh dCB3ZSBoYXZlIDEgZnVsbCBpbXBsZW1lbnRhdGlvbnMgb2YgZHJhZnQtaWV0Zi1pZHItYmdwLWV4 dGVuZGVkLW1lc3NhZ2VzIG9mZiBsaXN0IHdoaWNoIGlzIG5vdCBsaXN0ZWQgaW4NCiB0aGlzIHJl cG9ydC4gJm5ic3A7Jm5ic3A7SSBob3BlIHRob3NlIGltcGxlbWVudGVycyB3aWxsIHZvbHVudGVl ciB0aGlzIGluZm9ybWF0aW9uIG9uIHRoZSBsaXN0LiAmbmJzcDsmbmJzcDtJZiBub3QsIEkgd2ls bCBzaGFyZSB0aGlzIGluZm9ybWF0aW9uIHdpdGggQWx2YXJvIGFuZCB0aGUgSUVTRy4mbmJzcDsg Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgU0lEUiB3b3JrIGRpZCBkZWZpbmUgZHJh ZnQtaWV0Zi1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMgYXMgYSByZXF1aXJlbWVudCBhbmQgb25seSBt b3ZlZCB0byBub3Qgc3BlY2lmeWluZyBpdCB3aGVuIHdlIGNvdWxkIG5vdCBxdWlja2x5IHBhc3MN CiB0aGlzIHRocm91Z2ggV0cgTEMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHJlYWwgbmVl ZHMgYXJlIGEgZ3Jvd2luZyBCR1AtTFMgdGhhdCBtYXkgcnVuIG91dCBvZiBCR1AgbWVzc2FnZSBz cGFjZS4mbmJzcDsgQXMgbXkgcHJldmlvdXMgZW1haWwgdG8gSURSIGluZGljYXRlcywgSSB3YXMg aG9waW5nIHRoaXMgaGFuZGxlcw0KIGFuIEJHUCBtZXNzYWdlIHdob3NlIGxlbmd0aCBpcyBiaWdn ZXIgdGhhbiA0MDk2IGJ5dGVzLiZuYnNwOyAmbmJzcDtUaGFuayB5b3UgZm9yIHRoZSBjb3JyZWN0 aW9uIG9mOg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+4oCcVGhlIGlzc3VlIGlzIG5vdCBzcGVjaWZp YyB0byBhdHRyaWJ1dGVzIGJpZ2dlciB0aGFuIDQwOTYgb2N0ZXRzLCBidXQgdG8gQkdQIG1lc3Nh Z2Ugd2hvc2UgbGVuZ3RoIGlzIGJpZ2dlciB0aGFuIDQwOTYsIGlycmVzcGVjdGl2ZSBvZiB0aGUg c2l6ZQ0KIG9mIGVhY2ggYXR0cmlidXRlLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkFzIHRvIHlvdXIgY29tbWVudDoNCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij7igJxXaHkgaXMgdGhpcyBsaW1pdGVkIHRvIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucz8gQSBwcmlv cmksIHVzaW5nIGV4aXN0aW5nIEJHUCBtZWNoYW5pc20gKEFGSS9TQUZJLCBhdHRyaWJ1dGVzLCAq IGNvbW11bml0aWVzKSBvbmUgY291bGQgZXhjZWVkIHRoZSBzaXplIG9mIDQwOTYNCiBvY3RldHMu IEhvdyBkb2VzIHRoZSBCR1Agc3BlYWtlciBzdXBwb3NlZCB0byBiZWhhdmUgaW4gdGhpcyBjYXNl PyBUaGlzIHNob3VsZCBiZSBkZXNjcmliZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiBOb3RlIHRo YXQgdGhpcyBpcyBub3QgYSBjYXNlIG9mIGVycm9yIGhhbmRsaW5nLCBhcyBldmVyeSBCR1Agc3Bl YWtlciBpcyBiZWhhdmluZyBhcyBzcGVjaWZpZWQu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgcHJvYmxlbSBoYXMgYmVlbiB0cnVlIGZv ciB5ZWFycywgYW5kIHRodXMgYXMgY28tY2hhaXJzIGhhZCBob3BlZCB0byBoYXZlIHRoZSBkcmFm dC1pZXRmLWJncC1leHRlbmRlZC1tZXNzYWdlcyBwYXNzZWQgeWVhcnMgYWdvLiAmbmJzcDsmbmJz cDtBcyBCR1AtTFMgYXR0cmlidXRlcw0KIGdyb3cgdXNlIGFuZCBpbiBudW1iZXIsIHRoZSBwb3Rl bnRpYWwgb2YgZXhjZWVkaW5nIHRoZSBCR1AgbWVzc2FnZSBsaW1pdCBpbmNyZWFzZXMuICZuYnNw O0l0IHNlZW1zIGxpa2UgYSBnb29kIGRpcmVjdGlvbiB0byBwcmV2ZW50IGlzc3Vlcy4NCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGhvcGUgdGhl IGF1dGhvcnMgd2lsbCBjb21tZW50IG9uIHRoZSBjaGFuZ2VzIHlvdSBzdWdnZXN0ZWQgdG8gdGhl IHRleHQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Q2hlZXJzLA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdXNhbiBIYXJlcw0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+DQo8YSBocmVmPSJt YWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bTwvYT4gWzxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5tYWlsdG86 YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh eSwgSmFudWFyeSAyOSwgMjAxOSA4OjMzIEFNPGJyPg0KPGI+VG86PC9iPiBTdXNhbiBIYXJlczxi cj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0lkcl0gV0cgTGFzdCBDYWxsIG9uIEV4dGVu ZWQgTWVzc2FnZSBTdXBwb3J0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5IaSBXRyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlBsZWFzZSBmaW5kIGJlbG93IHNvbWUgY29tbWVu dHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkFzIG9mIHRvZGF5LCBJIGRvbuKAmXQgYmVs aWV2ZSB0aGlzIHNwZWNpZmljYXRpb24gaXMgcmVhZHkgdG8gYmUgcHJvZ3Jlc3NlZCB0byBJRVNH L1JGQywgZXNwZWNpYWxseSBmb3IgYSBkb2N1bWVudCB1cGRhdGluZyBSRkMgNDI3MSAoY29yZSBC R1Agc3BlYykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyBUaGUgV0cgY2hhaXJzIGludGVuZCB0byBmb3J3YXJk IHRoaXMgZHJhZnQgdG8gdGhlIElFU0cgd2l0aCB0aGUgY3VycmVudCBsZXZlbCBvZiBpbXBsZW1l bnRhdGlvbi4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs cGFkZGluZz0iMCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHRib2R5Pg0KPHRyPg0KPHRk IHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiAuLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0cmFjLmlldGYub3JnJTJGdHJh YyUyRmlkciUyRndpa2klMkZkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtaW1wbGVtZW50YXRp b25zJmFtcDtkYXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3QzQwYmI4 YTk0M2U2MTRiMTYzN2YzMDhkNjg2MDhkNmNkJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVj NjFkZWMlN0MxJTdDMCU3QzYzNjg0Mzc2OTg1OTE2NTA0MyZhbXA7c2RhdGE9aFhCYk9YcXd2WHF0 Q1YlMkI5UGJQJTJGN0lFNldKaldVQTJib00zM0tkcyUyQmdoNCUzRCZhbXA7cmVzZXJ2ZWQ9MCI+ aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4 dGVuZGVkLWltcGxlbWVudGF0aW9uczwvYT4NCiBzYXlzIDogPC9zcGFuPjVhIDxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIG5vdCBzZW5kIEV4dGVuZGVkIE1lc3NhZ2UgY2Fw YWJpbGl0eSA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQg Ljc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzIDxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiAuLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+WWVzIDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgbWF5IGJlIG1p c3VuZGVyc3RhbmRpbmcgdGhlIGltcGxlbWVudGF0aW9uIHJlcG9ydCwgYnV0IG15IHJlYWRpbmcg b2YgdGhlIGFib3ZlIGlzIHRoYXQgbm9uZSBvZiB0aGUgcmVwb3J0ZWQgaW1wbGVtZW50YXRpb25z IHNlbmRzIHRoZSBjYXBhYmlsaXR5IGhlbmNlDQogbm8gaW1wbGVtZW50YXRpb24gc3VwcG9ydHMg ZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLi4gSGVyZSB0aGlzIGRvY3VtZW50 IGlzIHVwZGF0aW5nIFJGQyA0MjcxLCBzbyBpdCBpcyBub3QgYSBtaW5vciBleHRlbnNpb24gZm9y IGEgbmljaGUgdXNlIGNhc2UuIFNvIEkgZG9u4oCZdCBzZWUgdGhlIGFyZ3VtZW50cyBmb3Igbm90 IHJlcXVpcmluZyB0aGUgSURS4oCZcyB1c3VhbCB0d28gaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRh dGlvbnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pi0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+wqcgMTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+4oCcIEFzIEJHUCBpcyBleHRlbmRlZCB0byBzdXBwb3J0IG5ld2VyIEFGSS9TQUZJcyBhbmQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBuZXdlciBjYXBhYmlsaXRpZXMgKGUu Zy4sIFs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmll dGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0yNyUy M3JlZi1JLUQuaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbCZhbXA7ZGF0YT0wMiU3QzAxJTdDb2xp dmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJiOGE5NDNlNjE0YjE2MzdmMzA4ZDY4NjA4ZDZj ZCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2MzY4NDM3Njk4 NTkxNjUwNDMmYW1wO3NkYXRhPXVaUyUyQmJOOXY1Y2lyMm81TDNVM2pQMnhGUGJZNFR6JTJGTm5C UGZkSDdpRGYwJTNEJmFtcDtyZXNlcnZlZD0wIiB0aXRsZT0iJnF1b3Q7QkdQU0VDIFByb3RvY29s IFNwZWNpZmljYXRpb24mcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5JLUQuaWV0Zi1zaWRyLWJn cHNlYy1wcm90b2NvbDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dKSwNCiB0aGVyZSBpczwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGEgbmVlZCB0byBleHRlbmQgdGhlIG1h eGltdW0gbWVzc2FnZSBzaXplIGJleW9uZCA0MDk2IG9jdGV0cy4mbmJzcDsg4oCcPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1l c3NhZ2VzLTI3JTIzc2VjdGlvbi0xJmFtcDtkYXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQl NDBuaXN0LmdvdiU3QzQwYmI4YTk0M2U2MTRiMTYzN2YzMDhkNjg2MDhkNmNkJTdDMmFiNWQ4MmZk OGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjg0Mzc2OTg1OTE2NTA0MyZhbXA7 c2RhdGE9WVZXSEFGYllSakclMkZsV1BicHcyclc4dUdRNlFYc3MzZHVmbSUyRnFIZ1J2RHclM0Qm YW1wO3Jlc2VydmVkPTAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlk ci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMjcjc2VjdGlvbi0xPC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+Wzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQt bWVzc2FnZXMtMjclMjNyZWYtSS1ELmlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2wmYW1wO2RhdGE9 MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDNDBiYjhhOTQzZTYxNGIxNjM3 ZjMwOGQ2ODYwOGQ2Y2QlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0Mw JTdDNjM2ODQzNzY5ODU5MTY1MDQzJmFtcDtzZGF0YT11WlMlMkJiTjl2NWNpcjJvNUwzVTNqUDJ4 RlBiWTRUeiUyRk5uQlBmZEg3aURmMCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGl0bGU9IiZxdW90O0JH UFNFQyBQcm90b2NvbCBTcGVjaWZpY2F0aW9uJnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+SS1E LmlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2w8L3NwYW4+PC9hPg0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPmlzIG5vdyBSRkMgODIwNSAodGhhbmtzIGZvciB1cGRhdGluZyB0aGUgcmVmZXJlbmNlKS4g SXQgaGFzIHJlbW92ZWQgdGhlIG5vcm1hdGl2ZS9hbnkgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYt aWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy4gU28gcHJlc3VtYWJseSBCR1AgU2VjIGRvZXMgbm90 IG5lZWQgZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5DYW4gd2UgaGF2ZSBhbiB1cGRhdGUgb24gdGhpcz88L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+Q2FuIHRoZSBpbnRyb2R1Y3Rpb24gb2YNCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+ZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzIGJlIHVwZGF0ZWQg dG8gaW50cm9kdWNlIG9uIHRoZSByZWFsIHJlYXNvbnMvbmVlZHM/PC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pi0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+wqc0PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+wqczIHNheXMg 4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BIHBlZXIgd2hpY2ggZG9lcyBub3QgYWR2ZXJ0aXNlIHRoaXMg Y2FwYWJpbGl0eSBNVVNUIE5PVCBzZW5kIEJHUDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyAmbmJzcDtFeHRlbmRlZCBNZXNzYWdlcywgYW5kIEJHUCBFeHRlbmRlZCBNZXNzYWdlcyBN VVNUIE5PVCBiZSBzZW50IHRvIGl0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj7igJ08L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkZpbmUuIFRleHQgaW4gwqc0IHNob3VsZCBwcm9iYWJseSBiZSBh bGlnbmVkIHdpdGggdGhlIGFib3ZlIC4uZS5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9MRDog PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5BIEJHUCBzcGVha2VyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IE1BWSBzZW5kIEV4dGVuZGVkIE1lc3NhZ2VzIHRvIGl0cyBwZWVyIG9ubHkg aWYgaXQgaGFzIHJlY2VpdmVkIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eSBmcm9tIHRoYXQgcGVlci48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPk5FVzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkEgQkdQIHNwZWFrZXI8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBNQVkgc2VuZCBFeHRlbmRlZCBNZXNz YWdlcyB0byBpdHMgcGVlciBvbmx5IGlmIGl0IGhhcyBzZW50IGFuZCByZWNlaXZlZCB0aGU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxp dHkgdG8gYW5kIGZyb20gdGhhdCBwZWVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+4oCcPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQXBwbGljYXRpb25zIGdlbmVyYXRpbmcgaW5mb3JtYXRp b24gd2hpY2ggbWlnaHQgYmUgZW5jYXBzdWxhdGVkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHdpdGhpbiBCR1AgbWVzc2FnZXMgTVVTVCBsaW1pdCB0aGUgc2l6ZSBvZiB0 aGVpciBwYXlsb2FkIHRvIHRha2UgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgbWF4aW11bSBtZXNzYWdlIHNpemUgaW50byBhY2NvdW50LuKAnTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBzZWUgd2hh dCBuZXcgYmVoYXZpb3IgaXMgYmVlbiBkZWZpbmVkIGhlcmUuIElmIHRoZXJlIGlzIG5vbmUsIEkg d291bGQgc3VnZ2VzdCB0byByZW1vdmUgdGhpcyBzZW50ZW5jZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+LS0tLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEEgQkdQIGFu bm91bmNlbWVudCB3aWxsLCBpbiB0aGUgbm9ybWFsIGNhc2UsIHByb3BhZ2F0ZSB0aHJvdWdob3V0 IHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEJHUCBzcGVha2luZyBJbnRl cm5ldDsgYW5kIHRoZXJlIHdpbGwgdW5kb3VidGVkbHkgYmUgQkdQIHNwZWFrZXJzPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgd2hpY2ggZG8gbm90IGhhdmUgdGhlIEV4dGVuZGVk IE1lc3NhZ2UgY2FwYWJpbGl0eS4mbmJzcDsgVGhlcmVmb3JlLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IHB1dHRpbmcgYW4gYXR0cmlidXRlIHdoaWNoIGNhbiBub3QgYmUgZGVj b21wb3NlZCB0byA0MDk2IG9jdGV0cyBvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IGxlc3MgaW4gYW4gRXh0ZW5kZWQgTWVzc2FnZSBpcyBhIGxpa2VseSBwYXRoIHRvIHJvdXRp bmcgZmFpbHVyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgaXNzdWUgaXMgbm90IHNwZWNpZmljIHRv IGF0dHJpYnV0ZXMgYmlnZ2VyIHRoYW4gNDA5NiBvY3RldHMsIGJ1dCB0byBCR1AgbWVzc2FnZSB3 aG9zZSBsZW5ndGggaXMgYmlnZ2VyIHRoYW4gNDA5NiwgaXJyZXNwZWN0aXZlIG9mIHRoZQ0KIHNp emUgb2YgZWFjaCBhdHRyaWJ1dGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPlBsZWFzZSBlbGFib3JhdGUgb24gd2hhdCB5b3UgbWVhbiBieSDigJw8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPmFuIGF0dHJpYnV0ZSB3aGljaCBjYW4gbm90IGJlIGRlY29tcG9zZWQNCiB0byA0MDk2IG9j dGV0c+KAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LS0tPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij7igJwmbmJzcDsmbmJzcDsgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBCR1AgcHJvdG9jb2wg ZGV2ZWxvcGVycyBhbmQgaW1wbGVtZW50ZXJzIGFyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IGNvbnNlcnZhdGl2ZSBpbiB0aGVpciBhcHBsaWNhdGlvbiBhbmQgdXNlIG9mIEV4 dGVuZGVkIE1lc3NhZ2VzLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgZG9lcyB0aGlzIG1lYW4gZXhhY3RseT8gVGhhdCB0aGV5 IGRvbuKAmXQgdXNlIHRoaXMgZXh0ZW5zaW9uPyBUaGF0IHRoZXkgZG9u4oCZdCB1c2UgdGhpcyBl eHRlbnNpb24gdW5sZXNzIFhYX1RPIEJFIFNQRUNJRklFRF9YWD88L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPi0tLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IEZ1dHVyZSBwcm90b2Nv bCBzcGVjaWZpY2F0aW9ucyB3aWxsIG5lZWQgdG8gZGVzY3JpYmUgaG93IHRvIGhhbmRsZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBlZXJzIHdoaWNoIGNhbiBvbmx5IGFjY29t bW9kYXRlIDQwOTYgb2N0ZXQgbWVzc2FnZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XaHkgaXMgdGhpcyBs aW1pdGVkIHRvIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucz8gQSBwcmlvcmksIHVzaW5nIGV4aXN0aW5n IEJHUCBtZWNoYW5pc20gKEFGSS9TQUZJLCBhdHRyaWJ1dGVzLCAqIGNvbW11bml0aWVzKSBvbmUg Y291bGQgZXhjZWVkIHRoZSBzaXplDQogb2YgNDA5NiBvY3RldHMuIEhvdyBkb2VzIHRoZSBCR1Ag c3BlYWtlciBzdXBwb3NlZCB0byBiZWhhdmUgaW4gdGhpcyBjYXNlPyBUaGlzIHNob3VsZCBiZSBk ZXNjcmliZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiBOb3RlIHRoYXQgdGhpcyBpcyBub3QgYSBj YXNlIG9mIGVycm9yIGhhbmRsaW5nLCBhcyBldmVyeSBCR1Agc3BlYWtlciBpcyBiZWhhdmluZyBh cyBzcGVjaWZpZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LS0tLTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5EZXBlbmRpbmcgb24gdGhlIGFib3ZlIHNwZWNpZmljYXRp b24sIGEgc2VjdGlvbiBkZXNjcmliaW5nIHRoZSBvcGVyYXRpb25hbCBjb25zZXF1ZW5jZXMgaW4g YSBuZXR3b3JrIChzdWNoIGFzIHRoZSBJbnRlcm5ldCwgQkdQIEVuYWJsZWQgU2VydmljZVMvVlBO DQogbmV0d29ya3MpIGlzIHByb2JhYmx5IG5lZWRlZC4gUG9zc2libGUgY29uc2VxdWVuY2VzIGNv dWxkIGJlIEJHUCBOTFJJIGJlaW5nIHJlbW92ZWQgaW4gdGhlIG1pZGRsZSBvZiBzdWNoIG5ldHdv cmssIG9yIChleHRlbmRlZCkgY29tbXVuaXR5IChzdWNoIGFzIFJvdXRlIFRhcmdldHMpIGJlZW4g cmVtb3ZlZC4gQm90aCBoYXZpbmcgc2lnbmlmaWNhbnQgY29uc2VxdWVuY2VzIG9uIHRoZSBhdmFp bGFiaWxpdHkgcHJvdmlkZWQgYnkgdGhlIG5ldHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+wqc0PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5PTEQ6IFRoZSBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgb25s eSBhcHBsaWVzIHRvIGFsbCBtZXNzYWdlcyBleGNlcHQgZm9yIHRoZSBPUEVOIG1lc3NhZ2UuDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPlByb2JhYmx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5ORVc6 IFRoZSBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgYXBwbGllcyB0byBhbGwgbWVzc2FnZSB0 eXBlcyBleGNlcHQgZm9yIHRoZSBPUEVOIG1lc3NhZ2UgKHR5cGUgMSkuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPi0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPsKnODwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJxUaGlzIGV4 dGVuc2lvbiB0byBCR1AgZG9lcyBub3QgY2hhbmdlIEJHUCdzIHVuZGVybHlpbmcgc2VjdXJpdHkg aXNzdWVzJm5ic3A7wrs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlZm9yZSBldmFsdWF0aW5nIHRoaXMsIEkgdGhpbmsg dGhpcyBkb2N1bWVudCBzaG91bGQgZmlyc3Qgc3BlY2lmaWVkIGhvdyBhIEJHUCBtZXNzYWdlcyBi aWdnZXIgdGhhbiA0MDk2IG9jdGV0cyBpcyBoYW5kbGVkIHdoZW4gaXQgbmVlZHMgdG8gYmUgc2Vu dCB0byBhIHJlY2VpdmVkIG5vdCBzdXBwb3J0aW5nIHRoaXMgZXh0ZW5zaW9uLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5OaXRzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T0xEJm5ic3A7OiB0byByZWR1Y2UgY29t cGV4aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5ORVcmbmJzcDs6IHRvIHJlZHVjZSBjb21wbGV4 aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4tLUJydW5vPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IElkciBbPGEgaHJlZj0ibWFpbHRvOmlkci1i b3VuY2VzQGlldGYub3JnIj5tYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5TdXNhbiBIYXJlczxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51 YXJ5IDI5LCAyMDE5IDEyOjMzIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86aWRy QGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtJZHJdIFdH IExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+VGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgTEMgb24gRXh0ZW5kZWQgTWVzc2FnZSBTdXBwb3J0 IGZvciBCR1AgKGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0yNykuJm5ic3A7 IFlvdSBjYW4gYWNjZXNzIHRoZSBkcmFmdCBhdDoNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdl cyUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJi OGE5NDNlNjE0YjE2MzdmMzA4ZDY4NjA4ZDZjZCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1 YzYxZGVjJTdDMSU3QzAlN0M2MzY4NDM3Njk4NTkzMjEyODkmYW1wO3NkYXRhPW9ralRlTGU2RGNU YVJWMlVTeTJNeTZIWERSeW51cG1YbEIwaTdnVXd5bkElM0QmYW1wO3Jlc2VydmVkPTAiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRy LWJncC1leHRlbmRlZC1tZXNzYWdlcy88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5U aGUgYXV0aG9ycyBzaG91bGQgaW5kaWNhdGUgd2hldGhlciB0aGV5IGtub3cgb2YgYW55IElQUi4m bmJzcDsmbmJzcDsgSW1wbGVtZW50ZXJzIGFyZSBlbmNvdXJhZ2VkIHRvIHVwZGF0ZSB0aGUmbmJz cDsgaW1wbGVtZW50YXRpb24gZGF0YSBhdDoNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0cmFjLmlldGYu b3JnJTJGdHJhYyUyRmlkciUyRndpa2klMkZkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtaW1w bGVtZW50YXRpb25zJmFtcDtkYXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0Lmdv diU3QzQwYmI4YTk0M2U2MTRiMTYzN2YzMDhkNjg2MDhkNmNkJTdDMmFiNWQ4MmZkOGZhNDc5N2E5 M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjg0Mzc2OTg1OTMyMTI4OSZhbXA7c2RhdGE9UG9S eUZvZnMwNCUyRkMlMkYlMkZnYlhMMnp5RUQzU1c2TXJFU3BIaUlFMmU3cDRjQSUzRCZhbXA7cmVz ZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dp a2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLWltcGxlbWVudGF0aW9uczwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBkcmFmdCBwcm92aWRlcyBhIG1lYW5zIGZvciBleHBh bmRpbmcgdGhlIEJHUCBtZXNzYWdlIHRvIDY1NTM1IG9jdGV0cyBmb3IgYWxsIG1lc3NhZ2VzIGV4 Y2VwdCBPUEVOIG1lc3NhZ2VzLiZuYnNwOyBCR1AgbWVzc2FnZSBzcGFjZSBpcyBydW5uaW5nDQog c2hvcnQgZm9yIGFsbCBvZiB0aGUgcG90ZW50aWFsIGF0dHJpYnV0ZXMgb3IgYWRkaXRpb25zIHBy b3Bvc2VkIGJ5IEJHUC1MUyBmZWF0dXJlcy4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+VGhlIFdHIGNoYWlycyBpbnRlbmQgdG8gZm9yd2FyZCB0aGlzIGRyYWZ0IHRvIHRoZSBJ RVNHIHdpdGggdGhlIGN1cnJlbnQgbGV2ZWwgb2YgaW1wbGVtZW50YXRpb24uJm5ic3A7DQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFzIHlvdSBjb21tZW50IG9uIHRoZSBkcmFmdCwgcGxl YXNlIGNvbnNpZGVyIGlmOiBhKSB0aGUgdGVjaG5vbG9neSBpcyBtYXR1cmUsIGIpIHRoZSBhZGRp dGlvbmFsIHNwYWNlIGluIGEgQkdQIG1lc3NhZ2Ugd291bGQgYmUgaGVscGZ1bCBmb3INCiB0aG9z ZSBkZXBsb3lpbmcgQkdQLUxTIG9yIFNSLCBhbmQgYykgaWYgdGhlIHNwZWNpZmljYXRpb24gaXMg cmVhZHkgZm9yIHB1YmxpY2F0aW9uLiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5TdWUgSGFyZXMgKFdHIENoYWlyLCBTaGVwaGVyZCkNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDb25zb2xhcyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpDb25zb2xhcyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPnBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+ YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25z b2xhcyI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzIj50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+VGhhbmsgeW91Ljwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_ba5ddfd47a7c42db8e3ad1fba72fd18aXCHALN014ciscocom_-- From nobody Mon Feb 11 07:17:42 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F661271FF for ; Mon, 11 Feb 2019 07:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.936 X-Spam-Level: ** X-Spam-Status: No, score=2.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3hxn6rvCu42 for ; Mon, 11 Feb 2019 07:17:36 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA16126F72 for ; Mon, 11 Feb 2019 07:17:36 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.248.72; From: "Susan Hares" To: "'Jakob Heitz \(jheitz\)'" , "'Dongjie \(Jimmy\)'" , "'Borchert, Oliver \(Fed\)'" , , "'Borchert, Oliver \(Fed\)'" Cc: References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <009501d4b7f1$962d0080$c2870180$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927C3286B43@NKGEML515-MBX.china.huawei.com> <00e201d4ba3f$34bb67b0$9e323710$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927C32AEB75@NKGEML515-MBS.china.huawei.com> In-Reply-To: Date: Mon, 11 Feb 2019 10:17:04 -0500 Message-ID: <00de01d4c21c$d91e6e30$8b5b4a90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DF_01D4C1F2.F04F9220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rAb/ZDQcBMZz+VgGA2nz4AiqzQJUB/lHI6wJZutJwpCz93fA= Content-Language: en-us X-Antivirus: AVG (VPS 190211-4, 02/11/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 15:17:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DF_01D4C1F2.F04F9220 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Jakob: =20 Thanks for mentioning the correct information the BGPSec as far as the = specifications. Whether or not the RSA-2048 would have been useful to = BGPSec, is left for the OPS group handling SIDR deployment. =20 =20 The focus of this discussion is to remove any future obstacles to the = use of BGP-LS attributes/NLRI. Two potential limits exist: a) message = size (greater than 4096) and b) error handling.=20 =20 Sue Hares=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz = (jheitz) Sent: Monday, February 4, 2019 3:14 PM To: Dongjie (Jimmy); Susan Hares; 'Borchert, Oliver (Fed)'; = bruno.decraene@orange.com; 'Borchert, Oliver (Fed)' Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 BGPSec dropped the requirement for extended messages because the signature was changed from RSA-2048 (256 byte sig) to ECDSA P-256 (64 = byte sig). https://mailarchive.ietf.org/arch/msg/sidr/LRHPuO5MF0u-vWuhNAVeVN_8fIU =20 There is no mention of extended messages in = https://tools.ietf.org/html/rfc8205 All mention of it was struck out in: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-protocol-23.= txt =20 Regards, Jakob. =20 From: Idr On Behalf Of Dongjie (Jimmy) Sent: Friday, February 1, 2019 10:45 PM To: Susan Hares ; 'Borchert, Oliver (Fed)' = ; = bruno.decraene@orange.com; 'Borchert, Oliver (Fed)' = Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Hi Sue,=20 =20 Thanks for updating the implementation report.=20 =20 My understanding was that bullet 4 was to cover the behavior of section = 5 paragraph 1, bullet 5 was to cover the behavior of section 5 paragraph = 2. =20 But after rereading section 5, I realize that both paragraph 1 and 2 are = talking about the behavior of a BGP speaker which does not advertise the = extended message capability to its peer, so perhaps bullets 4 and 5 in = the implementation report could be merged as below:=20 =20 4. When receives an extended message without advertising the BGP = Extended Message Capability to this peer (Error Handling). 4a. Accepts the extended message if the BGP speaker is able to process = extended message (but was configured not to advertise the capability) = [Section 5, paragraph 1 MAY] 4b. Does not accept the extended message, follows RFC4271 handling and = sends Bad Message Length Notification [Section 5, paragraph 1 SHOULD = NOT, and paragraph 2 MUST) =20 Hope this helps to reduce the confusion. =20 Best regards, Jie =20 =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Friday, February 01, 2019 11:03 PM To: Dongjie (Jimmy) ; 'Borchert, Oliver (Fed)' = ; = bruno.decraene@orange.com; 'Borchert, Oliver (Fed)' = Cc: idr@ietf.org Subject: RE: [Idr] WG Last Call on Extened Message Support =20 JIe, Bruno and Oliver:=20 =20 Thank you for your input. You are correct that the error handling = behavior was unclear based on the questions in the chart. The purpose = of the chart is to provide other BGP WGs (Bess, SPRING, LSVR) a clear = indication of changes to the base BGP specification.=20 =20 I=E2=80=99ve reformatted sections 4 and 5 of the chart. =20 =20 To section 4 I=E2=80=99ve added:=20 4c Does send Extended Message - with a yes from all = implementations (based on their email)=20 =20 Section 5, I=E2=80=99ve alter to be:=20 5 Error handing =20 5a Accepts Extended message without receiving=20 BGP Extended Message Capability [Section 5 paragraph 1 MAY] =20 5b If receives Extended Message without BGP extended message = support, follows RFC4271 handling and sends Bad message length = Notification=20 [section 5 paragraph 2 MUST]=20 =20 Oliver =E2=80=93 if you would read the current text and let me know the = updated message. I believe the answer for all 3 implementations is = =E2=80=9Cyes=E2=80=9D due to 4b. Please let me know and I will update = the information in the chart.=20 =20 To follow-up on Jie=E2=80=99s comments, the text did not accurately = represent the error handling. Section 5, paragraph 1 has a = =E2=80=9CSHOULD NOT=E2=80=9D modified by a =E2=80=9CMAY=E2=80=9D, which = results in simply a =E2=80=9CMAY=E2=80=9D. For readability, I think = the =E2=80=9CSHOULD NOT=E2=80=9D provides useful information to the = implementer, but it cannot be tested accurately when combined with the = =E2=80=9CMAY=E2=80=9D. =20 =20 Let me give you an example of that: If the peer did not send a BGP Extended Message capability, and it = accepts the extended message (with a length of 10,000 bytes), it could = have a liberal policy of MAY as a default in the implementation. The = =E2=80=9Con-wire=E2=80=9D observations cannot tell =E2=80=93 only the = implementation=E2=80=99s policy (default + configured). =20 =20 I also broke out the management information away from the specification = information. =20 =20 Sue Hares =20 =20 From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com]=20 Sent: Wednesday, January 30, 2019 8:53 PM To: Borchert, Oliver (Fed); Susan Hares; bruno.decraene@orange.com; = Borchert, Oliver (Fed) Cc: idr@ietf.org Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Hi Oliver, Bruno and Sue, =20 To my understanding, bullet 5/5a/5b in the implementation report is = corresponding to the second paragraph in section 5 =E2=80=9CError = Handling=E2=80=9D: =20 A BGP speaker that does not advertise the BGP Extended Messages capability might also genuinely not support Extended Messages. Such a speaker MUST follow the error handling procedures of [RFC4271] if it receives an Extended Message. Similarly, any speaker that treats an improper Extended Message as a fatal error, MUST treat it similarly. =20 Thus it is to describe the error handling behavior of an implementation = version which does not support extended message.=20 =20 While I agree this could be misleading for a report of implementation = which supports extended message capability, maybe it could be used to = verify the behavior of an old version which does not support this = capability? =20 Best regards, Jie =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Borchert, Oliver = (Fed) Sent: Wednesday, January 30, 2019 4:35 AM To: Susan Hares ; bruno.decraene@orange.com; Borchert, = Oliver (Fed) Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Bruno and Susan, =20 I cannot speak for the ExaBGP Implementation but for BGPSEC-IO and = QuaggaSRx. I believe when I compiled the report, I mis-read 5a and overlooked the = =E2=80=9Cnot=E2=80=9D and read instead: =E2=80=9CDoes send Extended = Message Capability=E2=80=9D. Therefore the implementation report for section 5a must be corrected = from =E2=80=9CYes=E2=80=9D into =E2=80=9CNo=E2=80=9D for both BGPSEC-IO = and QuaggaSRx =20 BGPSEC-IO and QuaggaSRx, both do send the extended message capability if = so configured. I just checked the code and run it again. I copy/pasted the relevant = output generated by BGPSEC-IO, =20 Oliver =20 ----- output of BGPSEC-IO ------- =20 =EF=BB=BF./bgpsecio -f bgpsecio.test.cfg.qsrx=20 Starting bgpsecio 0.2.0.25... Send: (Open message send from BGPSEC-IO to QuaggaSRx)=20 OPEN Message +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF =E2=80=A6 +--Optional Parameter: Capability | +--Type: Capability (2) | +--Length: 2 | +--Capability: Extended message support capability | +--Type: Extended message support capability (6) | +--Length: 0 =E2=80=A6 =20 Received: (Open message send from QuaggaSRx and received by BGPSEC-IO) OPEN Message +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF =E2=80=A6 +--Optional Parameter: Capability +--Type: Capability (2) +--Length: 2 +--Capability: Extended message support capability +--Type: Extended message support capability (6) +--Length: 0 BGP-receiver thread created! =20 =20 =20 From: Idr on behalf of Susan Hares = Date: Tuesday, January 29, 2019 at 11:43 AM To: "bruno.decraene@orange.com" Cc: "idr@ietf.org" Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Bruno: =20 Thank you for your comments on this topic =E2=80=93 as I think=20 =20 I did receive reports privately that we have 1 full implementations of = draft-ietf-idr-bgp-extended-messages off list which is not listed in = this report. I hope those implementers will volunteer this information = on the list. If not, I will share this information with Alvaro and the = IESG. =20 =20 The SIDR work did define draft-ietf-bgp-extended-messages as a = requirement and only moved to not specifying it when we could not = quickly pass this through WG LC.=20 =20 The real needs are a growing BGP-LS that may run out of BGP message = space. As my previous email to IDR indicates, I was hoping this handles = an BGP message whose length is bigger than 4096 bytes. Thank you for = the correction of:=20 =20 =E2=80=9CThe issue is not specific to attributes bigger than 4096 = octets, but to BGP message whose length is bigger than 4096, = irrespective of the size of each attribute.=E2=80=9D =20 =20 As to your comment:=20 =20 =E2=80=9CWhy is this limited to future specifications? A priori, using = existing BGP mechanism (AFI/SAFI, attributes, * communities) one could = exceed the size of 4096 octets. How does the BGP speaker supposed to = behave in this case? This should be described in this specification. = Note that this is not a case of error handling, as every BGP speaker is = behaving as specified.=E2=80=9D =20 This problem has been true for years, and thus as co-chairs had hoped to = have the draft-ietf-bgp-extended-messages passed years ago. As BGP-LS = attributes grow use and in number, the potential of exceeding the BGP = message limit increases. It seems like a good direction to prevent = issues.=20 =20 I hope the authors will comment on the changes you suggested to the = text.=20 =20 Cheers,=20 Susan Hares=20 =20 =20 =20 From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Sent: Tuesday, January 29, 2019 8:33 AM To: Susan Hares Cc: idr@ietf.org Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Hi WG, =20 Please find below some comments. As of today, I don=E2=80=99t believe this specification is ready to be = progressed to IESG/RFC, especially for a document updating RFC 4271 = (core BGP spec). =20 > The WG chairs intend to forward this draft to the IESG with the = current level of implementation. =20 =20 https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations = = says : 5a=20 Does not send Extended Message capability=20 Yes=20 Yes=20 Yes=20 =20 I may be misunderstanding the implementation report, but my reading of = the above is that none of the reported implementations sends the = capability hence no implementation supports = draft-ietf-idr-bgp-extended-messages.. Here this document is updating = RFC 4271, so it is not a minor extension for a niche use case. So I = don=E2=80=99t see the arguments for not requiring the IDR=E2=80=99s = usual two interoperable implementations. =20 ---- =C2=A7 1 =E2=80=9C As BGP is extended to support newer AFI/SAFIs and newer capabilities (e.g., [ = I-D.ietf-sidr-bgpsec-protocol]), there is a need to extend the maximum message size beyond 4096 octets. = =E2=80=9C =20 https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on-1 = =20 =20 =20 [ = I-D.ietf-sidr-bgpsec-protocol is now RFC 8205 (thanks = for updating the reference). It has removed the normative/any reference = to draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not = need draft-ietf-idr-bgp-extended-messages. Can we have an update on this? Can the introduction of draft-ietf-idr-bgp-extended-messages be updated = to introduce on the real reasons/needs? =20 ---- =C2=A74 =C2=A73 says =E2=80=9CA peer which does not advertise this capability = MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.=E2=80=9D =20 Fine. Text in =C2=A74 should probably be aligned with the above ..e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. =20 NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and = received the Extended Message Capability to and from that peer. =20 ---- =E2=80=9C Applications generating information which might be = encapsulated within BGP messages MUST limit the size of their payload to take the maximum message size into account.=E2=80=9D =20 I don=E2=80=99t see what new behavior is been defined here. If there is = none, I would suggest to remove this sentence =20 ---- A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. =20 =20 The issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than 4096, irrespective of the size = of each attribute. Please elaborate on what you mean by =E2=80=9Can attribute which can not = be decomposed to 4096 octets=E2=80=9D =20 --- =E2=80=9C It is RECOMMENDED that BGP protocol developers and = implementers are conservative in their application and use of Extended = Messages.=E2=80=9D =20 What does this mean exactly? That they don=E2=80=99t use this extension? = That they don=E2=80=99t use this extension unless XX_TO BE SPECIFIED_XX? =20 --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages. =20 Why is this limited to future specifications? A priori, using existing = BGP mechanism (AFI/SAFI, attributes, * communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = case? This should be described in this specification. Note that this is = not a case of error handling, as every BGP speaker is behaving as = specified. =20 =20 ---- Depending on the above specification, a section describing the = operational consequences in a network (such as the Internet, BGP Enabled = ServiceS/VPN networks) is probably needed. Possible consequences could = be BGP NLRI being removed in the middle of such network, or (extended) = community (such as Route Targets) been removed. Both having significant = consequences on the availability provided by the network. =20 --- =C2=A74 OLD: The Extended Message Capability only applies to all messages except = for the OPEN message.=20 Probably NEW: The Extended Message Capability applies to all message types except = for the OPEN message (type 1).=20 ---- =C2=A78 =E2=80=9CThis extension to BGP does not change BGP's underlying security = issues =C2=BB Before evaluating this, I think this document should first specified how = a BGP messages bigger than 4096 octets is handled when it needs to be = sent to a received not supporting this extension. =20 Nits: OLD : to reduce compexity NEW : to reduce complexity =20 Thanks, --Bruno =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org Subject: [Idr] WG Last Call on Extened Message Support =20 =20 This begins a 2 week WG LC on Extended Message Support for BGP = (draft-ietf-idr-bgp-extended-messages-27). You can access the draft at: = =20 = = https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ =20 The authors should indicate whether they know of any IPR. Implementers = are encouraged to update the implementation data at:=20 =20 = = = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations =20 The draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages. BGP message space is running = short for all of the potential attributes or additions proposed by = BGP-LS features. =20 =20 The WG chairs intend to forward this draft to the IESG with the current = level of implementation. =20 =20 As you comment on the draft, please consider if: a) the technology is = mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for = publication. =20 =20 Sue Hares (WG Chair, Shepherd)=20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. ------=_NextPart_000_00DF_01D4C1F2.F04F9220 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Jakob:

 

Thanks for mentioning the correct information the BGPSec as far as = the specifications.=C2=A0 Whether or not the RSA-2048 would have been = useful to BGPSec, is left for the OPS group handling SIDR = deployment.=C2=A0

 

The focus of this discussion is to remove any future obstacles to the = use of BGP-LS attributes/NLRI.=C2=A0 Two potential limits exist:=C2=A0 = a) message size (greater than 4096) and b) error handling. =

 

Sue Hares

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz = (jheitz)
Sent: Monday, February 4, 2019 3:14 PM
To: = Dongjie (Jimmy); Susan Hares; 'Borchert, Oliver (Fed)'; = bruno.decraene@orange.com; 'Borchert, Oliver (Fed)'
Cc: = idr@ietf.org
Subject: Re: [Idr] WG Last Call on Extened = Message Support

 

BGPSec dropped the requirement for extended messages = because the

signature was changed from RSA-2048 (256 byte sig) = to ECDSA P-256 (64 byte sig).

https://mailarchive.ietf.org/arch/msg/sidr/LRHPuO5MF0u-vWuhNAVeVN_= 8fIU

 

There is no mention of extended messages in https://tools.ietf.org/html/= rfc8205

All = mention of it was struck out in:

https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec= -protocol-23.txt

 

Regards,

Jakob.

 

From: Idr = <idr-bounces@ietf.org> On Behalf Of Dongjie = (Jimmy)
Sent: Friday, February 1, 2019 10:45 PM
To: = Susan Hares <shares@ndzh.com>; 'Borchert, Oliver (Fed)' = <oliver.borchert=3D40nist.gov@dmarc.ietf.org>; = bruno.decraene@orange.com; 'Borchert, Oliver (Fed)' = <oliver.borchert@nist.gov>
Cc: = idr@ietf.org
Subject: Re: [Idr] WG Last Call on Extened = Message Support

 

Hi Sue,

 

Thanks for updating the implementation report. =

 

My understanding was that bullet 4 was to cover the behavior of = section 5 paragraph 1, bullet 5 was to cover the behavior of section 5 = paragraph 2.

 

But after rereading section 5, I realize that both paragraph 1 and 2 = are talking about the behavior of a BGP speaker which does not advertise = the extended message capability to its peer, so perhaps bullets 4 and 5 = in the implementation report could be merged as below: =

 

4. When receives an extended message without advertising the BGP = Extended Message Capability to this peer (Error = Handling).

4a. Accepts the extended message if the BGP speaker is able to = process extended message (but was configured not to advertise the = capability)   [Section 5, paragraph 1 = MAY]

4b. Does not accept the extended message, follows RFC4271 handling = and sends Bad Message Length Notification [Section 5, paragraph 1 SHOULD = NOT, and paragraph 2 MUST)

 

Hope this helps to reduce the confusion.

 

Best regards,

Jie

 

 

From: Susan = Hares [mailto:shares@ndzh.com] =
Sent: Friday, February 01, 2019 11:03 PM
To: = Dongjie (Jimmy) <jie.dong@huawei.com>; = 'Borchert, Oliver (Fed)' <oliver.borche= rt=3D40nist.gov@dmarc.ietf.org>; bruno.decraene@orange.com; = 'Borchert, Oliver (Fed)' <oliver.borchert@nist.gov>=
Cc: idr@ietf.org
Subject: RE: = [Idr] WG Last Call on Extened Message = Support

 

JIe, Bruno and Oliver:

 

Thank you for your input.   You are correct that the error = handling behavior was unclear based on the questions in the chart. =   The purpose of the chart is to provide other BGP WGs (Bess, = SPRING, LSVR) a clear indication of changes to the base BGP = specification.

 

I=E2=80=99ve reformatted sections 4 and 5 of the chart.  =

 

To section 4 I=E2=80=99ve added:

4c            = Does send Extended Message  - with a yes from all implementations = (based on their email)

 

Section 5, I=E2=80=99ve alter to be:

5           &nb= sp;  Error = handing           =           =

5a           = Accepts Extended message without receiving

           &nbs= p; BGP Extended Message Capability [Section 5 paragraph 1 = MAY]

           &nbs= p;            = ;            =             =

5b           If = receives Extended Message without BGP extended message = support,

            =  follows RFC4271 handling and sends Bad message length Notification =

           &nbs= p;[section 5 paragraph 2 MUST]

 

Oliver =E2=80=93 if you would read the current text and let me know = the updated message.  I believe the answer for all 3 = implementations is =E2=80=9Cyes=E2=80=9D due to 4b.   Please = let me know and I will update the information in the chart. =

 

To follow-up on Jie=E2=80=99s comments, the text did not accurately = represent the error handling.   Section 5, paragraph 1 has a = =E2=80=9CSHOULD NOT=E2=80=9D modified by a =E2=80=9CMAY=E2=80=9D, which = results in simply a =E2=80=9CMAY=E2=80=9D.   For readability, = I think the =E2=80=9CSHOULD NOT=E2=80=9D provides useful = information  to the implementer,  but it cannot be tested = accurately when combined with the =E2=80=9CMAY=E2=80=9D.  =   

 

Let me give you an example of that:

If the peer did not send a BGP Extended Message capability, and it = accepts the extended message (with a length of 10,000 bytes), it could = have a liberal policy of MAY as a default in the implementation. =   The =E2=80=9Con-wire=E2=80=9D observations cannot tell = =E2=80=93 only the implementation=E2=80=99s policy (default + = configured).   

 

I also broke out the management information away from the = specification information. 

 

Sue Hares  

 

From:= = Dongjie (Jimmy) [mailto:jie.dong@huawei.com] =
Sent: Wednesday, January 30, 2019 8:53 PM
To: = Borchert, Oliver (Fed); Susan Hares; bruno.decraene@orange.com; = Borchert, Oliver (Fed)
Cc: idr@ietf.org
Subject: RE: = [Idr] WG Last Call on Extened Message = Support

 

Hi Oliver, Bruno and Sue,

 

To my understanding, bullet 5/5a/5b in the implementation report is = corresponding to the second paragraph in section 5 =E2=80=9CError = Handling=E2=80=9D:

 

A BGP speaker that does not advertise the BGP Extended = Messages

   capability might also genuinely not support Extended = Messages.  Such

   a speaker MUST follow the error handling procedures of = [RFC4271] if

   it receives an Extended Message.  Similarly, any = speaker that treats

   an improper Extended Message as a fatal error, MUST = treat it

   similarly.

 

Thus it is to describe the error handling behavior of an = implementation version which does not support extended message. =

 

While I agree this could be misleading for a report of implementation = which supports extended message capability, maybe it could be used to = verify the behavior of an old version which does not support this = capability?

 

Best regards,

Jie

 

From: Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Borchert, Oliver (Fed)
Sent: Wednesday, = January 30, 2019 4:35 AM
To: Susan Hares <shares@ndzh.com>; bruno.decraene@orange.com; = Borchert, Oliver (Fed) <oliver.borchert@nist.gov>=
Cc: idr@ietf.org
Subject: Re: = [Idr] WG Last Call on Extened Message = Support

 

Bruno and = Susan,

 =

I cannot = speak for the ExaBGP Implementation but for BGPSEC-IO and = QuaggaSRx.

I believe = when I compiled the report, I mis-read 5a and overlooked the = =E2=80=9Cnot=E2=80=9D and read instead: =E2=80=9CDoes send Extended = Message Capability=E2=80=9D.

Therefore = the implementation report for section 5a must be corrected from = =E2=80=9CYes=E2=80=9D into =E2=80=9CNo=E2=80=9D for both BGPSEC-IO and = QuaggaSRx

 =

BGPSEC-IO = and QuaggaSRx, both do send the extended message capability if so = configured.

I just = checked the code and run it again. I copy/pasted the relevant output = generated by BGPSEC-IO,

 =

Oliver=

 =

----- = output of BGPSEC-IO  -------

 =

=EF=BB=BF./= bgpsecio -f bgpsecio.test.cfg.qsrx

Starting = bgpsecio 0.2.0.25...

Send: = (Open message send from BGPSEC-IO to QuaggaSRx) =

OPEN = Message

  = +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

=E2=80=A6

  = ;   +--Optional Parameter: Capability

  = ;   |  +--Type: Capability (2)

  = ;   |  +--Length: 2

  = ;   |  +--Capability: Extended message support = capability

  = ;   |     +--Type: Extended message = support capability (6)

  = ;   |     +--Length: = 0

=E2=80=A6

 =

Received: = (Open message send from QuaggaSRx and received by = BGPSEC-IO)

OPEN = Message

  = +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

=E2=80=A6

  = ;   +--Optional Parameter: Capability

  = ;      +--Type: Capability = (2)

  = ;      +--Length: 2

  = ;      +--Capability: Extended message support = capability

  = ;         +--Type: Extended = message support capability (6)

  = ;         +--Length: = 0

BGP-receive= r thread created!

 =

 =

 =

From: = Idr <idr-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
Date: = Tuesday, January 29, 2019 at 11:43 AM
To: "bruno.decraene@orange.com&q= uot; <bruno.decraene@orange.com&g= t;
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: = [Idr] WG Last Call on Extened Message = Support

 

Bruno:

 

Thank = you for your comments on this topic =E2=80=93 as I think =

 

I did = receive reports privately that we have 1 full implementations of = draft-ietf-idr-bgp-extended-messages off list which is not listed in = this report.   I hope those implementers will volunteer this = information on the list.   If not, I will share this = information with Alvaro and the IESG.  =  

 

The = SIDR work did define draft-ietf-bgp-extended-messages as a requirement = and only moved to not specifying it when we could not quickly pass this = through WG LC.

 

The = real needs are a growing BGP-LS that may run out of BGP message = space.  As my previous email to IDR indicates, I was hoping this = handles an BGP message whose length is bigger than 4096 bytes.  =  Thank you for the correction of:

 

=E2=80=9CThe issue is not specific to attributes = bigger than 4096 octets, but to BGP message whose length is bigger than = 4096, irrespective of the size of each = attribute.=E2=80=9D

 

 

As to = your comment:

 

=E2=80=9CWhy is = this limited to future specifications? A priori, using existing BGP = mechanism (AFI/SAFI, attributes, * communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = case? This should be described in this specification. Note that this is = not a case of error handling, as every BGP speaker is behaving as = specified.=E2=80=9D

 

This problem has = been true for years, and thus as co-chairs had hoped to have the = draft-ietf-bgp-extended-messages passed years ago.   As BGP-LS = attributes grow use and in number, the potential of exceeding the BGP = message limit increases.  It seems like a good direction to prevent = issues.

 

I hope the authors = will comment on the changes you suggested to the text. =

 

Cheers, =

Susan Hares =

 

 

 

From:= = bruno.decraene@orange.com = [mailto:bruno.decraene@orange.co= m]
Sent: Tuesday, January 29, 2019 8:33 AM
To: = Susan Hares
Cc: idr@ietf.org
Subject: RE: = [Idr] WG Last Call on Extened Message = Support

 

Hi = WG,

 =

Please find = below some comments.

As of today, = I don=E2=80=99t believe this specification is ready to be progressed to = IESG/RFC, especially for a document updating RFC 4271 (core BGP = spec).

 

&= gt; The WG chairs intend to forward this draft to the IESG with the = current level of implementation. 

 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bg= p-extended-implementations says : 5a

Does not = send Extended Message capability

Yes =

Yes

Yes =

 

I may be = misunderstanding the implementation report, but my reading of the above = is that none of the reported implementations sends the capability hence = no implementation supports draft-ietf-idr-bgp-extended-messages.. Here = this document is updating RFC 4271, so it is not a minor extension for a = niche use case. So I don=E2=80=99t see the arguments for not requiring = the IDR=E2=80=99s usual two interoperable = implementations.

 

----

=C2=A7 = 1

=E2=80=9C As BGP is = extended to support newer AFI/SAFIs and

   newer = capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there = is

   a need = to extend the maximum message size beyond 4096 octets.  = =E2=80=9C

 

https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-mes= sages-27#section-1

 

 

[I-D.ietf-sidr-bgpsec-protocol is now RFC = 8205 (thanks for updating the reference). It has removed the = normative/any reference to draft-ietf-idr-bgp-extended-messages. So = presumably BGP Sec does not need = draft-ietf-idr-bgp-extended-messages.

Can we have = an update on this?

Can the = introduction of draft-ietf-idr-bgp-extended-messages be updated to = introduce on the real reasons/needs?

&= nbsp;

----

=C2=A74

=C2=A73 says =
=E2=80=9CA peer which does not advertise this capability MUST NOT send =
BGP
<= p class=3DMsoNormal style=3D'margin-left:.5in'>  =  Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.=E2=80=9D

&= nbsp;

F= ine. Text in =C2=A74 should probably be aligned with the above = ..e.g.

O=
LD: A =
BGP speaker
<= p class=3DMsoNormal style=3D'margin-left:.5in'>   MAY = send Extended Messages to its peer only if it has received = the

   = Extended Message Capability from that peer.

&= nbsp;

N= EW:

A BGP = speaker

   MAY = send Extended Messages to its peer only if it has sent and received = the

   = Extended Message Capability to and from that = peer.

 

----

=E2=
=80=9C   Applications generating information which might be =
encapsulated
<= p class=3DMsoNormal style=3D'margin-left:.5in'>   within = BGP messages MUST limit the size of their payload to take = the

   = maximum message size into account.=E2=80=9D

 

I = don=E2=80=99t see what new behavior is been defined here. If there is = none, I would suggest to remove this sentence

&= nbsp;

-= ---

   A BGP = announcement will, in the normal case, propagate throughout = the

   BGP = speaking Internet; and there will undoubtedly be BGP = speakers

   which = do not have the Extended Message capability.  = Therefore,

   = putting an attribute which can not be decomposed to 4096 octets = or

   less = in an Extended Message is a likely path to routing = failure.

&= nbsp;

&= nbsp;

T= he issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than 4096, irrespective of the size = of each attribute.

P= lease elaborate on what you mean by =E2=80=9Can attribute which = can not be decomposed to 4096 octets=E2=80=9D

&= nbsp;

-= --

=E2=80=9C   It is RECOMMENDED that BGP protocol = developers and implementers are

   = conservative in their application and use of Extended = Messages.=E2=80=9D

 

What does = this mean exactly? That they don=E2=80=99t use this extension? That they = don=E2=80=99t use this extension unless XX_TO BE = SPECIFIED_XX?

&= nbsp;

-= --

  Future = protocol specifications will need to describe how to = handle

   peers = which can only accommodate 4096 octet messages.

&= nbsp;

Why is this = limited to future specifications? A priori, using existing BGP mechanism = (AFI/SAFI, attributes, * communities) one could exceed the size of 4096 = octets. How does the BGP speaker supposed to behave in this case? This = should be described in this specification. Note that this is not a case = of error handling, as every BGP speaker is behaving as = specified.

 

 

-= ---

D= epending on the above specification, a section describing the = operational consequences in a network (such as the Internet, BGP Enabled = ServiceS/VPN networks) is probably needed. Possible consequences could = be BGP NLRI being removed in the middle of such network, or (extended) = community (such as Route Targets) been removed. Both having significant = consequences on the availability provided by the = network.

&= nbsp;

-= --

=C2= =A74

OLD: The Extended = Message Capability only applies to all messages except for the OPEN = message.

Probably

NEW: The Extended = Message Capability applies to all message types except for the OPEN = message (type 1).

----

=C2=A78

=E2=80=9CThis =
extension to BGP does not change BGP's underlying security =
issues =C2=BB
<= pre style=3D'margin-left:.5in'>Before evaluating = this, I think this document should first specified how a BGP messages = bigger than 4096 octets is handled when it needs to be sent to a = received not supporting this extension.<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

N= its:

OLD : to = reduce compexity

NEW : to = reduce complexity

 

T= hanks,

-= -Bruno

&= nbsp;

From:= Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Tuesday, January 29, = 2019 12:33 PM
To: idr@ietf.org
Subject: [Idr] = WG Last Call on Extened Message = Support

 

&= nbsp;

T= his begins a 2 week WG LC on Extended Message Support for BGP = (draft-ietf-idr-bgp-extended-messages-27).  You can access the = draft at:

&= nbsp;

https://datat= racker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/=

&= nbsp;

T= he authors should indicate whether they know of any IPR.   = Implementers are encouraged to update the  implementation data at: =

&= nbsp;

https://trac.= ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations=

&= nbsp;

T= he draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages.  BGP message space is = running short for all of the potential attributes or additions proposed = by BGP-LS features. 

&= nbsp;

T= he WG chairs intend to forward this draft to the IESG with the current = level of implementation. 

&= nbsp;

A= s you comment on the draft, please consider if: a) the technology is = mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for = publication. 

&= nbsp;

S= ue Hares (WG Chair, Shepherd)

&= nbsp;

 

_________________________=
_________________________________________________________________________=
_______________________
<= pre style=3D'margin-left:.5in'> <= pre style=3D'margin-left:.5in'>Ce message et ses pieces = jointes peuvent contenir des informations confidentielles ou = privilegiees et ne doivent donc<= pre style=3D'margin-left:.5in'>pas etre diffuses, = exploites ou copies sans autorisation. Si vous avez recu ce message par = erreur, veuillez le signaler<= pre style=3D'margin-left:.5in'>a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration,<= pre style=3D'margin-left:.5in'>Orange decline toute = responsabilite si ce message a ete altere, deforme ou falsifie. = Merci.<= pre style=3D'margin-left:.5in'> <= pre style=3D'margin-left:.5in'>This message and its = attachments may contain confidential or privileged information that may = be protected by law;<= pre style=3D'margin-left:.5in'>they should not be = distributed, used or copied without authorisation.<= pre style=3D'margin-left:.5in'>If you have received = this email in error, please notify the sender and delete this message = and its attachments.<= pre style=3D'margin-left:.5in'>As emails may be = altered, Orange is not liable for messages that have been modified, = changed or falsified.<= pre style=3D'margin-left:.5in'>Thank you.<= /div>
------=_NextPart_000_00DF_01D4C1F2.F04F9220-- From nobody Mon Feb 11 08:42:59 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0921A131089 for ; Mon, 11 Feb 2019 08:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.936 X-Spam-Level: ** X-Spam-Status: No, score=2.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-GVDNuSwGpA for ; Mon, 11 Feb 2019 08:42:53 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62552131074 for ; Mon, 11 Feb 2019 08:42:53 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.248.72; From: "Susan Hares" To: "'Borchert, Oliver \(Fed\)'" , "'Randy Bush'" Cc: References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <009501d4b7f1$962d0080$c2870180$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927C3286B43@NKGEML515-MBX.china.huawei.com> <00e201d4ba3f$34bb67b0$9e323710$@ndzh.com> In-Reply-To: Date: Mon, 11 Feb 2019 11:42:39 -0500 Message-ID: <011b01d4c228$cd4ec940$67ec5bc0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011C_01D4C1FE.E4808970" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rAb/ZDQcBMZz+VgGA2nz4AiqzQJUCeA0itaQ8Au6A Content-Language: en-us X-Antivirus: AVG (VPS 190211-4, 02/11/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 16:42:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_011C_01D4C1FE.E4808970 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Oliver and Randy:=20 =20 We are waiting your comments/revisions to complete the WG LC on extended = messages. We will extend the WG LC 1 more week to receive your answers. = =20 Oliver =E2=80=93 Please update the wiki with the correct information.=20 =20 Randy =E2=80=93 Please respond to the questions send on the list.=20 =20 Thank you, Susan Hares=20 =20 From: Borchert, Oliver (Fed) [mailto:oliver.borchert@nist.gov]=20 Sent: Monday, February 4, 2019 10:55 AM To: Susan Hares Cc: Borchert, Oliver (Fed) Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Hi Susan, I know it=E2=80=99s not much but I want to be thorough before I post to = the list. I try today but definitely will get to this in the next days. = Still cleaning up from the government shutdown, Oliver =20 From: Susan Hares Date: Friday, February 1, 2019 at 10:03 AM To: "'Dongjie (Jimmy)'" , "'Borchert, Oliver = (Fed)'" , = "bruno.decraene@orange.com" , Oliver Borchert = Cc: "idr@ietf.org" Subject: RE: [Idr] WG Last Call on Extened Message Support =20 JIe, Bruno and Oliver:=20 =20 Thank you for your input. You are correct that the error handling = behavior was unclear based on the questions in the chart. The purpose = of the chart is to provide other BGP WGs (Bess, SPRING, LSVR) a clear = indication of changes to the base BGP specification.=20 =20 I=E2=80=99ve reformatted sections 4 and 5 of the chart. =20 =20 To section 4 I=E2=80=99ve added:=20 4c Does send Extended Message - with a yes from all = implementations (based on their email)=20 =20 Section 5, I=E2=80=99ve alter to be:=20 5 Error handing =20 5a Accepts Extended message without receiving=20 BGP Extended Message Capability [Section 5 paragraph 1 MAY] =20 5b If receives Extended Message without BGP extended message = support, follows RFC4271 handling and sends Bad message length = Notification=20 [section 5 paragraph 2 MUST]=20 =20 Oliver =E2=80=93 if you would read the current text and let me know the = updated message. I believe the answer for all 3 implementations is = =E2=80=9Cyes=E2=80=9D due to 4b. Please let me know and I will update = the information in the chart.=20 =20 To follow-up on Jie=E2=80=99s comments, the text did not accurately = represent the error handling. Section 5, paragraph 1 has a = =E2=80=9CSHOULD NOT=E2=80=9D modified by a =E2=80=9CMAY=E2=80=9D, which = results in simply a =E2=80=9CMAY=E2=80=9D. For readability, I think = the =E2=80=9CSHOULD NOT=E2=80=9D provides useful information to the = implementer, but it cannot be tested accurately when combined with the = =E2=80=9CMAY=E2=80=9D. =20 =20 Let me give you an example of that: If the peer did not send a BGP Extended Message capability, and it = accepts the extended message (with a length of 10,000 bytes), it could = have a liberal policy of MAY as a default in the implementation. The = =E2=80=9Con-wire=E2=80=9D observations cannot tell =E2=80=93 only the = implementation=E2=80=99s policy (default + configured). =20 =20 I also broke out the management information away from the specification = information. =20 =20 Sue Hares =20 =20 From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com]=20 Sent: Wednesday, January 30, 2019 8:53 PM To: Borchert, Oliver (Fed); Susan Hares; bruno.decraene@orange.com; = Borchert, Oliver (Fed) Cc: idr@ietf.org Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Hi Oliver, Bruno and Sue, =20 To my understanding, bullet 5/5a/5b in the implementation report is = corresponding to the second paragraph in section 5 =E2=80=9CError = Handling=E2=80=9D: =20 A BGP speaker that does not advertise the BGP Extended Messages capability might also genuinely not support Extended Messages. Such a speaker MUST follow the error handling procedures of [RFC4271] if it receives an Extended Message. Similarly, any speaker that treats an improper Extended Message as a fatal error, MUST treat it similarly. =20 Thus it is to describe the error handling behavior of an implementation = version which does not support extended message.=20 =20 While I agree this could be misleading for a report of implementation = which supports extended message capability, maybe it could be used to = verify the behavior of an old version which does not support this = capability? =20 Best regards, Jie =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Borchert, Oliver = (Fed) Sent: Wednesday, January 30, 2019 4:35 AM To: Susan Hares ; bruno.decraene@orange.com; Borchert, = Oliver (Fed) Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Bruno and Susan, =20 I cannot speak for the ExaBGP Implementation but for BGPSEC-IO and = QuaggaSRx. I believe when I compiled the report, I mis-read 5a and overlooked the = =E2=80=9Cnot=E2=80=9D and read instead: =E2=80=9CDoes send Extended = Message Capability=E2=80=9D. Therefore the implementation report for section 5a must be corrected = from =E2=80=9CYes=E2=80=9D into =E2=80=9CNo=E2=80=9D for both BGPSEC-IO = and QuaggaSRx =20 BGPSEC-IO and QuaggaSRx, both do send the extended message capability if = so configured. I just checked the code and run it again. I copy/pasted the relevant = output generated by BGPSEC-IO, =20 Oliver =20 ----- output of BGPSEC-IO ------- =20 ./bgpsecio -f bgpsecio.test.cfg.qsrx=20 Starting bgpsecio 0.2.0.25... Send: (Open message send from BGPSEC-IO to QuaggaSRx)=20 OPEN Message +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF =E2=80=A6 +--Optional Parameter: Capability | +--Type: Capability (2) | +--Length: 2 | +--Capability: Extended message support capability | +--Type: Extended message support capability (6) | +--Length: 0 =E2=80=A6 =20 Received: (Open message send from QuaggaSRx and received by BGPSEC-IO) OPEN Message +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF =E2=80=A6 +--Optional Parameter: Capability +--Type: Capability (2) +--Length: 2 +--Capability: Extended message support capability +--Type: Extended message support capability (6) +--Length: 0 BGP-receiver thread created! =20 =20 =20 From: Idr on behalf of Susan Hares = Date: Tuesday, January 29, 2019 at 11:43 AM To: "bruno.decraene@orange.com" Cc: "idr@ietf.org" Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Bruno: =20 Thank you for your comments on this topic =E2=80=93 as I think=20 =20 I did receive reports privately that we have 1 full implementations of = draft-ietf-idr-bgp-extended-messages off list which is not listed in = this report. I hope those implementers will volunteer this information = on the list. If not, I will share this information with Alvaro and the = IESG. =20 =20 The SIDR work did define draft-ietf-bgp-extended-messages as a = requirement and only moved to not specifying it when we could not = quickly pass this through WG LC.=20 =20 The real needs are a growing BGP-LS that may run out of BGP message = space. As my previous email to IDR indicates, I was hoping this handles = an BGP message whose length is bigger than 4096 bytes. Thank you for = the correction of:=20 =20 =E2=80=9CThe issue is not specific to attributes bigger than 4096 = octets, but to BGP message whose length is bigger than 4096, = irrespective of the size of each attribute.=E2=80=9D =20 =20 As to your comment:=20 =20 =E2=80=9CWhy is this limited to future specifications? A priori, using = existing BGP mechanism (AFI/SAFI, attributes, * communities) one could = exceed the size of 4096 octets. How does the BGP speaker supposed to = behave in this case? This should be described in this specification. = Note that this is not a case of error handling, as every BGP speaker is = behaving as specified.=E2=80=9D =20 This problem has been true for years, and thus as co-chairs had hoped to = have the draft-ietf-bgp-extended-messages passed years ago. As BGP-LS = attributes grow use and in number, the potential of exceeding the BGP = message limit increases. It seems like a good direction to prevent = issues.=20 =20 I hope the authors will comment on the changes you suggested to the = text.=20 =20 Cheers,=20 Susan Hares=20 =20 =20 =20 From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Sent: Tuesday, January 29, 2019 8:33 AM To: Susan Hares Cc: idr@ietf.org Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Hi WG, =20 Please find below some comments. As of today, I don=E2=80=99t believe this specification is ready to be = progressed to IESG/RFC, especially for a document updating RFC 4271 = (core BGP spec). =20 > The WG chairs intend to forward this draft to the IESG with the = current level of implementation. =20 =20 https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations = = says : 5a=20 Does not send Extended Message capability=20 Yes=20 Yes=20 Yes=20 =20 I may be misunderstanding the implementation report, but my reading of = the above is that none of the reported implementations sends the = capability hence no implementation supports = draft-ietf-idr-bgp-extended-messages.. Here this document is updating = RFC 4271, so it is not a minor extension for a niche use case. So I = don=E2=80=99t see the arguments for not requiring the IDR=E2=80=99s = usual two interoperable implementations. =20 ---- =C2=A7 1 =E2=80=9C As BGP is extended to support newer AFI/SAFIs and newer capabilities (e.g., [ = I-D.ietf-sidr-bgpsec-protocol]), there is a need to extend the maximum message size beyond 4096 octets. = =E2=80=9C =20 https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on-1 = =20 =20 =20 [ = I-D.ietf-sidr-bgpsec-protocol is now RFC 8205 (thanks = for updating the reference). It has removed the normative/any reference = to draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not = need draft-ietf-idr-bgp-extended-messages. Can we have an update on this? Can the introduction of draft-ietf-idr-bgp-extended-messages be updated = to introduce on the real reasons/needs? =20 ---- =C2=A74 =C2=A73 says =E2=80=9CA peer which does not advertise this capability = MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.=E2=80=9D =20 Fine. Text in =C2=A74 should probably be aligned with the above ..e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. =20 NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and = received the Extended Message Capability to and from that peer. =20 ---- =E2=80=9C Applications generating information which might be = encapsulated within BGP messages MUST limit the size of their payload to take the maximum message size into account.=E2=80=9D =20 I don=E2=80=99t see what new behavior is been defined here. If there is = none, I would suggest to remove this sentence =20 ---- A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. =20 =20 The issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than 4096, irrespective of the size = of each attribute. Please elaborate on what you mean by =E2=80=9Can attribute which can not = be decomposed to 4096 octets=E2=80=9D =20 --- =E2=80=9C It is RECOMMENDED that BGP protocol developers and = implementers are conservative in their application and use of Extended = Messages.=E2=80=9D =20 What does this mean exactly? That they don=E2=80=99t use this extension? = That they don=E2=80=99t use this extension unless XX_TO BE SPECIFIED_XX? =20 --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages. =20 Why is this limited to future specifications? A priori, using existing = BGP mechanism (AFI/SAFI, attributes, * communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = case? This should be described in this specification. Note that this is = not a case of error handling, as every BGP speaker is behaving as = specified. =20 =20 ---- Depending on the above specification, a section describing the = operational consequences in a network (such as the Internet, BGP Enabled = ServiceS/VPN networks) is probably needed. Possible consequences could = be BGP NLRI being removed in the middle of such network, or (extended) = community (such as Route Targets) been removed. Both having significant = consequences on the availability provided by the network. =20 --- =C2=A74 OLD: The Extended Message Capability only applies to all messages except = for the OPEN message.=20 Probably NEW: The Extended Message Capability applies to all message types except = for the OPEN message (type 1).=20 ---- =C2=A78 =E2=80=9CThis extension to BGP does not change BGP's underlying security = issues =C2=BB Before evaluating this, I think this document should first specified how = a BGP messages bigger than 4096 octets is handled when it needs to be = sent to a received not supporting this extension. =20 Nits: OLD : to reduce compexity NEW : to reduce complexity =20 Thanks, --Bruno =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org Subject: [Idr] WG Last Call on Extened Message Support =20 =20 This begins a 2 week WG LC on Extended Message Support for BGP = (draft-ietf-idr-bgp-extended-messages-27). You can access the draft at: = =20 = = https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ =20 The authors should indicate whether they know of any IPR. Implementers = are encouraged to update the implementation data at:=20 =20 = = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations =20 The draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages. BGP message space is running = short for all of the potential attributes or additions proposed by = BGP-LS features. =20 =20 The WG chairs intend to forward this draft to the IESG with the current = level of implementation. =20 =20 As you comment on the draft, please consider if: a) the technology is = mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for = publication. =20 =20 Sue Hares (WG Chair, Shepherd)=20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. ------=_NextPart_000_011C_01D4C1FE.E4808970 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Oliver and Randy:

 

We are waiting your comments/revisions to complete the WG LC on = extended messages.=C2=A0 We will extend the WG LC 1 more week to receive = your answers.

 

Oliver =E2=80=93 Please update the wiki with the correct information. =

 

Randy =E2=80=93 Please respond to the questions send on the list. =

 

Thank you, Susan Hares

 

From:= = Borchert, Oliver (Fed) [mailto:oliver.borchert@nist.gov] =
Sent: Monday, February 4, 2019 10:55 AM
To: Susan = Hares
Cc: Borchert, Oliver (Fed)
Subject: Re: [Idr] = WG Last Call on Extened Message = Support

 

Hi = Susan,

I know = it=E2=80=99s not much but I want to be thorough before I post to the = list. I try today but definitely will get to this in the next days. = Still cleaning up from the government shutdown,

Oliver=

 =

From: = Susan Hares = <shares@ndzh.com>
Date: Friday, February 1, 2019 at = 10:03 AM
To: "'Dongjie (Jimmy)'" = <jie.dong@huawei.com>, "'Borchert, Oliver (Fed)'" = <oliver.borchert=3D40nist.gov@dmarc.ietf.org>, = "bruno.decraene@orange.com" <bruno.decraene@orange.com>, = Oliver Borchert <oliver.borchert@nist.gov>
Cc: = "idr@ietf.org" <idr@ietf.org>
Subject: RE: = [Idr] WG Last Call on Extened Message = Support

 

JIe, Bruno and Oliver:

 

Thank you for your input.   You are correct that the error = handling behavior was unclear based on the questions in the chart. =   The purpose of the chart is to provide other BGP WGs (Bess, = SPRING, LSVR) a clear indication of changes to the base BGP = specification.

 

I=E2=80=99ve reformatted sections 4 and 5 of the chart.  =

 

To section 4 I=E2=80=99ve added:

4c            = Does send Extended Message  - with a yes from all implementations = (based on their email)

 

Section 5, I=E2=80=99ve alter to be:

5           &nb= sp;  Error = handing           =           =

5a           = Accepts Extended message without receiving

           &nbs= p; BGP Extended Message Capability [Section 5 paragraph 1 = MAY]

           &nbs= p;            = ;            =             =

5b           If = receives Extended Message without BGP extended message = support,

            =  follows RFC4271 handling and sends Bad message length Notification =

           &nbs= p;[section 5 paragraph 2 MUST]

 

Oliver =E2=80=93 if you would read the current text and let me know = the updated message.  I believe the answer for all 3 = implementations is =E2=80=9Cyes=E2=80=9D due to 4b.   Please = let me know and I will update the information in the chart. =

 

To follow-up on Jie=E2=80=99s comments, the text did not accurately = represent the error handling.   Section 5, paragraph 1 has a = =E2=80=9CSHOULD NOT=E2=80=9D modified by a =E2=80=9CMAY=E2=80=9D, which = results in simply a =E2=80=9CMAY=E2=80=9D.   For readability, = I think the =E2=80=9CSHOULD NOT=E2=80=9D provides useful = information  to the implementer,  but it cannot be tested = accurately when combined with the =E2=80=9CMAY=E2=80=9D.  =   

 

Let me give you an example of that:

If the peer did not send a BGP Extended Message capability, and it = accepts the extended message (with a length of 10,000 bytes), it could = have a liberal policy of MAY as a default in the implementation. =   The =E2=80=9Con-wire=E2=80=9D observations cannot tell = =E2=80=93 only the implementation=E2=80=99s policy (default + = configured).   

 

I also broke out the management information away from the = specification information. 

 

Sue Hares  

 

From:= = Dongjie (Jimmy) [mailto:jie.dong@huawei.com]
Sent: Wednesday, = January 30, 2019 8:53 PM
To: Borchert, Oliver (Fed); Susan = Hares; bruno.decraene@orange.com; Borchert, Oliver (Fed)
Cc: = idr@ietf.org
Subject: RE: [Idr] WG Last Call on Extened = Message Support

 

Hi Oliver, Bruno and = Sue,

 

To my understanding, bullet 5/5a/5b in the = implementation report is corresponding to the second paragraph in = section 5 =E2=80=9CError Handling=E2=80=9D:

 

A BGP speaker that does not advertise the = BGP Extended Messages

   capability might also = genuinely not support Extended Messages.  = Such

   a speaker MUST follow the = error handling procedures of [RFC4271] if

   it receives an Extended = Message.  Similarly, any speaker that = treats

   an improper Extended Message = as a fatal error, MUST treat it

   = similarly.

 

Thus it is to describe the error handling = behavior of an implementation version which does not support extended = message.

 

While I agree this could be misleading for = a report of implementation which supports extended message capability, = maybe it could be used to verify the behavior of an old version which = does not support this capability?

 

Best regards,

Jie

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of = Borchert, Oliver (Fed)
Sent: Wednesday, January 30, 2019 = 4:35 AM
To: Susan Hares <shares@ndzh.com>; = bruno.decraene@orange.com; Borchert, Oliver (Fed) = <oliver.borchert@nist.gov>
Cc: = idr@ietf.org
Subject: Re: [Idr] WG Last Call on Extened = Message Support

 

Bruno and Susan,

 

I cannot speak for the ExaBGP Implementation but for = BGPSEC-IO and QuaggaSRx.

I believe when I compiled the report, I mis-read 5a and = overlooked the =E2=80=9Cnot=E2=80=9D and read instead: =E2=80=9CDoes = send Extended Message Capability=E2=80=9D.

Therefore the implementation report for section 5a must = be corrected from =E2=80=9CYes=E2=80=9D into =E2=80=9CNo=E2=80=9D for = both BGPSEC-IO and QuaggaSRx

 

BGPSEC-IO and QuaggaSRx, both do send the extended = message capability if so configured.

I just checked the code and run it again. I copy/pasted = the relevant output generated by BGPSEC-IO,

 

Oliver

 

-----  output of BGPSEC-IO  = -------

 

./bgpsecio -f bgpsecio.test.cfg.qsrx =

Starting bgpsecio 0.2.0.25...

Send:  (Open message send from BGPSEC-IO to = QuaggaSRx)

OPEN Message

  +--marker: = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

=E2=80=A6

     +--Optional Parameter: = Capability

     |  +--Type: Capability = (2)

     |  +--Length: = 2

     |  +--Capability: Extended = message support capability

     |     = +--Type: Extended message support capability (6)

     |     = +--Length: 0

=E2=80=A6

 

Received: (Open message send from QuaggaSRx and received = by BGPSEC-IO)

OPEN Message

  +--marker: = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

=E2=80=A6

     +--Optional Parameter: = Capability

        +--Type: = Capability (2)

        +--Length: = 2

        = +--Capability: Extended message support = capability

         &nb= sp; +--Type: Extended message support capability = (6)

         &nb= sp; +--Length: 0

BGP-receiver thread created!

 

 

 

From: Idr <idr-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
Date: = Tuesday, January 29, 2019 at 11:43 AM
To: "bruno.decraene@orange.com&q= uot; <bruno.decraene@orange.com&g= t;
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: = [Idr] WG Last Call on Extened Message = Support

 <= /o:p>

Bruno:

 

Thank you for your = comments on this topic =E2=80=93 as I think

 

I did receive reports = privately that we have 1 full implementations of = draft-ietf-idr-bgp-extended-messages off list which is not listed in = this report.   I hope those implementers will volunteer this = information on the list.   If not, I will share this = information with Alvaro and the IESG.  =  

 

The SIDR work did define = draft-ietf-bgp-extended-messages as a requirement and only moved to not = specifying it when we could not quickly pass this through WG LC. =

 

The real needs are a = growing BGP-LS that may run out of BGP message space.  As my = previous email to IDR indicates, I was hoping this handles an BGP = message whose length is bigger than 4096 bytes.   Thank you = for the correction of:

 

=E2=80=9CThe issue is not = specific to attributes bigger than 4096 octets, but to BGP message whose = length is bigger than 4096, irrespective of the size of each = attribute.=E2=80=9D

 

=

 

=

As to your comment: =

 

=

=E2=80=9CWhy is this limited to future = specifications? A priori, using existing BGP mechanism (AFI/SAFI, = attributes, * communities) one could exceed the size of 4096 octets. How = does the BGP speaker supposed to behave in this case? This should be = described in this specification. Note that this is not a case of error = handling, as every BGP speaker is behaving as = specified.=E2=80=9D

 

This problem has been true for years, = and thus as co-chairs had hoped to have the = draft-ietf-bgp-extended-messages passed years ago.   As BGP-LS = attributes grow use and in number, the potential of exceeding the BGP = message limit increases.  It seems like a good direction to prevent = issues.

 

I hope the authors will comment on the = changes you suggested to the text.

 

Cheers,

Susan Hares

 

=

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.co= m]
Sent: Tuesday, January 29, 2019 8:33 AM
To: = Susan Hares
Cc: idr@ietf.org
Subject: RE: = [Idr] WG Last Call on Extened Message = Support

 

Hi WG,

 

Please find below some comments.

As of today, I don=E2=80=99t believe this specification is = ready to be progressed to IESG/RFC, especially for a document updating = RFC 4271 (core BGP spec).

 

> The WG chairs intend to forward this = draft to the IESG with the current level of implementation.  =

 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-= extended-implementations says : 5a

Does not = send Extended Message capability

Yes =

Yes

Yes =

 

I may be misunderstanding the implementation report, but = my reading of the above is that none of the reported implementations = sends the capability hence no implementation supports = draft-ietf-idr-bgp-extended-messages.. Here this document is updating = RFC 4271, so it is not a minor extension for a niche use case. So I = don=E2=80=99t see the arguments for not requiring the IDR=E2=80=99s = usual two interoperable implementations.

 

----

=C2=A7 1

=E2=80=9C As BGP is extended to support = newer AFI/SAFIs and

   newer capabilities (e.g., = [I-D.ietf-sidr-bgpsec-protocol]), there is

   a need to extend the = maximum message size beyond 4096 octets.  = =E2=80=9C

 

https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-mes= sages-27#section-1

 

 

[I-D.ietf-sidr-bgpsec-protocol is now RFC 8205 (thanks for updating the reference). It = has removed the normative/any reference to = draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not = need draft-ietf-idr-bgp-extended-messages.

Can we have an update on this?

Can the introduction of draft-ietf-idr-bgp-extended-messages be updated to = introduce on the real reasons/needs?

 

----

=C2=A74

=C2=A73 says =E2=80=9CA peer which does not advertise this =
capability MUST NOT send BGP

   Extended Messages, and BGP = Extended Messages MUST NOT be sent to it.=E2=80=9D

 

Fine. Text in =C2=A74 should probably be = aligned with the above ..e.g.

OLD: A BGP speaker

   MAY send Extended Messages = to its peer only if it has received the

   Extended Message = Capability from that peer.

 

NEW:

A BGP speaker

   MAY send Extended Messages = to its peer only if it has sent and received the

   Extended Message = Capability to and from that peer.

 

----

=E2=80=9C   Applications generating =
information which might be encapsulated

   within BGP messages MUST = limit the size of their payload to take the

   maximum message size into = account.=E2=80=9D

 

I don=E2=80=99t see what new behavior is been defined = here. If there is none, I would suggest to remove this = sentence

 

----

   A BGP announcement will, = in the normal case, propagate throughout the

   BGP speaking Internet; and = there will undoubtedly be BGP speakers

   which do not have the = Extended Message capability.  Therefore,

   putting an attribute which = can not be decomposed to 4096 octets or

   less in an Extended = Message is a likely path to routing failure.

 

 

The issue is not specific to attributes bigger = than 4096 octets, but to BGP message whose length is bigger than 4096, = irrespective of the size of each attribute.

Please elaborate on what you mean by = =E2=80=9Can attribute which can not be = decomposed to 4096 octets=E2=80=9D

 

---

=E2=80=9C   It is RECOMMENDED = that BGP protocol developers and implementers = are

   conservative in their = application and use of Extended = Messages.=E2=80=9D

 

What does this mean exactly? That they don=E2=80=99t use = this extension? That they don=E2=80=99t use this extension unless XX_TO = BE SPECIFIED_XX?

 

---

  Future protocol specifications = will need to describe how to handle

   peers which can only = accommodate 4096 octet messages.

 

Why is this limited to future specifications? A priori, = using existing BGP mechanism (AFI/SAFI, attributes, * communities) one = could exceed the size of 4096 octets. How does the BGP speaker supposed = to behave in this case? This should be described in this specification. = Note that this is not a case of error handling, as every BGP speaker is = behaving as specified.

 

 

----

Depending on the above specification, a = section describing the operational consequences in a network (such as = the Internet, BGP Enabled ServiceS/VPN networks) is probably needed. = Possible consequences could be BGP NLRI being removed in the middle of = such network, or (extended) community (such as Route Targets) been = removed. Both having significant consequences on the availability = provided by the network.

 

---

=C2=A74

OLD: The Extended Message Capability = only applies to all messages except for the OPEN message. =

Probably

NEW: The Extended Message Capability = applies to all message types except for the OPEN message (type 1). =

----

=C2=A78

=E2=80=9CThis extension to BGP does not =
change BGP's underlying security =
issues =C2=BB
Before evaluating this, I think this =
document should first specified how a BGP messages bigger than 4096 =
octets is handled when it needs to be sent to a received not supporting =
this extension.

 

Nits:

OLD : to reduce = compexity

NEW : to reduce = complexity

 

Thanks,

--Bruno

 

From: Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Tuesday, January 29, = 2019 12:33 PM
To: idr@ietf.org
Subject: [Idr] = WG Last Call on Extened Message = Support

 

 

This begins a 2 week WG LC on Extended Message = Support for BGP (draft-ietf-idr-bgp-extended-messages-27).  You can = access the draft at:

 

https://datat= racker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

 

The authors should indicate whether they know = of any IPR.   Implementers are encouraged to update the  = implementation data at:

 

https://trac.= ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations=

 

The draft provides a means for expanding the = BGP message to 65535 octets for all messages except OPEN messages.  = BGP message space is running short for all of the potential attributes = or additions proposed by BGP-LS features. 

 

The WG chairs intend to forward this draft to = the IESG with the current level of implementation.  =

 

As you comment on the draft, please consider = if: a) the technology is mature, b) the additional space in a BGP = message would be helpful for those deploying BGP-LS or SR, and c) if the = specification is ready for publication. 

 

Sue Hares (WG Chair, Shepherd) =

 

 

_______________________________________________________________________=
__________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le =
signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or =
privileged information that may be protected by =
law;
they should not be distributed, used or copied without =
authorisation.
If you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
------=_NextPart_000_011C_01D4C1FE.E4808970-- From nobody Mon Feb 11 15:17:08 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F25131155 for ; Mon, 11 Feb 2019 15:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.512 X-Spam-Level: X-Spam-Status: No, score=-12.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cQ6DThIG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZKIHe/Ne Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-7jBfAxfWGq for ; Mon, 11 Feb 2019 15:17:01 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2658A1200D8 for ; Mon, 11 Feb 2019 15:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=127723; q=dns/txt; s=iport; t=1549927021; x=1551136621; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xiQ5ZlKBq3si4LgWELv1v0vg7XCT98bw2e85ZdHQR0M=; b=cQ6DThIGitpMT1yHJyQzl88dNE/mEmtxXkzC6fLRWPB2uUvvI8K1el0P bwa1fUuSQjmNzKwMCU0vfCsWry4y9P7LzEOSPSbk0n8Hp8YbGW/ZdkwMS iibqXHS6MoPHLFvNNKT1A1zRAI4JAbnzebFQMf2kIeNj3sWPiSskM9U4B M=; IronPort-PHdr: =?us-ascii?q?9a23=3AjrLwBRT9hYs7Val6Zc4TTmhoytpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUDNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOi46EcVeRndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACwAWJc/5hdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgQ0jUANndAQLJwqDeoFfgWgDj3eCV3y?= =?us-ascii?q?XFxSBEANUCwEBIgqBBV2CXgIXgygiNQgNAQMBAQIBAQJtHAyFSgEBAQECARo?= =?us-ascii?q?BCAoTAQE3AQQLAgEIDgMDAQEBFgsBBgMCAgIwFAkIAgQOBRSDCwQBAYEdTAM?= =?us-ascii?q?NBwEBDqA/AooUcYEvgngBAQWBMAETQYMBAxWCCwMFjEMXgUA/gRABJx+CFwc?= =?us-ascii?q?ugx4BAQIBARaBAhIBCwEGAQcvCQYGAQkJgkoxgiaJZRgBCgcghW+HE4twCQK?= =?us-ascii?q?HNosYGYFtgXaDVWmCVYdqi0KEMIwjAgQCBAUCDQEBBYFIATUNWHFwFTsqAYJ?= =?us-ascii?q?BE4FlJAkDBRKDS4UUhT9yAQEBAYEkikEBDheBCAExbQEB?= X-IronPort-AV: E=Sophos;i="5.58,360,1544486400"; d="scan'208,217";a="513348954" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2019 23:16:58 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x1BNGwMq002179 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Feb 2019 23:16:58 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 11 Feb 2019 17:16:57 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 11 Feb 2019 18:16:56 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 11 Feb 2019 17:16:56 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xiQ5ZlKBq3si4LgWELv1v0vg7XCT98bw2e85ZdHQR0M=; b=ZKIHe/NeEhepemSOPiEA/uaXwV/fWf1DcPZVxVTt62hYzJHicCau/x+xrV+T3OHhmnWxYjhEf6lQEq+0I37hUS3we3T/Rd+Hkss0V2gTIq/Jgg4LZa9mWO8wSQfl3SPWpO+/2DLcoKoS01c0bTnNkluQYjrtS7vEgY7OIbBT/2w= Received: from BN6PR11MB2050.namprd11.prod.outlook.com (10.173.26.20) by BN6PR11MB0003.namprd11.prod.outlook.com (10.161.158.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.19; Mon, 11 Feb 2019 23:16:54 +0000 Received: from BN6PR11MB2050.namprd11.prod.outlook.com ([fe80::55bb:9b28:e053:42d7]) by BN6PR11MB2050.namprd11.prod.outlook.com ([fe80::55bb:9b28:e053:42d7%12]) with mapi id 15.20.1601.023; Mon, 11 Feb 2019 23:16:54 +0000 From: "Jakob Heitz (jheitz)" To: Susan Hares CC: "Dongjie (Jimmy)" , "Borchert, Oliver (Fed)" , "bruno.decraene@orange.com" , "Borchert, Oliver (Fed)" , "idr@ietf.org" Thread-Topic: [Idr] WG Last Call on Extened Message Support Thread-Index: AdS3xjQ/tSoF1syoSCC0lUpnr5BmnQACO/8QABUu6QAACB5qAAA9Z2KAAE3h5wAAIOhfgABz6gyAAVYD7AAAEMH5LQ== Date: Mon, 11 Feb 2019 23:16:53 +0000 Message-ID: <1E129C92-97F7-4E25-AB5B-6E9A921D679D@cisco.com> References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <009501d4b7f1$962d0080$c2870180$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927C3286B43@NKGEML515-MBX.china.huawei.com> <00e201d4ba3f$34bb67b0$9e323710$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927C32AEB75@NKGEML515-MBS.china.huawei.com> , <00de01d4c21c$d91e6e30$8b5b4a90$@ndzh.com> In-Reply-To: <00de01d4c21c$d91e6e30$8b5b4a90$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com; x-originating-ip: [1.127.109.217] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b0a337f-3bce-4f13-1664-08d6907702af x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BN6PR11MB0003; x-ms-traffictypediagnostic: BN6PR11MB0003: x-ms-exchange-purlcount: 7 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjExTUIwMDAzOzIzOmVWVTVkV0dKRzFBZlRqYzhlMTJQbjR4N0RX?= =?utf-8?B?cjdsZFhXcnlhTXdIZEdrUDEzM2VjbGs4ZTJ0VCt3cGtPSzJqdzZtZ2tBY3ZP?= =?utf-8?B?T3hSK1pvSURmbkZwMW9jcDhFc3B1Sm9WdjlNQjJzbkN0T3Zwa3VLcUJhSzVS?= =?utf-8?B?dkFBRUYweHAvejkrMXZJR0Z0cTgzdXJhd1NTSDJmbEFkSjVBZXBBTDhSYWd5?= =?utf-8?B?dkVXUlFYVlo4QmhEY2QvNExHbElvSnZ5Z2tQbjVYMnFKSkFGY0xXRW81anNI?= =?utf-8?B?ajBCNmVjbU9tbXliV1B1NzlHazY3TXpKSEtaU0loQ1QwT3NoSzA5Z3l5aUxm?= =?utf-8?B?MXd1Njk3UDgxbHFRNXE5YWJ6Y2tKV0p1eVVlMHpQVy8xYkQxR3V4M1lYS01V?= =?utf-8?B?SnhUdFZ1S0tKaFlHbTJQTWRLalp1aGptSW4raVB2ZHdVQWJuNDdRaEVmdDRW?= =?utf-8?B?aGpaV2VYRTZFTThmM1RyanpMVDhEV2tGUVNmY1k2VWE0eHNESnRRR2sxTTRx?= =?utf-8?B?bnlCSm0yZ3dUUFIvODlqNkdsNFRyU04rcGtJdXdEVUNpdFhYSXdkK012L1RC?= =?utf-8?B?eUhHTlZ4dS9BQkhJdXowcDhvL2Z6Y2tCckxBdkJERnlHbEpkM2ViSXhoM0dl?= =?utf-8?B?bnEybWZNa1pCMlFxcEltNW1xNmo0dWh5aStSZDFvY0FaT3l4S2hUb3B2NXBZ?= =?utf-8?B?alhvcGh5MHFTOWFBR0FSbC9CQ3FQSGZvVFhhWDEycFR3NURWYkxFclFpQ1pF?= =?utf-8?B?bm0xTFNXc1Z1K0F6Zk9OVTI3YlNvUnUxUFBKWmJFelVONGR1ait1OEJUTXNv?= =?utf-8?B?VUdCdE9rck5Mcmt5VUlMYU9JTFlBbFo3eDNRYi9YT3JiejVRQUxJSmdnb1Rp?= =?utf-8?B?NlVoYkNyUzdRZFNXSk1yeTg4L1VhWkNSZ2hzSU56MWhRRjBwZys4V3RpOWlJ?= =?utf-8?B?RUt6ZVh2VjFhWWVjTi9MUXVQeklLSDJwOUk1akdhNFA2dG13MFY4UWkwSFJY?= =?utf-8?B?MnRpeFpvSys2RUdWVFRLM3VYY1BpbjBOSU5DYldFaDVvaDV5RlBsTDRTTmdD?= =?utf-8?B?TUU1TjlvSWU0Q1p5ZzRTdUNLRFpxMVc4UkF6eWJYOUNwZFpkZWlBWmlQY0gz?= =?utf-8?B?bFdyaTc1WVhoNjU0K25XdXllbVY4ZlgyNkhVTVJ3MXpkQnlKWklQUXdBeHF0?= =?utf-8?B?cjhDdWdlck5rS09FdSsyR3JabGg1S2R3Y1d2dHdUazQrRzRnYnMwOUVWb05B?= =?utf-8?B?T3g3VHVUNDV6c2NhOHIvalQ0b3dpR2pxaWZZclFQVWFOVkwzakowek1YZTds?= =?utf-8?B?M0NhSnVOK3pjSUpUL1V3VUdIVElieDJpa2dtc3Znb09ESUhoZTQzaUlkMU5i?= =?utf-8?B?KzBYaE9CcFBSTGxsSCs4dmhJbE0xNmV2M2d1Sjg2UWE3Mnh4d1hJS3dYY2VM?= =?utf-8?B?UElLdm1vV3FpdGFJd09ybTdqcGhUODBZU2R1Mm5SVm8zbEkvaFEyaEVpa2NE?= =?utf-8?B?RnBtVUZuR1pGYU1oeWxHbGNuZkVZZXNSdTZFQ0Jabyt3Qk1CRko2QzZlR3dx?= =?utf-8?B?MHM4V2htODgxWHdYNXh6MjJwNWYzQXhkTndaVytoVHQrRlhjalJLSUVDNGZv?= =?utf-8?B?OUVnR3gvMXlxbE1TY21ST3B0T3RtdkNBUnR4cGI3NW43YjdoODdkSHlhbkVw?= =?utf-8?B?Zlh1eEw1Mytnamp2MEhQMVFEbUovNUNlZ1ZYSEdoQzNiS24yZEtoMk8vdStB?= =?utf-8?B?VGdLc2s3aDVlbFlqN2lxOXFtVUczdjdWOURZOGI2L1RQcW4wTmd3SDl4SE4z?= =?utf-8?B?NVBSdk95bzNQUUpPNnNaRklhNWZRNjhJa0ZMd3R0YVA4Wng2R203TStndXhz?= =?utf-8?B?bHkrRVpzZUNPOUgyMkhxdDAxSEhKNXBRMjc2OUMyNGxzdzd0WWN4R0pWa0tl?= =?utf-8?B?bmZ6YWtzL3dTK2o1dXpqVG9qbVkyV3lPMTl5YmhKbVczZWJBa3pFTlJod1hI?= =?utf-8?B?R0pENHdyTjdKMTloVWV5RDVWdVdDZnhleDZLZGtlZVJadzluYWlWTTZGT2ow?= =?utf-8?Q?QLyY=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(396003)(136003)(39860400002)(129404003)(189003)(199004)(66066001)(82746002)(446003)(105586002)(606006)(30864003)(86362001)(33656002)(186003)(106356001)(93886005)(790700001)(3846002)(6116002)(486006)(53936002)(25786009)(2616005)(476003)(11346002)(6916009)(478600001)(102836004)(26005)(6306002)(54896002)(6512007)(236005)(53946003)(71190400001)(71200400001)(6486002)(2906002)(81166006)(81156014)(14444005)(83716004)(6436002)(229853002)(316002)(5024004)(14454004)(8936002)(256004)(68736007)(66574012)(4326008)(97736004)(7736002)(966005)(54906003)(6506007)(53546011)(76176011)(6246003)(99286004)(15650500001)(36756003)(8676002)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB0003; H:BN6PR11MB2050.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kTDoC084zsA71ZaGc0hFrcpPyd7s/7UjmIkOcfr5TBu4uNwtSM14sfYI8Ob3ysjjbU1YmYliXdNDufksR0dY14yphRMDrnJL6fLBaofRrI70327HekjHCbHVdWAdwXytEplHWj7H/mqPK7ucwUyY8A7+dVDm42nyxss4/WY303Xse2Ay+WXdfVTGCSHLi85lIRHwTAhJJDDFfNOEZ7IAEaQQITKdf77tv4nXEYl7bWqKvd8pQLUWlo6adtfQwMBBTTXXPb+Tn2esrTISJmHuph0F8xQPtENQcQzzuJmxURxSsq0Xc8obxJndywuPVCjYX8NsOFNkEO/sWNQ5ZjJFdB7fT28Tjgx/52WNmfjJWzMDYNhSWF1sYT6najg9hWOgWe0XqXJ8c63OcDivnItIpf3gAPyCNsvxyfQpAiO234E= Content-Type: multipart/alternative; boundary="_000_1E129C9297F74E25AB5B6E9A921D679Dciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2b0a337f-3bce-4f13-1664-08d6907702af X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2019 23:16:53.8069 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB0003 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 23:17:06 -0000 --_000_1E129C9297F74E25AB5B6E9A921D679Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VlLA0KDQpTb3JyeSBpZiBJJ20gYSBiaXQgYmVoaW5kLCBidXQgY291bGQgeW91IGVsYWJvcmF0 ZSB0aGUgcHJvYmxlbSB3aXRoIEJHUC1MUyBwbGVhc2UuIENhbiB5b3UgZ2l2ZSBzb21lIGV4YW1w bGVzIG9mIGEgQkdQLUxTIE5MUkkgYW5kIGFzc29jaWF0ZWQgcGF0aCBhdHRyaWJ1dGUgdGhhdCB3 aWxsIG5vdCBmaXQgNDA5NiBieXRlcz8NCg0KVGhhbmtzLA0KSmFrb2IuDQoNCg0KT24gRmViIDEx LCAyMDE5LCBhdCAxMToxOCBQTSwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86 c2hhcmVzQG5kemguY29tPj4gd3JvdGU6DQoNCkpha29iOg0KDQpUaGFua3MgZm9yIG1lbnRpb25p bmcgdGhlIGNvcnJlY3QgaW5mb3JtYXRpb24gdGhlIEJHUFNlYyBhcyBmYXIgYXMgdGhlIHNwZWNp ZmljYXRpb25zLiAgV2hldGhlciBvciBub3QgdGhlIFJTQS0yMDQ4IHdvdWxkIGhhdmUgYmVlbiB1 c2VmdWwgdG8gQkdQU2VjLCBpcyBsZWZ0IGZvciB0aGUgT1BTIGdyb3VwIGhhbmRsaW5nIFNJRFIg ZGVwbG95bWVudC4NCg0KVGhlIGZvY3VzIG9mIHRoaXMgZGlzY3Vzc2lvbiBpcyB0byByZW1vdmUg YW55IGZ1dHVyZSBvYnN0YWNsZXMgdG8gdGhlIHVzZSBvZiBCR1AtTFMgYXR0cmlidXRlcy9OTFJJ LiAgVHdvIHBvdGVudGlhbCBsaW1pdHMgZXhpc3Q6ICBhKSBtZXNzYWdlIHNpemUgKGdyZWF0ZXIg dGhhbiA0MDk2KSBhbmQgYikgZXJyb3IgaGFuZGxpbmcuDQoNClN1ZSBIYXJlcw0KDQpGcm9tOiBJ ZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpha29iIEhlaXR6 IChqaGVpdHopDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDQsIDIwMTkgMzoxNCBQTQ0KVG86IERv bmdqaWUgKEppbW15KTsgU3VzYW4gSGFyZXM7ICdCb3JjaGVydCwgT2xpdmVyIChGZWQpJzsgYnJ1 bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT47 ICdCb3JjaGVydCwgT2xpdmVyIChGZWQpJw0KQ2M6IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3Nh Z2UgU3VwcG9ydA0KDQpCR1BTZWMgZHJvcHBlZCB0aGUgcmVxdWlyZW1lbnQgZm9yIGV4dGVuZGVk IG1lc3NhZ2VzIGJlY2F1c2UgdGhlDQpzaWduYXR1cmUgd2FzIGNoYW5nZWQgZnJvbSBSU0EtMjA0 OCAoMjU2IGJ5dGUgc2lnKSB0byBFQ0RTQSBQLTI1NiAoNjQgYnl0ZSBzaWcpLg0KaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zaWRyL0xSSFB1TzVNRjB1LXZXdWhOQVZlVk5f OGZJVQ0KDQpUaGVyZSBpcyBubyBtZW50aW9uIG9mIGV4dGVuZGVkIG1lc3NhZ2VzIGluIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MjA1DQpBbGwgbWVudGlvbiBvZiBpdCB3YXMgc3Ry dWNrIG91dCBpbjoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtc2lkci1iZ3BzZWMtcHJvdG9jb2wtMjMudHh0DQoNClJlZ2FyZHMsDQpKYWtvYi4NCg0KRnJv bTogSWRyIDxpZHItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc+ PiBPbiBCZWhhbGYgT2YgRG9uZ2ppZSAoSmltbXkpDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDEs IDIwMTkgMTA6NDUgUE0NClRvOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpz aGFyZXNAbmR6aC5jb20+PjsgJ0JvcmNoZXJ0LCBPbGl2ZXIgKEZlZCknIDxvbGl2ZXIuYm9yY2hl cnQ9NDBuaXN0LmdvdkBkbWFyYy5pZXRmLm9yZzxtYWlsdG86b2xpdmVyLmJvcmNoZXJ0PTQwbmlz dC5nb3ZAZG1hcmMuaWV0Zi5vcmc+PjsgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86 YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT47ICdCb3JjaGVydCwgT2xpdmVyIChGZWQpJyA8b2xp dmVyLmJvcmNoZXJ0QG5pc3QuZ292PG1haWx0bzpvbGl2ZXIuYm9yY2hlcnRAbmlzdC5nb3Y+Pg0K Q2M6IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJZHJd IFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydA0KDQpIaSBTdWUsDQoNClRo YW5rcyBmb3IgdXBkYXRpbmcgdGhlIGltcGxlbWVudGF0aW9uIHJlcG9ydC4NCg0KTXkgdW5kZXJz dGFuZGluZyB3YXMgdGhhdCBidWxsZXQgNCB3YXMgdG8gY292ZXIgdGhlIGJlaGF2aW9yIG9mIHNl Y3Rpb24gNSBwYXJhZ3JhcGggMSwgYnVsbGV0IDUgd2FzIHRvIGNvdmVyIHRoZSBiZWhhdmlvciBv ZiBzZWN0aW9uIDUgcGFyYWdyYXBoIDIuDQoNCkJ1dCBhZnRlciByZXJlYWRpbmcgc2VjdGlvbiA1 LCBJIHJlYWxpemUgdGhhdCBib3RoIHBhcmFncmFwaCAxIGFuZCAyIGFyZSB0YWxraW5nIGFib3V0 IHRoZSBiZWhhdmlvciBvZiBhIEJHUCBzcGVha2VyIHdoaWNoIGRvZXMgbm90IGFkdmVydGlzZSB0 aGUgZXh0ZW5kZWQgbWVzc2FnZSBjYXBhYmlsaXR5IHRvIGl0cyBwZWVyLCBzbyBwZXJoYXBzIGJ1 bGxldHMgNCBhbmQgNSBpbiB0aGUgaW1wbGVtZW50YXRpb24gcmVwb3J0IGNvdWxkIGJlIG1lcmdl ZCBhcyBiZWxvdzoNCg0KNC4gV2hlbiByZWNlaXZlcyBhbiBleHRlbmRlZCBtZXNzYWdlIHdpdGhv dXQgYWR2ZXJ0aXNpbmcgdGhlIEJHUCBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgdG8gdGhp cyBwZWVyIChFcnJvciBIYW5kbGluZykuDQo0YS4gQWNjZXB0cyB0aGUgZXh0ZW5kZWQgbWVzc2Fn ZSBpZiB0aGUgQkdQIHNwZWFrZXIgaXMgYWJsZSB0byBwcm9jZXNzIGV4dGVuZGVkIG1lc3NhZ2Ug KGJ1dCB3YXMgY29uZmlndXJlZCBub3QgdG8gYWR2ZXJ0aXNlIHRoZSBjYXBhYmlsaXR5KSAgIFtT ZWN0aW9uIDUsIHBhcmFncmFwaCAxIE1BWV0NCjRiLiBEb2VzIG5vdCBhY2NlcHQgdGhlIGV4dGVu ZGVkIG1lc3NhZ2UsIGZvbGxvd3MgUkZDNDI3MSBoYW5kbGluZyBhbmQgc2VuZHMgQmFkIE1lc3Nh Z2UgTGVuZ3RoIE5vdGlmaWNhdGlvbiBbU2VjdGlvbiA1LCBwYXJhZ3JhcGggMSBTSE9VTEQgTk9U LCBhbmQgcGFyYWdyYXBoIDIgTVVTVCkNCg0KSG9wZSB0aGlzIGhlbHBzIHRvIHJlZHVjZSB0aGUg Y29uZnVzaW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpKaWUNCg0KDQpGcm9tOiBTdXNhbiBIYXJlcyBb bWFpbHRvOnNoYXJlc0BuZHpoLmNvbV0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDEsIDIwMTkg MTE6MDMgUE0NClRvOiBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5jb208bWFpbHRv OmppZS5kb25nQGh1YXdlaS5jb20+PjsgJ0JvcmNoZXJ0LCBPbGl2ZXIgKEZlZCknIDxvbGl2ZXIu Ym9yY2hlcnQ9NDBuaXN0LmdvdkBkbWFyYy5pZXRmLm9yZzxtYWlsdG86b2xpdmVyLmJvcmNoZXJ0 PTQwbmlzdC5nb3ZAZG1hcmMuaWV0Zi5vcmc+PjsgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxt YWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT47ICdCb3JjaGVydCwgT2xpdmVyIChGZWQp JyA8b2xpdmVyLmJvcmNoZXJ0QG5pc3QuZ292PG1haWx0bzpvbGl2ZXIuYm9yY2hlcnRAbmlzdC5n b3Y+Pg0KQ2M6IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0KU3ViamVjdDogUkU6 IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydA0KDQpKSWUsIEJy dW5vIGFuZCBPbGl2ZXI6DQoNClRoYW5rIHlvdSBmb3IgeW91ciBpbnB1dC4gICBZb3UgYXJlIGNv cnJlY3QgdGhhdCB0aGUgZXJyb3IgaGFuZGxpbmcgYmVoYXZpb3Igd2FzIHVuY2xlYXIgYmFzZWQg b24gdGhlIHF1ZXN0aW9ucyBpbiB0aGUgY2hhcnQuICAgVGhlIHB1cnBvc2Ugb2YgdGhlIGNoYXJ0 IGlzIHRvIHByb3ZpZGUgb3RoZXIgQkdQIFdHcyAoQmVzcywgU1BSSU5HLCBMU1ZSKSBhIGNsZWFy IGluZGljYXRpb24gb2YgY2hhbmdlcyB0byB0aGUgYmFzZSBCR1Agc3BlY2lmaWNhdGlvbi4NCg0K SeKAmXZlIHJlZm9ybWF0dGVkIHNlY3Rpb25zIDQgYW5kIDUgb2YgdGhlIGNoYXJ0Lg0KDQpUbyBz ZWN0aW9uIDQgSeKAmXZlIGFkZGVkOg0KNGMgICAgICAgICAgICBEb2VzIHNlbmQgRXh0ZW5kZWQg TWVzc2FnZSAgLSB3aXRoIGEgeWVzIGZyb20gYWxsIGltcGxlbWVudGF0aW9ucyAoYmFzZWQgb24g dGhlaXIgZW1haWwpDQoNClNlY3Rpb24gNSwgSeKAmXZlIGFsdGVyIHRvIGJlOg0KNSAgICAgICAg ICAgICAgRXJyb3IgaGFuZGluZw0KNWEgICAgICAgICAgIEFjY2VwdHMgRXh0ZW5kZWQgbWVzc2Fn ZSB3aXRob3V0IHJlY2VpdmluZw0KICAgICAgICAgICAgIEJHUCBFeHRlbmRlZCBNZXNzYWdlIENh cGFiaWxpdHkgW1NlY3Rpb24gNSBwYXJhZ3JhcGggMSBNQVldDQoNCjViICAgICAgICAgICBJZiBy ZWNlaXZlcyBFeHRlbmRlZCBNZXNzYWdlIHdpdGhvdXQgQkdQIGV4dGVuZGVkIG1lc3NhZ2Ugc3Vw cG9ydCwNCiAgICAgICAgICAgICBmb2xsb3dzIFJGQzQyNzEgaGFuZGxpbmcgYW5kIHNlbmRzIEJh ZCBtZXNzYWdlIGxlbmd0aCBOb3RpZmljYXRpb24NCiAgICAgICAgICAgIFtzZWN0aW9uIDUgcGFy YWdyYXBoIDIgTVVTVF0NCg0KT2xpdmVyIOKAkyBpZiB5b3Ugd291bGQgcmVhZCB0aGUgY3VycmVu dCB0ZXh0IGFuZCBsZXQgbWUga25vdyB0aGUgdXBkYXRlZCBtZXNzYWdlLiAgSSBiZWxpZXZlIHRo ZSBhbnN3ZXIgZm9yIGFsbCAzIGltcGxlbWVudGF0aW9ucyBpcyDigJx5ZXPigJ0gZHVlIHRvIDRi LiAgIFBsZWFzZSBsZXQgbWUga25vdyBhbmQgSSB3aWxsIHVwZGF0ZSB0aGUgaW5mb3JtYXRpb24g aW4gdGhlIGNoYXJ0Lg0KDQpUbyBmb2xsb3ctdXAgb24gSmll4oCZcyBjb21tZW50cywgdGhlIHRl eHQgZGlkIG5vdCBhY2N1cmF0ZWx5IHJlcHJlc2VudCB0aGUgZXJyb3IgaGFuZGxpbmcuICAgU2Vj dGlvbiA1LCBwYXJhZ3JhcGggMSBoYXMgYSDigJxTSE9VTEQgTk9U4oCdIG1vZGlmaWVkIGJ5IGEg 4oCcTUFZ4oCdLCB3aGljaCByZXN1bHRzIGluIHNpbXBseSBhIOKAnE1BWeKAnS4gICBGb3IgcmVh ZGFiaWxpdHksIEkgdGhpbmsgdGhlIOKAnFNIT1VMRCBOT1TigJ0gcHJvdmlkZXMgdXNlZnVsIGlu Zm9ybWF0aW9uICB0byB0aGUgaW1wbGVtZW50ZXIsICBidXQgaXQgY2Fubm90IGJlIHRlc3RlZCBh Y2N1cmF0ZWx5IHdoZW4gY29tYmluZWQgd2l0aCB0aGUg4oCcTUFZ4oCdLg0KDQpMZXQgbWUgZ2l2 ZSB5b3UgYW4gZXhhbXBsZSBvZiB0aGF0Og0KSWYgdGhlIHBlZXIgZGlkIG5vdCBzZW5kIGEgQkdQ IEV4dGVuZGVkIE1lc3NhZ2UgY2FwYWJpbGl0eSwgYW5kIGl0IGFjY2VwdHMgdGhlIGV4dGVuZGVk IG1lc3NhZ2UgKHdpdGggYSBsZW5ndGggb2YgMTAsMDAwIGJ5dGVzKSwgaXQgY291bGQgaGF2ZSBh IGxpYmVyYWwgcG9saWN5IG9mIE1BWSBhcyBhIGRlZmF1bHQgaW4gdGhlIGltcGxlbWVudGF0aW9u LiAgIFRoZSDigJxvbi13aXJl4oCdIG9ic2VydmF0aW9ucyBjYW5ub3QgdGVsbCDigJMgb25seSB0 aGUgaW1wbGVtZW50YXRpb27igJlzIHBvbGljeSAoZGVmYXVsdCArIGNvbmZpZ3VyZWQpLg0KDQpJ IGFsc28gYnJva2Ugb3V0IHRoZSBtYW5hZ2VtZW50IGluZm9ybWF0aW9uIGF3YXkgZnJvbSB0aGUg c3BlY2lmaWNhdGlvbiBpbmZvcm1hdGlvbi4NCg0KU3VlIEhhcmVzDQoNCkZyb206IERvbmdqaWUg KEppbW15KSBbbWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEph bnVhcnkgMzAsIDIwMTkgODo1MyBQTQ0KVG86IEJvcmNoZXJ0LCBPbGl2ZXIgKEZlZCk7IFN1c2Fu IEhhcmVzOyBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tPjsgQm9yY2hlcnQsIE9saXZlciAoRmVkKQ0KQ2M6IGlkckBpZXRmLm9yZzxtYWls dG86aWRyQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRl bmVkIE1lc3NhZ2UgU3VwcG9ydA0KDQpIaSBPbGl2ZXIsIEJydW5vIGFuZCBTdWUsDQoNClRvIG15 IHVuZGVyc3RhbmRpbmcsIGJ1bGxldCA1LzVhLzViIGluIHRoZSBpbXBsZW1lbnRhdGlvbiByZXBv cnQgaXMgY29ycmVzcG9uZGluZyB0byB0aGUgc2Vjb25kIHBhcmFncmFwaCBpbiBzZWN0aW9uIDUg 4oCcRXJyb3IgSGFuZGxpbmfigJ06DQoNCkEgQkdQIHNwZWFrZXIgdGhhdCBkb2VzIG5vdCBhZHZl cnRpc2UgdGhlIEJHUCBFeHRlbmRlZCBNZXNzYWdlcw0KICAgY2FwYWJpbGl0eSBtaWdodCBhbHNv IGdlbnVpbmVseSBub3Qgc3VwcG9ydCBFeHRlbmRlZCBNZXNzYWdlcy4gIFN1Y2gNCiAgIGEgc3Bl YWtlciBNVVNUIGZvbGxvdyB0aGUgZXJyb3IgaGFuZGxpbmcgcHJvY2VkdXJlcyBvZiBbUkZDNDI3 MV0gaWYNCiAgIGl0IHJlY2VpdmVzIGFuIEV4dGVuZGVkIE1lc3NhZ2UuICBTaW1pbGFybHksIGFu eSBzcGVha2VyIHRoYXQgdHJlYXRzDQogICBhbiBpbXByb3BlciBFeHRlbmRlZCBNZXNzYWdlIGFz IGEgZmF0YWwgZXJyb3IsIE1VU1QgdHJlYXQgaXQNCiAgIHNpbWlsYXJseS4NCg0KVGh1cyBpdCBp cyB0byBkZXNjcmliZSB0aGUgZXJyb3IgaGFuZGxpbmcgYmVoYXZpb3Igb2YgYW4gaW1wbGVtZW50 YXRpb24gdmVyc2lvbiB3aGljaCBkb2VzIG5vdCBzdXBwb3J0IGV4dGVuZGVkIG1lc3NhZ2UuDQoN CldoaWxlIEkgYWdyZWUgdGhpcyBjb3VsZCBiZSBtaXNsZWFkaW5nIGZvciBhIHJlcG9ydCBvZiBp bXBsZW1lbnRhdGlvbiB3aGljaCBzdXBwb3J0cyBleHRlbmRlZCBtZXNzYWdlIGNhcGFiaWxpdHks IG1heWJlIGl0IGNvdWxkIGJlIHVzZWQgdG8gdmVyaWZ5IHRoZSBiZWhhdmlvciBvZiBhbiBvbGQg dmVyc2lvbiB3aGljaCBkb2VzIG5vdCBzdXBwb3J0IHRoaXMgY2FwYWJpbGl0eT8NCg0KQmVzdCBy ZWdhcmRzLA0KSmllDQoNCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQm9yY2hlcnQsIE9saXZlciAoRmVkKQ0KU2VudDogV2VkbmVzZGF5LCBKYW51 YXJ5IDMwLCAyMDE5IDQ6MzUgQU0NClRvOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1h aWx0bzpzaGFyZXNAbmR6aC5jb20+PjsgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86 YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT47IEJvcmNoZXJ0LCBPbGl2ZXIgKEZlZCkgPG9saXZl ci5ib3JjaGVydEBuaXN0LmdvdjxtYWlsdG86b2xpdmVyLmJvcmNoZXJ0QG5pc3QuZ292Pj4NCkNj OiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWRyXSBX RyBMYXN0IENhbGwgb24gRXh0ZW5lZCBNZXNzYWdlIFN1cHBvcnQNCg0KQnJ1bm8gYW5kIFN1c2Fu LA0KDQpJIGNhbm5vdCBzcGVhayBmb3IgdGhlIEV4YUJHUCBJbXBsZW1lbnRhdGlvbiBidXQgZm9y IEJHUFNFQy1JTyBhbmQgUXVhZ2dhU1J4Lg0KSSBiZWxpZXZlIHdoZW4gSSBjb21waWxlZCB0aGUg cmVwb3J0LCBJIG1pcy1yZWFkIDVhIGFuZCBvdmVybG9va2VkIHRoZSDigJxub3TigJ0gYW5kIHJl YWQgaW5zdGVhZDog4oCcRG9lcyBzZW5kIEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eeKAnS4N ClRoZXJlZm9yZSB0aGUgaW1wbGVtZW50YXRpb24gcmVwb3J0IGZvciBzZWN0aW9uIDVhIG11c3Qg YmUgY29ycmVjdGVkIGZyb20g4oCcWWVz4oCdIGludG8g4oCcTm/igJ0gZm9yIGJvdGggQkdQU0VD LUlPIGFuZCBRdWFnZ2FTUngNCg0KQkdQU0VDLUlPIGFuZCBRdWFnZ2FTUngsIGJvdGggZG8gc2Vu ZCB0aGUgZXh0ZW5kZWQgbWVzc2FnZSBjYXBhYmlsaXR5IGlmIHNvIGNvbmZpZ3VyZWQuDQpJIGp1 c3QgY2hlY2tlZCB0aGUgY29kZSBhbmQgcnVuIGl0IGFnYWluLiBJIGNvcHkvcGFzdGVkIHRoZSBy ZWxldmFudCBvdXRwdXQgZ2VuZXJhdGVkIGJ5IEJHUFNFQy1JTywNCg0KT2xpdmVyDQoNCi0tLS0t ICBvdXRwdXQgb2YgQkdQU0VDLUlPICAtLS0tLS0tDQoNCu+7vy4vYmdwc2VjaW8gLWYgYmdwc2Vj aW8udGVzdC5jZmcucXNyeA0KU3RhcnRpbmcgYmdwc2VjaW8gMC4yLjAuMjUuLi4NClNlbmQ6ICAo T3BlbiBtZXNzYWdlIHNlbmQgZnJvbSBCR1BTRUMtSU8gdG8gUXVhZ2dhU1J4KQ0KT1BFTiBNZXNz YWdlDQogICstLW1hcmtlcjogRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCuKApg0K ICAgICArLS1PcHRpb25hbCBQYXJhbWV0ZXI6IENhcGFiaWxpdHkNCiAgICAgfCAgKy0tVHlwZTog Q2FwYWJpbGl0eSAoMikNCiAgICAgfCAgKy0tTGVuZ3RoOiAyDQogICAgIHwgICstLUNhcGFiaWxp dHk6IEV4dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCBjYXBhYmlsaXR5DQogICAgIHwgICAgICstLVR5 cGU6IEV4dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCBjYXBhYmlsaXR5ICg2KQ0KICAgICB8ICAgICAr LS1MZW5ndGg6IDANCuKApg0KDQpSZWNlaXZlZDogKE9wZW4gbWVzc2FnZSBzZW5kIGZyb20gUXVh Z2dhU1J4IGFuZCByZWNlaXZlZCBieSBCR1BTRUMtSU8pDQpPUEVOIE1lc3NhZ2UNCiAgKy0tbWFy a2VyOiBGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRg0K4oCmDQogICAgICstLU9wdGlv bmFsIFBhcmFtZXRlcjogQ2FwYWJpbGl0eQ0KICAgICAgICArLS1UeXBlOiBDYXBhYmlsaXR5ICgy KQ0KICAgICAgICArLS1MZW5ndGg6IDINCiAgICAgICAgKy0tQ2FwYWJpbGl0eTogRXh0ZW5kZWQg bWVzc2FnZSBzdXBwb3J0IGNhcGFiaWxpdHkNCiAgICAgICAgICAgKy0tVHlwZTogRXh0ZW5kZWQg bWVzc2FnZSBzdXBwb3J0IGNhcGFiaWxpdHkgKDYpDQogICAgICAgICAgICstLUxlbmd0aDogMA0K QkdQLXJlY2VpdmVyIHRocmVhZCBjcmVhdGVkIQ0KDQoNCg0KRnJvbTogSWRyIDxpZHItYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgU3Vz YW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NCkRhdGU6 IFR1ZXNkYXksIEphbnVhcnkgMjksIDIwMTkgYXQgMTE6NDMgQU0NClRvOiAiYnJ1bm8uZGVjcmFl bmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4iIDxicnVuby5k ZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPj4NCkNj OiAiaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+IiA8aWRyQGlldGYub3JnPG1haWx0 bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRl bmVkIE1lc3NhZ2UgU3VwcG9ydA0KDQpCcnVubzoNCg0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1l bnRzIG9uIHRoaXMgdG9waWMg4oCTIGFzIEkgdGhpbmsNCg0KSSBkaWQgcmVjZWl2ZSByZXBvcnRz IHByaXZhdGVseSB0aGF0IHdlIGhhdmUgMSBmdWxsIGltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1p ZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMgb2ZmIGxpc3Qgd2hpY2ggaXMgbm90IGxpc3Rl ZCBpbiB0aGlzIHJlcG9ydC4gICBJIGhvcGUgdGhvc2UgaW1wbGVtZW50ZXJzIHdpbGwgdm9sdW50 ZWVyIHRoaXMgaW5mb3JtYXRpb24gb24gdGhlIGxpc3QuICAgSWYgbm90LCBJIHdpbGwgc2hhcmUg dGhpcyBpbmZvcm1hdGlvbiB3aXRoIEFsdmFybyBhbmQgdGhlIElFU0cuDQoNClRoZSBTSURSIHdv cmsgZGlkIGRlZmluZSBkcmFmdC1pZXRmLWJncC1leHRlbmRlZC1tZXNzYWdlcyBhcyBhIHJlcXVp cmVtZW50IGFuZCBvbmx5IG1vdmVkIHRvIG5vdCBzcGVjaWZ5aW5nIGl0IHdoZW4gd2UgY291bGQg bm90IHF1aWNrbHkgcGFzcyB0aGlzIHRocm91Z2ggV0cgTEMuDQoNClRoZSByZWFsIG5lZWRzIGFy ZSBhIGdyb3dpbmcgQkdQLUxTIHRoYXQgbWF5IHJ1biBvdXQgb2YgQkdQIG1lc3NhZ2Ugc3BhY2Uu ICBBcyBteSBwcmV2aW91cyBlbWFpbCB0byBJRFIgaW5kaWNhdGVzLCBJIHdhcyBob3BpbmcgdGhp cyBoYW5kbGVzIGFuIEJHUCBtZXNzYWdlIHdob3NlIGxlbmd0aCBpcyBiaWdnZXIgdGhhbiA0MDk2 IGJ5dGVzLiAgIFRoYW5rIHlvdSBmb3IgdGhlIGNvcnJlY3Rpb24gb2Y6DQoNCuKAnFRoZSBpc3N1 ZSBpcyBub3Qgc3BlY2lmaWMgdG8gYXR0cmlidXRlcyBiaWdnZXIgdGhhbiA0MDk2IG9jdGV0cywg YnV0IHRvIEJHUCBtZXNzYWdlIHdob3NlIGxlbmd0aCBpcyBiaWdnZXIgdGhhbiA0MDk2LCBpcnJl c3BlY3RpdmUgb2YgdGhlIHNpemUgb2YgZWFjaCBhdHRyaWJ1dGUu4oCdDQoNCg0KQXMgdG8geW91 ciBjb21tZW50Og0KDQrigJxXaHkgaXMgdGhpcyBsaW1pdGVkIHRvIGZ1dHVyZSBzcGVjaWZpY2F0 aW9ucz8gQSBwcmlvcmksIHVzaW5nIGV4aXN0aW5nIEJHUCBtZWNoYW5pc20gKEFGSS9TQUZJLCBh dHRyaWJ1dGVzLCAqIGNvbW11bml0aWVzKSBvbmUgY291bGQgZXhjZWVkIHRoZSBzaXplIG9mIDQw OTYgb2N0ZXRzLiBIb3cgZG9lcyB0aGUgQkdQIHNwZWFrZXIgc3VwcG9zZWQgdG8gYmVoYXZlIGlu IHRoaXMgY2FzZT8gVGhpcyBzaG91bGQgYmUgZGVzY3JpYmVkIGluIHRoaXMgc3BlY2lmaWNhdGlv bi4gTm90ZSB0aGF0IHRoaXMgaXMgbm90IGEgY2FzZSBvZiBlcnJvciBoYW5kbGluZywgYXMgZXZl cnkgQkdQIHNwZWFrZXIgaXMgYmVoYXZpbmcgYXMgc3BlY2lmaWVkLuKAnQ0KDQpUaGlzIHByb2Js ZW0gaGFzIGJlZW4gdHJ1ZSBmb3IgeWVhcnMsIGFuZCB0aHVzIGFzIGNvLWNoYWlycyBoYWQgaG9w ZWQgdG8gaGF2ZSB0aGUgZHJhZnQtaWV0Zi1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMgcGFzc2VkIHll YXJzIGFnby4gICBBcyBCR1AtTFMgYXR0cmlidXRlcyBncm93IHVzZSBhbmQgaW4gbnVtYmVyLCB0 aGUgcG90ZW50aWFsIG9mIGV4Y2VlZGluZyB0aGUgQkdQIG1lc3NhZ2UgbGltaXQgaW5jcmVhc2Vz LiAgSXQgc2VlbXMgbGlrZSBhIGdvb2QgZGlyZWN0aW9uIHRvIHByZXZlbnQgaXNzdWVzLg0KDQpJ IGhvcGUgdGhlIGF1dGhvcnMgd2lsbCBjb21tZW50IG9uIHRoZSBjaGFuZ2VzIHlvdSBzdWdnZXN0 ZWQgdG8gdGhlIHRleHQuDQoNCkNoZWVycywNClN1c2FuIEhhcmVzDQoNCg0KDQpGcm9tOiBicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPiBb bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb21dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5 IDI5LCAyMDE5IDg6MzMgQU0NClRvOiBTdXNhbiBIYXJlcw0KQ2M6IGlkckBpZXRmLm9yZzxtYWls dG86aWRyQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRl bmVkIE1lc3NhZ2UgU3VwcG9ydA0KDQpIaSBXRywNCg0KUGxlYXNlIGZpbmQgYmVsb3cgc29tZSBj b21tZW50cy4NCkFzIG9mIHRvZGF5LCBJIGRvbuKAmXQgYmVsaWV2ZSB0aGlzIHNwZWNpZmljYXRp b24gaXMgcmVhZHkgdG8gYmUgcHJvZ3Jlc3NlZCB0byBJRVNHL1JGQywgZXNwZWNpYWxseSBmb3Ig YSBkb2N1bWVudCB1cGRhdGluZyBSRkMgNDI3MSAoY29yZSBCR1Agc3BlYykuDQoNCj4gVGhlIFdH IGNoYWlycyBpbnRlbmQgdG8gZm9yd2FyZCB0aGlzIGRyYWZ0IHRvIHRoZSBJRVNHIHdpdGggdGhl IGN1cnJlbnQgbGV2ZWwgb2YgaW1wbGVtZW50YXRpb24uDQoNCmh0dHBzOi8vdHJhYy5pZXRmLm9y Zy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRhdGlv bnM8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ0cmFjLmlldGYub3JnJTJGdHJhYyUyRmlkciUyRndpa2klMkZkcmFmdC1pZXRm LWlkci1iZ3AtZXh0ZW5kZWQtaW1wbGVtZW50YXRpb25zJmRhdGE9MDIlN0MwMSU3Q29saXZlci5i b3JjaGVydCU0MG5pc3QuZ292JTdDNDBiYjhhOTQzZTYxNGIxNjM3ZjMwOGQ2ODYwOGQ2Y2QlN0My YWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2ODQzNzY5ODU5MTY1 MDQzJnNkYXRhPWhYQmJPWHF3dlhxdENWJTJCOVBiUCUyRjdJRTZXSmpXVUEyYm9NMzNLZHMlMkJn aDQlM0QmcmVzZXJ2ZWQ9MD4gc2F5cyA6IDVhDQoNCkRvZXMgbm90IHNlbmQgRXh0ZW5kZWQgTWVz c2FnZSBjYXBhYmlsaXR5DQoNClllcw0KDQpZZXMNCg0KWWVzDQoNCg0KSSBtYXkgYmUgbWlzdW5k ZXJzdGFuZGluZyB0aGUgaW1wbGVtZW50YXRpb24gcmVwb3J0LCBidXQgbXkgcmVhZGluZyBvZiB0 aGUgYWJvdmUgaXMgdGhhdCBub25lIG9mIHRoZSByZXBvcnRlZCBpbXBsZW1lbnRhdGlvbnMgc2Vu ZHMgdGhlIGNhcGFiaWxpdHkgaGVuY2Ugbm8gaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgZHJhZnQt aWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLi4gSGVyZSB0aGlzIGRvY3VtZW50IGlzIHVw ZGF0aW5nIFJGQyA0MjcxLCBzbyBpdCBpcyBub3QgYSBtaW5vciBleHRlbnNpb24gZm9yIGEgbmlj aGUgdXNlIGNhc2UuIFNvIEkgZG9u4oCZdCBzZWUgdGhlIGFyZ3VtZW50cyBmb3Igbm90IHJlcXVp cmluZyB0aGUgSURS4oCZcyB1c3VhbCB0d28gaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMu DQoNCi0tLS0NCsKnIDENCuKAnCBBcyBCR1AgaXMgZXh0ZW5kZWQgdG8gc3VwcG9ydCBuZXdlciBB RkkvU0FGSXMgYW5kDQogICBuZXdlciBjYXBhYmlsaXRpZXMgKGUuZy4sIFtJLUQuaWV0Zi1zaWRy LWJncHNlYy1wcm90b2NvbDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWll dGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0yNyUyM3JlZi1JLUQuaWV0Zi1zaWRyLWJncHNl Yy1wcm90b2NvbCZkYXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3QzQw YmI4YTk0M2U2MTRiMTYzN2YzMDhkNjg2MDhkNmNkJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2 NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjg0Mzc2OTg1OTE2NTA0MyZzZGF0YT11WlMlMkJiTjl2NWNp cjJvNUwzVTNqUDJ4RlBiWTRUeiUyRk5uQlBmZEg3aURmMCUzRCZyZXNlcnZlZD0wPl0pLCB0aGVy ZSBpcw0KICAgYSBuZWVkIHRvIGV4dGVuZCB0aGUgbWF4aW11bSBtZXNzYWdlIHNpemUgYmV5b25k IDQwOTYgb2N0ZXRzLiAg4oCcDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMjcjc2VjdGlvbi0xPGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMu aWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTI3 JTIzc2VjdGlvbi0xJmRhdGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdD NDBiYjhhOTQzZTYxNGIxNjM3ZjMwOGQ2ODYwOGQ2Y2QlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1 NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2ODQzNzY5ODU5MTY1MDQzJnNkYXRhPVlWV0hBRmJZUmpH JTJGbFdQYnB3MnJXOHVHUTZRWHNzM2R1Zm0lMkZxSGdSdkR3JTNEJnJlc2VydmVkPTA+DQoNCg0K W0ktRC5pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZo dG1sJTJGZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTI3JTIzcmVmLUktRC5p ZXRmLXNpZHItYmdwc2VjLXByb3RvY29sJmRhdGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0 MG5pc3QuZ292JTdDNDBiYjhhOTQzZTYxNGIxNjM3ZjMwOGQ2ODYwOGQ2Y2QlN0MyYWI1ZDgyZmQ4 ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2ODQzNzY5ODU5MTY1MDQzJnNkYXRh PXVaUyUyQmJOOXY1Y2lyMm81TDNVM2pQMnhGUGJZNFR6JTJGTm5CUGZkSDdpRGYwJTNEJnJlc2Vy dmVkPTA+IGlzIG5vdyBSRkMgODIwNSAodGhhbmtzIGZvciB1cGRhdGluZyB0aGUgcmVmZXJlbmNl KS4gSXQgaGFzIHJlbW92ZWQgdGhlIG5vcm1hdGl2ZS9hbnkgcmVmZXJlbmNlIHRvIGRyYWZ0LWll dGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy4gU28gcHJlc3VtYWJseSBCR1AgU2VjIGRvZXMg bm90IG5lZWQgZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLg0KQ2FuIHdlIGhh dmUgYW4gdXBkYXRlIG9uIHRoaXM/DQpDYW4gdGhlIGludHJvZHVjdGlvbiBvZiBkcmFmdC1pZXRm LWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMgYmUgdXBkYXRlZCB0byBpbnRyb2R1Y2Ugb24gdGhl IHJlYWwgcmVhc29ucy9uZWVkcz8NCg0KLS0tLQ0Kwqc0DQoNCsKnMyBzYXlzIOKAnEEgcGVlciB3 aGljaCBkb2VzIG5vdCBhZHZlcnRpc2UgdGhpcyBjYXBhYmlsaXR5IE1VU1QgTk9UIHNlbmQgQkdQ DQogICBFeHRlbmRlZCBNZXNzYWdlcywgYW5kIEJHUCBFeHRlbmRlZCBNZXNzYWdlcyBNVVNUIE5P VCBiZSBzZW50IHRvIGl0LuKAnQ0KDQpGaW5lLiBUZXh0IGluIMKnNCBzaG91bGQgcHJvYmFibHkg YmUgYWxpZ25lZCB3aXRoIHRoZSBhYm92ZSAuLmUuZy4NCg0KT0xEOiBBIEJHUCBzcGVha2VyDQog ICBNQVkgc2VuZCBFeHRlbmRlZCBNZXNzYWdlcyB0byBpdHMgcGVlciBvbmx5IGlmIGl0IGhhcyBy ZWNlaXZlZCB0aGUNCiAgIEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eSBmcm9tIHRoYXQgcGVl ci4NCg0KTkVXOg0KQSBCR1Agc3BlYWtlcg0KICAgTUFZIHNlbmQgRXh0ZW5kZWQgTWVzc2FnZXMg dG8gaXRzIHBlZXIgb25seSBpZiBpdCBoYXMgc2VudCBhbmQgcmVjZWl2ZWQgdGhlDQogICBFeHRl bmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgdG8gYW5kIGZyb20gdGhhdCBwZWVyLg0KDQotLS0tDQoN CuKAnCAgIEFwcGxpY2F0aW9ucyBnZW5lcmF0aW5nIGluZm9ybWF0aW9uIHdoaWNoIG1pZ2h0IGJl IGVuY2Fwc3VsYXRlZA0KICAgd2l0aGluIEJHUCBtZXNzYWdlcyBNVVNUIGxpbWl0IHRoZSBzaXpl IG9mIHRoZWlyIHBheWxvYWQgdG8gdGFrZSB0aGUNCiAgIG1heGltdW0gbWVzc2FnZSBzaXplIGlu dG8gYWNjb3VudC7igJ0NCg0KSSBkb27igJl0IHNlZSB3aGF0IG5ldyBiZWhhdmlvciBpcyBiZWVu IGRlZmluZWQgaGVyZS4gSWYgdGhlcmUgaXMgbm9uZSwgSSB3b3VsZCBzdWdnZXN0IHRvIHJlbW92 ZSB0aGlzIHNlbnRlbmNlDQoNCi0tLS0NCiAgIEEgQkdQIGFubm91bmNlbWVudCB3aWxsLCBpbiB0 aGUgbm9ybWFsIGNhc2UsIHByb3BhZ2F0ZSB0aHJvdWdob3V0IHRoZQ0KICAgQkdQIHNwZWFraW5n IEludGVybmV0OyBhbmQgdGhlcmUgd2lsbCB1bmRvdWJ0ZWRseSBiZSBCR1Agc3BlYWtlcnMNCiAg IHdoaWNoIGRvIG5vdCBoYXZlIHRoZSBFeHRlbmRlZCBNZXNzYWdlIGNhcGFiaWxpdHkuICBUaGVy ZWZvcmUsDQogICBwdXR0aW5nIGFuIGF0dHJpYnV0ZSB3aGljaCBjYW4gbm90IGJlIGRlY29tcG9z ZWQgdG8gNDA5NiBvY3RldHMgb3INCiAgIGxlc3MgaW4gYW4gRXh0ZW5kZWQgTWVzc2FnZSBpcyBh IGxpa2VseSBwYXRoIHRvIHJvdXRpbmcgZmFpbHVyZS4NCg0KDQpUaGUgaXNzdWUgaXMgbm90IHNw ZWNpZmljIHRvIGF0dHJpYnV0ZXMgYmlnZ2VyIHRoYW4gNDA5NiBvY3RldHMsIGJ1dCB0byBCR1Ag bWVzc2FnZSB3aG9zZSBsZW5ndGggaXMgYmlnZ2VyIHRoYW4gNDA5NiwgaXJyZXNwZWN0aXZlIG9m IHRoZSBzaXplIG9mIGVhY2ggYXR0cmlidXRlLg0KUGxlYXNlIGVsYWJvcmF0ZSBvbiB3aGF0IHlv dSBtZWFuIGJ5IOKAnGFuIGF0dHJpYnV0ZSB3aGljaCBjYW4gbm90IGJlIGRlY29tcG9zZWQgdG8g NDA5NiBvY3RldHPigJ0NCg0KLS0tDQrigJwgICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IEJHUCBw cm90b2NvbCBkZXZlbG9wZXJzIGFuZCBpbXBsZW1lbnRlcnMgYXJlDQogICBjb25zZXJ2YXRpdmUg aW4gdGhlaXIgYXBwbGljYXRpb24gYW5kIHVzZSBvZiBFeHRlbmRlZCBNZXNzYWdlcy7igJ0NCg0K V2hhdCBkb2VzIHRoaXMgbWVhbiBleGFjdGx5PyBUaGF0IHRoZXkgZG9u4oCZdCB1c2UgdGhpcyBl eHRlbnNpb24/IFRoYXQgdGhleSBkb27igJl0IHVzZSB0aGlzIGV4dGVuc2lvbiB1bmxlc3MgWFhf VE8gQkUgU1BFQ0lGSUVEX1hYPw0KDQotLS0NCiAgRnV0dXJlIHByb3RvY29sIHNwZWNpZmljYXRp b25zIHdpbGwgbmVlZCB0byBkZXNjcmliZSBob3cgdG8gaGFuZGxlDQogICBwZWVycyB3aGljaCBj YW4gb25seSBhY2NvbW1vZGF0ZSA0MDk2IG9jdGV0IG1lc3NhZ2VzLg0KDQpXaHkgaXMgdGhpcyBs aW1pdGVkIHRvIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucz8gQSBwcmlvcmksIHVzaW5nIGV4aXN0aW5n IEJHUCBtZWNoYW5pc20gKEFGSS9TQUZJLCBhdHRyaWJ1dGVzLCAqIGNvbW11bml0aWVzKSBvbmUg Y291bGQgZXhjZWVkIHRoZSBzaXplIG9mIDQwOTYgb2N0ZXRzLiBIb3cgZG9lcyB0aGUgQkdQIHNw ZWFrZXIgc3VwcG9zZWQgdG8gYmVoYXZlIGluIHRoaXMgY2FzZT8gVGhpcyBzaG91bGQgYmUgZGVz Y3JpYmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4gTm90ZSB0aGF0IHRoaXMgaXMgbm90IGEgY2Fz ZSBvZiBlcnJvciBoYW5kbGluZywgYXMgZXZlcnkgQkdQIHNwZWFrZXIgaXMgYmVoYXZpbmcgYXMg c3BlY2lmaWVkLg0KDQoNCi0tLS0NCkRlcGVuZGluZyBvbiB0aGUgYWJvdmUgc3BlY2lmaWNhdGlv biwgYSBzZWN0aW9uIGRlc2NyaWJpbmcgdGhlIG9wZXJhdGlvbmFsIGNvbnNlcXVlbmNlcyBpbiBh IG5ldHdvcmsgKHN1Y2ggYXMgdGhlIEludGVybmV0LCBCR1AgRW5hYmxlZCBTZXJ2aWNlUy9WUE4g bmV0d29ya3MpIGlzIHByb2JhYmx5IG5lZWRlZC4gUG9zc2libGUgY29uc2VxdWVuY2VzIGNvdWxk IGJlIEJHUCBOTFJJIGJlaW5nIHJlbW92ZWQgaW4gdGhlIG1pZGRsZSBvZiBzdWNoIG5ldHdvcmss IG9yIChleHRlbmRlZCkgY29tbXVuaXR5IChzdWNoIGFzIFJvdXRlIFRhcmdldHMpIGJlZW4gcmVt b3ZlZC4gQm90aCBoYXZpbmcgc2lnbmlmaWNhbnQgY29uc2VxdWVuY2VzIG9uIHRoZSBhdmFpbGFi aWxpdHkgcHJvdmlkZWQgYnkgdGhlIG5ldHdvcmsuDQoNCi0tLQ0Kwqc0DQpPTEQ6IFRoZSBFeHRl bmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgb25seSBhcHBsaWVzIHRvIGFsbCBtZXNzYWdlcyBleGNl cHQgZm9yIHRoZSBPUEVOIG1lc3NhZ2UuDQpQcm9iYWJseQ0KTkVXOiBUaGUgRXh0ZW5kZWQgTWVz c2FnZSBDYXBhYmlsaXR5IGFwcGxpZXMgdG8gYWxsIG1lc3NhZ2UgdHlwZXMgZXhjZXB0IGZvciB0 aGUgT1BFTiBtZXNzYWdlICh0eXBlIDEpLg0KLS0tLQ0Kwqc4DQoNCuKAnFRoaXMgZXh0ZW5zaW9u IHRvIEJHUCBkb2VzIG5vdCBjaGFuZ2UgQkdQJ3MgdW5kZXJseWluZyBzZWN1cml0eSBpc3N1ZXMg wrsNCg0KQmVmb3JlIGV2YWx1YXRpbmcgdGhpcywgSSB0aGluayB0aGlzIGRvY3VtZW50IHNob3Vs ZCBmaXJzdCBzcGVjaWZpZWQgaG93IGEgQkdQIG1lc3NhZ2VzIGJpZ2dlciB0aGFuIDQwOTYgb2N0 ZXRzIGlzIGhhbmRsZWQgd2hlbiBpdCBuZWVkcyB0byBiZSBzZW50IHRvIGEgcmVjZWl2ZWQgbm90 IHN1cHBvcnRpbmcgdGhpcyBleHRlbnNpb24uDQoNCk5pdHM6DQpPTEQgOiB0byByZWR1Y2UgY29t cGV4aXR5DQpORVcgOiB0byByZWR1Y2UgY29tcGxleGl0eQ0KDQpUaGFua3MsDQotLUJydW5vDQoN CkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3Vz YW4gSGFyZXMNClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjksIDIwMTkgMTI6MzMgUE0NClRvOiBp ZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFtJZHJdIFdHIExhc3Qg Q2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydA0KDQoNClRoaXMgYmVnaW5zIGEgMiB3ZWVr IFdHIExDIG9uIEV4dGVuZGVkIE1lc3NhZ2UgU3VwcG9ydCBmb3IgQkdQIChkcmFmdC1pZXRmLWlk ci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMjcpLiAgWW91IGNhbiBhY2Nlc3MgdGhlIGRyYWZ0IGF0 Og0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1iZ3At ZXh0ZW5kZWQtbWVzc2FnZXMvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZk cmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMlMkYmZGF0YT0wMiU3QzAxJTdDb2xp dmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJiOGE5NDNlNjE0YjE2MzdmMzA4ZDY4NjA4ZDZj ZCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2MzY4NDM3Njk4 NTkzMjEyODkmc2RhdGE9b2tqVGVMZTZEY1RhUlYyVVN5Mk15NkhYRFJ5bnVwbVhsQjBpN2dVd3lu QSUzRCZyZXNlcnZlZD0wPg0KDQpUaGUgYXV0aG9ycyBzaG91bGQgaW5kaWNhdGUgd2hldGhlciB0 aGV5IGtub3cgb2YgYW55IElQUi4gICBJbXBsZW1lbnRlcnMgYXJlIGVuY291cmFnZWQgdG8gdXBk YXRlIHRoZSAgaW1wbGVtZW50YXRpb24gZGF0YSBhdDoNCg0KaHR0cHM6Ly90cmFjLmlldGYub3Jn L3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLWltcGxlbWVudGF0aW9u czxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRnRyYWMuaWV0Zi5vcmclMkZ0cmFjJTJGaWRyJTJGd2lraSUyRmRyYWZ0LWlldGYt aWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRhdGlvbnMmZGF0YT0wMiU3QzAxJTdDb2xpdmVyLmJv cmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJiOGE5NDNlNjE0YjE2MzdmMzA4ZDY4NjA4ZDZjZCU3QzJh YjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2MzY4NDM3Njk4NTkzMjEy ODkmc2RhdGE9UG9SeUZvZnMwNCUyRkMlMkYlMkZnYlhMMnp5RUQzU1c2TXJFU3BIaUlFMmU3cDRj QSUzRCZyZXNlcnZlZD0wPg0KDQpUaGUgZHJhZnQgcHJvdmlkZXMgYSBtZWFucyBmb3IgZXhwYW5k aW5nIHRoZSBCR1AgbWVzc2FnZSB0byA2NTUzNSBvY3RldHMgZm9yIGFsbCBtZXNzYWdlcyBleGNl cHQgT1BFTiBtZXNzYWdlcy4gIEJHUCBtZXNzYWdlIHNwYWNlIGlzIHJ1bm5pbmcgc2hvcnQgZm9y IGFsbCBvZiB0aGUgcG90ZW50aWFsIGF0dHJpYnV0ZXMgb3IgYWRkaXRpb25zIHByb3Bvc2VkIGJ5 IEJHUC1MUyBmZWF0dXJlcy4NCg0KVGhlIFdHIGNoYWlycyBpbnRlbmQgdG8gZm9yd2FyZCB0aGlz IGRyYWZ0IHRvIHRoZSBJRVNHIHdpdGggdGhlIGN1cnJlbnQgbGV2ZWwgb2YgaW1wbGVtZW50YXRp b24uDQoNCkFzIHlvdSBjb21tZW50IG9uIHRoZSBkcmFmdCwgcGxlYXNlIGNvbnNpZGVyIGlmOiBh KSB0aGUgdGVjaG5vbG9neSBpcyBtYXR1cmUsIGIpIHRoZSBhZGRpdGlvbmFsIHNwYWNlIGluIGEg QkdQIG1lc3NhZ2Ugd291bGQgYmUgaGVscGZ1bCBmb3IgdGhvc2UgZGVwbG95aW5nIEJHUC1MUyBv ciBTUiwgYW5kIGMpIGlmIHRoZSBzcGVjaWZpY2F0aW9uIGlzIHJlYWR5IGZvciBwdWJsaWNhdGlv bi4NCg0KU3VlIEhhcmVzIChXRyBDaGFpciwgU2hlcGhlcmQpDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0K DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg== --_000_1E129C9297F74E25AB5B6E9A921D679Dciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpT dWUsDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Tb3JyeSBpZiBJJ20gYSBiaXQgYmVoaW5kLCBi dXQgY291bGQgeW91IGVsYWJvcmF0ZSB0aGUgcHJvYmxlbSB3aXRoIEJHUC1MUyBwbGVhc2UuIENh biB5b3UgZ2l2ZSBzb21lIGV4YW1wbGVzIG9mIGEgQkdQLUxTIE5MUkkgYW5kIGFzc29jaWF0ZWQg cGF0aCBhdHRyaWJ1dGUgdGhhdCB3aWxsIG5vdCBmaXQgNDA5NiBieXRlcz88YnI+DQo8YnI+DQo8 ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiIGRpcj0ibHRyIj5UaGFua3MsPGJyPg0KPGRpdj5K YWtvYi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxi cj4NCk9uIEZlYiAxMSwgMjAxOSwgYXQgMTE6MTggUE0sIFN1c2FuIEhhcmVzICZsdDs8YSBocmVm PSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0 ciI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChm aWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0 w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KcC5QcmZvcm1hdEhUTUwsIGxpLlBy Zm9ybWF0SFRNTCwgZGl2LlByZm9ybWF0SFRNTA0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1h dMOpIEhUTUwiOw0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnAuSFRNTCwgbGkuSFRNTCwgZGl2LkhUTUwNCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTo rr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFs O30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJY29sb3I6IzcwMzBBMDt9DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5KYWtvYjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgbWVudGlvbmluZyB0 aGUgY29ycmVjdCBpbmZvcm1hdGlvbiB0aGUgQkdQU2VjIGFzIGZhciBhcyB0aGUgc3BlY2lmaWNh dGlvbnMuJm5ic3A7IFdoZXRoZXIgb3Igbm90IHRoZSBSU0EtMjA0OCB3b3VsZCBoYXZlIGJlZW4g dXNlZnVsIHRvIEJHUFNlYywgaXMgbGVmdA0KIGZvciB0aGUgT1BTIGdyb3VwIGhhbmRsaW5nIFNJ RFIgZGVwbG95bWVudC4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgZm9jdXMgb2YgdGhpcyBkaXNjdXNz aW9uIGlzIHRvIHJlbW92ZSBhbnkgZnV0dXJlIG9ic3RhY2xlcyB0byB0aGUgdXNlIG9mIEJHUC1M UyBhdHRyaWJ1dGVzL05MUkkuJm5ic3A7IFR3byBwb3RlbnRpYWwgbGltaXRzIGV4aXN0OiZuYnNw OyBhKSBtZXNzYWdlIHNpemUgKGdyZWF0ZXINCiB0aGFuIDQwOTYpIGFuZCBiKSBlcnJvciBoYW5k bGluZy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5TdWUgSGFyZXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IElkciBbPGEg aHJlZj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYWtvYiBIZWl0eiAoamhlaXR6KTxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDQsIDIwMTkgMzoxNCBQTTxicj4NCjxiPlRv OjwvYj4gRG9uZ2ppZSAoSmltbXkpOyBTdXNhbiBIYXJlczsgJ0JvcmNoZXJ0LCBPbGl2ZXIgKEZl ZCknOyA8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+DQpicnVuby5k ZWNyYWVuZUBvcmFuZ2UuY29tPC9hPjsgJ0JvcmNoZXJ0LCBPbGl2ZXIgKEZlZCknPGJyPg0KPGI+ Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWRyXSBXRyBMYXN0IENhbGwgb24gRXh0ZW5lZCBNZXNz YWdlIFN1cHBvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5CR1BTZWMgZHJvcHBlZCB0aGUgcmVxdWlyZW1lbnQg Zm9yIGV4dGVuZGVkIG1lc3NhZ2VzIGJlY2F1c2UgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+c2lnbmF0dXJlIHdh cyBjaGFuZ2VkIGZyb20gUlNBLTIwNDggKDI1NiBieXRlIHNpZykgdG8gRUNEU0EgUC0yNTYgKDY0 IGJ5dGUgc2lnKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojNzAzMEEwIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3NpZHIvTFJIUHVPNU1GMHUtdld1aE5BVmVWTl84ZklVIj5odHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NpZHIvTFJIUHVPNU1GMHUtdld1aE5BVmVWTl84 ZklVPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPlRoZXJlIGlzIG5vIG1lbnRpb24g b2YgZXh0ZW5kZWQgbWVzc2FnZXMgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM4MjA1Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODIwNTwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj NzAzMEEwIj5BbGwgbWVudGlvbiBvZiBpdCB3YXMgc3RydWNrIG91dCBpbjo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNp ZHItYmdwc2VjLXByb3RvY29sLTIzLnR4dCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbC0yMy50eHQ8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBB MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+SmFrb2IuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gSWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmciPmlk ci1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+RG9uZ2ppZSAo SmltbXkpPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMSwgMjAxOSAxMDo0NSBQ TTxicj4NCjxiPlRvOjwvYj4gU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNA bmR6aC5jb20iPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7OyAnQm9yY2hlcnQsIE9saXZlciAoRmVk KScgJmx0OzxhIGhyZWY9Im1haWx0bzpvbGl2ZXIuYm9yY2hlcnQ9NDBuaXN0LmdvdkBkbWFyYy5p ZXRmLm9yZyI+b2xpdmVyLmJvcmNoZXJ0PTQwbmlzdC5nb3ZAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0 OzsNCjxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNy YWVuZUBvcmFuZ2UuY29tPC9hPjsgJ0JvcmNoZXJ0LCBPbGl2ZXIgKEZlZCknICZsdDs8YSBocmVm PSJtYWlsdG86b2xpdmVyLmJvcmNoZXJ0QG5pc3QuZ292Ij5vbGl2ZXIuYm9yY2hlcnRAbmlzdC5n b3Y8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+ aWRyQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkcl0gV0cgTGFzdCBD YWxsIG9uIEV4dGVuZWQgTWVzc2FnZSBTdXBwb3J0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhpIFN1ZSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB1cGRhdGluZyB0aGUgaW1wbGVt ZW50YXRpb24gcmVwb3J0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IGJ1 bGxldCA0IHdhcyB0byBjb3ZlciB0aGUgYmVoYXZpb3Igb2Ygc2VjdGlvbiA1IHBhcmFncmFwaCAx LCBidWxsZXQgNSB3YXMgdG8gY292ZXIgdGhlIGJlaGF2aW9yIG9mIHNlY3Rpb24gNSBwYXJhZ3Jh cGggMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJ1dCBhZnRlciByZXJlYWRpbmcgc2VjdGlvbiA1LCBJIHJlYWxpemUg dGhhdCBib3RoIHBhcmFncmFwaCAxIGFuZCAyIGFyZSB0YWxraW5nIGFib3V0IHRoZSBiZWhhdmlv ciBvZiBhIEJHUCBzcGVha2VyIHdoaWNoIGRvZXMgbm90IGFkdmVydGlzZSB0aGUgZXh0ZW5kZWQg bWVzc2FnZQ0KIGNhcGFiaWxpdHkgdG8gaXRzIHBlZXIsIHNvIHBlcmhhcHMgYnVsbGV0cyA0IGFu ZCA1IGluIHRoZSBpbXBsZW1lbnRhdGlvbiByZXBvcnQgY291bGQgYmUgbWVyZ2VkIGFzIGJlbG93 Og0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj40LiBXaGVuIHJlY2VpdmVzIGFuIGV4dGVuZGVkIG1lc3NhZ2Ugd2l0aG91 dCBhZHZlcnRpc2luZyB0aGUgQkdQIEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eSB0byB0aGlz IHBlZXIgKEVycm9yIEhhbmRsaW5nKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+NGEu IEFjY2VwdHMgdGhlIGV4dGVuZGVkIG1lc3NhZ2UgaWYgdGhlIEJHUCBzcGVha2VyIGlzIGFibGUg dG8gcHJvY2VzcyBleHRlbmRlZCBtZXNzYWdlIChidXQgd2FzIGNvbmZpZ3VyZWQgbm90IHRvIGFk dmVydGlzZSB0aGUgY2FwYWJpbGl0eSkgJm5ic3A7Jm5ic3A7W1NlY3Rpb24gNSwgcGFyYWdyYXBo DQogMSBNQVldPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjRiLiBEb2VzIG5vdCBhY2Nl cHQgdGhlIGV4dGVuZGVkIG1lc3NhZ2UsIGZvbGxvd3MgUkZDNDI3MSBoYW5kbGluZyBhbmQgc2Vu ZHMgQmFkIE1lc3NhZ2UgTGVuZ3RoIE5vdGlmaWNhdGlvbiBbU2VjdGlvbiA1LCBwYXJhZ3JhcGgg MSBTSE9VTEQgTk9ULCBhbmQgcGFyYWdyYXBoDQogMiBNVVNUKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG9wZSB0aGlz IGhlbHBzIHRvIHJlZHVjZSB0aGUgY29uZnVzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gU3VzYW4gSGFyZXMgWzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPm1haWx0bzpz aGFyZXNAbmR6aC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkg MDEsIDIwMTkgMTE6MDMgUE08YnI+DQo8Yj5Ubzo8L2I+IERvbmdqaWUgKEppbW15KSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb20iPmppZS5kb25nQGh1YXdlaS5jb208L2E+ Jmd0OzsgJ0JvcmNoZXJ0LCBPbGl2ZXIgKEZlZCknICZsdDs8YSBocmVmPSJtYWlsdG86b2xpdmVy LmJvcmNoZXJ0PTQwbmlzdC5nb3ZAZG1hcmMuaWV0Zi5vcmciPm9saXZlci5ib3JjaGVydD00MG5p c3QuZ292QGRtYXJjLmlldGYub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVj cmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT47ICdCb3JjaGVy dCwgT2xpdmVyIChGZWQpJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9saXZlci5ib3JjaGVydEBuaXN0 LmdvdiI+b2xpdmVyLmJvcmNoZXJ0QG5pc3QuZ292PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxh IGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUkU6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9y dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KSWUsIEJydW5vIGFuZCBPbGl2ZXI6 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSBmb3IgeW91ciBpbnB1dC4mbmJzcDsmbmJzcDsgWW91IGFy ZSBjb3JyZWN0IHRoYXQgdGhlIGVycm9yIGhhbmRsaW5nIGJlaGF2aW9yIHdhcyB1bmNsZWFyIGJh c2VkIG9uIHRoZSBxdWVzdGlvbnMgaW4gdGhlIGNoYXJ0LiAmbmJzcDsmbmJzcDtUaGUgcHVycG9z ZSBvZiB0aGUgY2hhcnQgaXMNCiB0byBwcm92aWRlIG90aGVyIEJHUCBXR3MgKEJlc3MsIFNQUklO RywgTFNWUikgYSBjbGVhciBpbmRpY2F0aW9uIG9mIGNoYW5nZXMgdG8gdGhlIGJhc2UgQkdQIHNw ZWNpZmljYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJl2ZSByZWZvcm1hdHRlZCBzZWN0aW9ucyA0IGFu ZCA1IG9mIHRoZSBjaGFydC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gc2VjdGlvbiA0IEnigJl2ZSBh ZGRlZDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj40YyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEb2VzIHNl bmQgRXh0ZW5kZWQgTWVzc2FnZSAmbmJzcDstIHdpdGggYSB5ZXMgZnJvbSBhbGwgaW1wbGVtZW50 YXRpb25zIChiYXNlZCBvbiB0aGVpciBlbWFpbCkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiA1LCBJ4oCZ dmUgYWx0ZXIgdG8gYmU6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+NSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBFcnJvciBoYW5kaW5nJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+NWEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQWNjZXB0cyBFeHRlbmRlZCBtZXNzYWdlIHdpdGhvdXQgcmVjZWl2aW5n DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QkdQ IEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eSBbU2VjdGlvbiA1IHBhcmFncmFwaCAxIE1BWV08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+NWImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSWYgcmVjZWl2ZXMgRXh0ZW5kZWQgTWVzc2FnZSB3aXRob3V0IEJHUCBleHRlbmRl ZCBtZXNzYWdlIHN1cHBvcnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDtmb2xsb3dzIFJGQzQyNzEgaGFuZGxpbmcgYW5kIHNlbmRzIEJhZCBtZXNzYWdlIGxl bmd0aCBOb3RpZmljYXRpb24NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtbc2VjdGlvbiA1IHBhcmFncmFwaCAyIE1VU1RdDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9saXZlciDi gJMgaWYgeW91IHdvdWxkIHJlYWQgdGhlIGN1cnJlbnQgdGV4dCBhbmQgbGV0IG1lIGtub3cgdGhl IHVwZGF0ZWQgbWVzc2FnZS4gJm5ic3A7SSBiZWxpZXZlIHRoZSBhbnN3ZXIgZm9yIGFsbCAzIGlt cGxlbWVudGF0aW9ucyBpcyDigJx5ZXPigJ0gZHVlIHRvIDRiLiZuYnNwOyZuYnNwOyBQbGVhc2UN CiBsZXQgbWUga25vdyBhbmQgSSB3aWxsIHVwZGF0ZSB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIGNo YXJ0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRvIGZvbGxvdy11cCBvbiBKaWXigJlzIGNvbW1lbnRzLCB0aGUgdGV4 dCBkaWQgbm90IGFjY3VyYXRlbHkgcmVwcmVzZW50IHRoZSBlcnJvciBoYW5kbGluZy4mbmJzcDsg Jm5ic3A7U2VjdGlvbiA1LCBwYXJhZ3JhcGggMSBoYXMgYSDigJxTSE9VTEQgTk9U4oCdIG1vZGlm aWVkIGJ5IGEg4oCcTUFZ4oCdLCB3aGljaA0KIHJlc3VsdHMgaW4gc2ltcGx5IGEg4oCcTUFZ4oCd LiZuYnNwOyAmbmJzcDtGb3IgcmVhZGFiaWxpdHksIEkgdGhpbmsgdGhlIOKAnFNIT1VMRCBOT1Ti gJ0gcHJvdmlkZXMgdXNlZnVsIGluZm9ybWF0aW9uJm5ic3A7IHRvIHRoZSBpbXBsZW1lbnRlciwg Jm5ic3A7YnV0IGl0IGNhbm5vdCBiZSB0ZXN0ZWQgYWNjdXJhdGVseSB3aGVuIGNvbWJpbmVkIHdp dGggdGhlIOKAnE1BWeKAnS4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MZXQgbWUgZ2l2 ZSB5b3UgYW4gZXhhbXBsZSBvZiB0aGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhlIHBlZXIgZGlkIG5vdCBzZW5kIGEgQkdQIEV4 dGVuZGVkIE1lc3NhZ2UgY2FwYWJpbGl0eSwgYW5kIGl0IGFjY2VwdHMgdGhlIGV4dGVuZGVkIG1l c3NhZ2UgKHdpdGggYSBsZW5ndGggb2YgMTAsMDAwIGJ5dGVzKSwgaXQNCiBjb3VsZCBoYXZlIGEg bGliZXJhbCBwb2xpY3kgb2YgTUFZIGFzIGEgZGVmYXVsdCBpbiB0aGUgaW1wbGVtZW50YXRpb24u ICZuYnNwOyZuYnNwO1RoZSDigJxvbi13aXJl4oCdIG9ic2VydmF0aW9ucyBjYW5ub3QgdGVsbCDi gJMgb25seSB0aGUgaW1wbGVtZW50YXRpb27igJlzIHBvbGljeSAoZGVmYXVsdCAmIzQzOyBjb25m aWd1cmVkKS4mbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbHNvIGJyb2tlIG91dCB0 aGUgbWFuYWdlbWVudCBpbmZvcm1hdGlvbiBhd2F5IGZyb20gdGhlIHNwZWNpZmljYXRpb24gaW5m b3JtYXRpb24uJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN1ZSBIYXJlcyAmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBEb25namllIChKaW1teSkgWzxhIGhyZWY9Im1haWx0bzpqaWUuZG9uZ0BodWF3ZWku Y29tIj5tYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBKYW51YXJ5IDMwLCAyMDE5IDg6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IEJvcmNo ZXJ0LCBPbGl2ZXIgKEZlZCk7IFN1c2FuIEhhcmVzOyA8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVj cmFlbmVAb3JhbmdlLmNvbSI+DQpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPjsgQm9yY2hl cnQsIE9saXZlciAoRmVkKTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRm Lm9yZyI+aWRyQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0lkcl0gV0cg TGFzdCBDYWxsIG9uIEV4dGVuZWQgTWVzc2FnZSBTdXBwb3J0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIE9saXZlciwgQnJ1bm8gYW5kIFN1ZSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRvIG15IHVu ZGVyc3RhbmRpbmcsIGJ1bGxldCA1LzVhLzViIGluIHRoZSBpbXBsZW1lbnRhdGlvbiByZXBvcnQg aXMgY29ycmVzcG9uZGluZyB0byB0aGUgc2Vjb25kIHBhcmFncmFwaCBpbiBzZWN0aW9uIDUg4oCc RXJyb3IgSGFuZGxpbmfigJ06PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWlu ZGVudDo1LjI1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5B IEJHUCBzcGVha2VyIHRoYXQgZG9lcyBub3QgYWR2ZXJ0aXNlIHRoZSBCR1AgRXh0ZW5kZWQgTWVz c2FnZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGNhcGFiaWxp dHkgbWlnaHQgYWxzbyBnZW51aW5lbHkgbm90IHN1cHBvcnQgRXh0ZW5kZWQgTWVzc2FnZXMuJm5i c3A7IFN1Y2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGEgc3Bl YWtlciBNVVNUIGZvbGxvdyB0aGUgZXJyb3IgaGFuZGxpbmcgcHJvY2VkdXJlcyBvZiBbUkZDNDI3 MV0gaWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGl0IHJlY2Vp dmVzIGFuIEV4dGVuZGVkIE1lc3NhZ2UuJm5ic3A7IFNpbWlsYXJseSwgYW55IHNwZWFrZXIgdGhh dCB0cmVhdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGFuIGlt cHJvcGVyIEV4dGVuZGVkIE1lc3NhZ2UgYXMgYSBmYXRhbCBlcnJvciwgTVVTVCB0cmVhdCBpdDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgc2ltaWxhcmx5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGh1cyBpdCBpcyB0byBkZXNjcmliZSB0aGUgZXJyb3IgaGFuZGxpbmcgYmVoYXZpb3Ig b2YgYW4gaW1wbGVtZW50YXRpb24gdmVyc2lvbiB3aGljaCBkb2VzIG5vdCBzdXBwb3J0IGV4dGVu ZGVkIG1lc3NhZ2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoaWxlIEkgYWdyZWUgdGhpcyBjb3VsZCBiZSBtaXNs ZWFkaW5nIGZvciBhIHJlcG9ydCBvZiBpbXBsZW1lbnRhdGlvbiB3aGljaCBzdXBwb3J0cyBleHRl bmRlZCBtZXNzYWdlIGNhcGFiaWxpdHksIG1heWJlIGl0IGNvdWxkIGJlIHVzZWQgdG8gdmVyaWZ5 IHRoZSBiZWhhdmlvcg0KIG9mIGFuIG9sZCB2ZXJzaW9uIHdoaWNoIGRvZXMgbm90IHN1cHBvcnQg dGhpcyBjYXBhYmlsaXR5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5KaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBJZHIgWzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv Omlkci1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Qm9yY2hlcnQs IE9saXZlciAoRmVkKTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMzAsIDIw MTkgNDozNSBBTTxicj4NCjxiPlRvOjwvYj4gU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0 bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7OyA8YSBocmVmPSJtYWls dG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+DQpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29t PC9hPjsgQm9yY2hlcnQsIE9saXZlciAoRmVkKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9saXZlci5i b3JjaGVydEBuaXN0LmdvdiI+b2xpdmVyLmJvcmNoZXJ0QG5pc3QuZ292PC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1l c3NhZ2UgU3VwcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QnJ1bm8gYW5kIFN1c2FuLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGNhbm5vdCBzcGVhayBmb3IgdGhlIEV4 YUJHUCBJbXBsZW1lbnRhdGlvbiBidXQgZm9yIEJHUFNFQy1JTyBhbmQgUXVhZ2dhU1J4LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SSBiZWxpZXZlIHdoZW4gSSBjb21waWxlZCB0aGUgcmVwb3J0LCBJIG1pcy1y ZWFkIDVhIGFuZCBvdmVybG9va2VkIHRoZSDigJxub3TigJ0gYW5kIHJlYWQgaW5zdGVhZDog4oCc RG9lcyBzZW5kIEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eeKAnS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlRoZXJlZm9yZSB0aGUgaW1wbGVtZW50YXRpb24gcmVwb3J0IGZvciBzZWN0aW9uIDVhIG11c3Qg YmUgY29ycmVjdGVkIGZyb20g4oCcWWVz4oCdIGludG8g4oCcTm/igJ0gZm9yIGJvdGggQkdQU0VD LUlPIGFuZCBRdWFnZ2FTUng8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ QkdQU0VDLUlPIGFuZCBRdWFnZ2FTUngsIGJvdGggZG8gc2VuZCB0aGUgZXh0ZW5kZWQgbWVzc2Fn ZSBjYXBhYmlsaXR5IGlmIHNvIGNvbmZpZ3VyZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGp1c3QgY2hl Y2tlZCB0aGUgY29kZSBhbmQgcnVuIGl0IGFnYWluLiBJIGNvcHkvcGFzdGVkIHRoZSByZWxldmFu dCBvdXRwdXQgZ2VuZXJhdGVkIGJ5IEJHUFNFQy1JTyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+T2xpdmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPi0tLS0tJm5ic3A7IG91dHB1dCBvZiBCR1BTRUMtSU8mbmJzcDsgLS0tLS0tLTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7vu78uL2JncHNlY2lvIC1mIGJncHNlY2lv LnRlc3QuY2ZnLnFzcngNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3RhcnRpbmcgYmdwc2VjaW8gMC4yLjAu MjUuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlbmQ6Jm5ic3A7IChPcGVuIG1lc3NhZ2Ugc2VuZCBmcm9t IEJHUFNFQy1JTyB0byBRdWFnZ2FTUngpDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9QRU4gTWVzc2FnZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7ICYjNDM7LS1tYXJrZXI6IEZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tT3B0aW9uYWwgUGFyYW1ldGVyOiBDYXBhYmlsaXR5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tVHlw ZTogQ2FwYWJpbGl0eSAoMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7ICYjNDM7LS1MZW5ndGg6IDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1DYXBhYmlsaXR5OiBFeHRlbmRlZCBtZXNzYWdlIHN1 cHBvcnQgY2FwYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLVR5cGU6IEV4dGVuZGVkIG1lc3NhZ2Ug c3VwcG9ydCBjYXBhYmlsaXR5ICg2KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLUxlbmd0aDogMDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlY2Vp dmVkOiAoT3BlbiBtZXNzYWdlIHNlbmQgZnJvbSBRdWFnZ2FTUnggYW5kIHJlY2VpdmVkIGJ5IEJH UFNFQy1JTyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9QRU4gTWVzc2FnZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7ICYjNDM7LS1tYXJrZXI6IEZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm IzQzOy0tT3B0aW9uYWwgUGFyYW1ldGVyOiBDYXBhYmlsaXR5PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLVR5cGU6IENhcGFi aWxpdHkgKDIpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstLUxlbmd0aDogMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1DYXBhYmlsaXR5OiBFeHRlbmRl ZCBtZXNzYWdlIHN1cHBvcnQgY2FwYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1U eXBlOiBFeHRlbmRlZCBtZXNzYWdlIHN1cHBvcnQgY2FwYWJpbGl0eSAoNik8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmIzQzOy0tTGVuZ3RoOiAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CR1AtcmVjZWl2ZXIgdGhy ZWFkIGNyZWF0ZWQhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5j ZXNAaWV0Zi5vcmciPmlkci1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFN1 c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6 aC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDI5LCAyMDE5 IGF0IDExOjQzIEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8u ZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNy YWVuZUBvcmFuZ2UuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1h aWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBbSWRyXSBXRyBMYXN0IENhbGwgb24gRXh0ZW5lZCBNZXNzYWdlIFN1cHBvcnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJydW5vOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzIG9uIHRoaXMg dG9waWMg4oCTIGFzIEkgdGhpbmsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkaWQgcmVjZWl2 ZSByZXBvcnRzIHByaXZhdGVseSB0aGF0IHdlIGhhdmUgMSBmdWxsIGltcGxlbWVudGF0aW9ucyBv ZiBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMgb2ZmIGxpc3Qgd2hpY2ggaXMg bm90IGxpc3RlZCBpbg0KIHRoaXMgcmVwb3J0LiAmbmJzcDsmbmJzcDtJIGhvcGUgdGhvc2UgaW1w bGVtZW50ZXJzIHdpbGwgdm9sdW50ZWVyIHRoaXMgaW5mb3JtYXRpb24gb24gdGhlIGxpc3QuICZu YnNwOyZuYnNwO0lmIG5vdCwgSSB3aWxsIHNoYXJlIHRoaXMgaW5mb3JtYXRpb24gd2l0aCBBbHZh cm8gYW5kIHRoZSBJRVNHLiZuYnNwOyAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBT SURSIHdvcmsgZGlkIGRlZmluZSBkcmFmdC1pZXRmLWJncC1leHRlbmRlZC1tZXNzYWdlcyBhcyBh IHJlcXVpcmVtZW50IGFuZCBvbmx5IG1vdmVkIHRvIG5vdCBzcGVjaWZ5aW5nIGl0IHdoZW4gd2Ug Y291bGQgbm90IHF1aWNrbHkgcGFzcw0KIHRoaXMgdGhyb3VnaCBXRyBMQy4gPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGUgcmVhbCBuZWVkcyBhcmUgYSBncm93aW5nIEJHUC1MUyB0aGF0IG1heSBy dW4gb3V0IG9mIEJHUCBtZXNzYWdlIHNwYWNlLiZuYnNwOyBBcyBteSBwcmV2aW91cyBlbWFpbCB0 byBJRFIgaW5kaWNhdGVzLCBJIHdhcyBob3BpbmcgdGhpcyBoYW5kbGVzDQogYW4gQkdQIG1lc3Nh Z2Ugd2hvc2UgbGVuZ3RoIGlzIGJpZ2dlciB0aGFuIDQwOTYgYnl0ZXMuJm5ic3A7ICZuYnNwO1Ro YW5rIHlvdSBmb3IgdGhlIGNvcnJlY3Rpb24gb2Y6DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj7igJxU aGUgaXNzdWUgaXMgbm90IHNwZWNpZmljIHRvIGF0dHJpYnV0ZXMgYmlnZ2VyIHRoYW4gNDA5NiBv Y3RldHMsIGJ1dCB0byBCR1AgbWVzc2FnZSB3aG9zZSBsZW5ndGggaXMgYmlnZ2VyIHRoYW4gNDA5 NiwgaXJyZXNwZWN0aXZlIG9mIHRoZSBzaXplDQogb2YgZWFjaCBhdHRyaWJ1dGUu4oCdPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QXMg dG8geW91ciBjb21tZW50Og0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAnFdoeSBpcyB0aGlzIGxpbWl0ZWQgdG8gZnV0dXJl IHNwZWNpZmljYXRpb25zPyBBIHByaW9yaSwgdXNpbmcgZXhpc3RpbmcgQkdQIG1lY2hhbmlzbSAo QUZJL1NBRkksIGF0dHJpYnV0ZXMsICogY29tbXVuaXRpZXMpIG9uZSBjb3VsZCBleGNlZWQgdGhl IHNpemUgb2YgNDA5Ng0KIG9jdGV0cy4gSG93IGRvZXMgdGhlIEJHUCBzcGVha2VyIHN1cHBvc2Vk IHRvIGJlaGF2ZSBpbiB0aGlzIGNhc2U/IFRoaXMgc2hvdWxkIGJlIGRlc2NyaWJlZCBpbiB0aGlz IHNwZWNpZmljYXRpb24uIE5vdGUgdGhhdCB0aGlzIGlzIG5vdCBhIGNhc2Ugb2YgZXJyb3IgaGFu ZGxpbmcsIGFzIGV2ZXJ5IEJHUCBzcGVha2VyIGlzIGJlaGF2aW5nIGFzIHNwZWNpZmllZC7igJ08 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhpcyBw cm9ibGVtIGhhcyBiZWVuIHRydWUgZm9yIHllYXJzLCBhbmQgdGh1cyBhcyBjby1jaGFpcnMgaGFk IGhvcGVkIHRvIGhhdmUgdGhlIGRyYWZ0LWlldGYtYmdwLWV4dGVuZGVkLW1lc3NhZ2VzIHBhc3Nl ZCB5ZWFycyBhZ28uICZuYnNwOyZuYnNwO0FzIEJHUC1MUyBhdHRyaWJ1dGVzDQogZ3JvdyB1c2Ug YW5kIGluIG51bWJlciwgdGhlIHBvdGVudGlhbCBvZiBleGNlZWRpbmcgdGhlIEJHUCBtZXNzYWdl IGxpbWl0IGluY3JlYXNlcy4gJm5ic3A7SXQgc2VlbXMgbGlrZSBhIGdvb2QgZGlyZWN0aW9uIHRv IHByZXZlbnQgaXNzdWVzLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPkkgaG9wZSB0aGUgYXV0aG9ycyB3aWxsIGNvbW1lbnQgb24gdGhlIGNoYW5n ZXMgeW91IHN1Z2dlc3RlZCB0byB0aGUgdGV4dC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DaGVlcnMsDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PlN1c2FuIEhhcmVzDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPiBbPGEg aHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPm1haWx0bzpicnVuby5kZWNy YWVuZUBvcmFuZ2UuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5 IDI5LCAyMDE5IDg6MzMgQU08YnI+DQo8Yj5Ubzo8L2I+IFN1c2FuIEhhcmVzPGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJFOiBbSWRyXSBXRyBMYXN0IENhbGwgb24gRXh0ZW5lZCBNZXNzYWdl IFN1cHBvcnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkhpIFdHLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGxl YXNlIGZpbmQgYmVsb3cgc29tZSBjb21tZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+QXMgb2YgdG9kYXksIEkgZG9u4oCZdCBiZWxpZXZlIHRoaXMgc3BlY2lmaWNh dGlvbiBpcyByZWFkeSB0byBiZSBwcm9ncmVzc2VkIHRvIElFU0cvUkZDLCBlc3BlY2lhbGx5IGZv ciBhIGRvY3VtZW50IHVwZGF0aW5nIFJGQyA0MjcxIChjb3JlIEJHUCBzcGVjKS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mZ3Q7IFRoZSBXRyBjaGFpcnMgaW50ZW5kIHRvIGZvcndhcmQgdGhpcyBk cmFmdCB0byB0aGUgSUVTRyB3aXRoIHRoZSBjdXJyZW50IGxldmVsIG9mIGltcGxlbWVudGF0aW9u LiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIC4uNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRyYWMuaWV0Zi5vcmcl MkZ0cmFjJTJGaWRyJTJGd2lraSUyRmRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1l bnRhdGlvbnMmYW1wO2RhdGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdD NDBiYjhhOTQzZTYxNGIxNjM3ZjMwOGQ2ODYwOGQ2Y2QlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1 NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2ODQzNzY5ODU5MTY1MDQzJmFtcDtzZGF0YT1oWEJiT1hx d3ZYcXRDViUyQjlQYlAlMkY3SUU2V0pqV1VBMmJvTTMzS2RzJTJCZ2g0JTNEJmFtcDtyZXNlcnZl ZD0wIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9pZHIvd2lraS9kcmFmdC1pZXRmLWlkci1i Z3AtZXh0ZW5kZWQtaW1wbGVtZW50YXRpb25zPC9hPg0KIHNheXMgOiA8L3NwYW4+NWEgPG86cD48 L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgbm90IHNlbmQgRXh0ZW5kZWQgTWVzc2Fn ZSBjYXBhYmlsaXR5IDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzou NzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgPG86cD48 L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcyA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIC4uNzVwdCAuNzVwdCAuNzVwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwv dGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+SSBtYXkgYmUgbWlzdW5kZXJzdGFuZGluZyB0aGUgaW1wbGVtZW50YXRpb24gcmVwb3J0 LCBidXQgbXkgcmVhZGluZyBvZiB0aGUgYWJvdmUgaXMgdGhhdCBub25lIG9mIHRoZSByZXBvcnRl ZCBpbXBsZW1lbnRhdGlvbnMgc2VuZHMgdGhlIGNhcGFiaWxpdHkNCiBoZW5jZSBubyBpbXBsZW1l bnRhdGlvbiBzdXBwb3J0cyBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMuLiBI ZXJlIHRoaXMgZG9jdW1lbnQgaXMgdXBkYXRpbmcgUkZDIDQyNzEsIHNvIGl0IGlzIG5vdCBhIG1p bm9yIGV4dGVuc2lvbiBmb3IgYSBuaWNoZSB1c2UgY2FzZS4gU28gSSBkb27igJl0IHNlZSB0aGUg YXJndW1lbnRzIGZvciBub3QgcmVxdWlyaW5nIHRoZSBJRFLigJlzIHVzdWFsIHR3byBpbnRlcm9w ZXJhYmxlIGltcGxlbWVudGF0aW9ucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+LS0tLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij7CpyAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJwgQXMgQkdQIGlzIGV4dGVuZGVkIHRv IHN1cHBvcnQgbmV3ZXIgQUZJL1NBRklzIGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IG5ld2VyIGNhcGFiaWxpdGllcyAoZS5nLiwgWzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1p ZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTI3JTIzcmVmLUktRC5pZXRmLXNpZHItYmdwc2VjLXBy b3RvY29sJmFtcDtkYXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3QzQw YmI4YTk0M2U2MTRiMTYzN2YzMDhkNjg2MDhkNmNkJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2 NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjg0Mzc2OTg1OTE2NTA0MyZhbXA7c2RhdGE9dVpTJTJCYk45 djVjaXIybzVMM1UzalAyeEZQYlk0VHolMkZObkJQZmRIN2lEZjAlM0QmYW1wO3Jlc2VydmVkPTAi IHRpdGxlPSImcXVvdDtCR1BTRUMgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiZxdW90OyI+PHNwYW4g bGFuZz0iRU4tVVMiPkktRC5pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sPC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPl0pLA0KIHRoZXJlIGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgYSBuZWVkIHRvIGV4dGVuZCB0aGUgbWF4aW11bSBtZXNzYWdlIHNpemUgYmV5b25kIDQw OTYgb2N0ZXRzLiZuYnNwOyDigJw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZk cmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMjclMjNzZWN0aW9uLTEmYW1wO2Rh dGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDNDBiYjhhOTQzZTYxNGIx NjM3ZjMwOGQ2ODYwOGQ2Y2QlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzEl N0MwJTdDNjM2ODQzNzY5ODU5MTY1MDQzJmFtcDtzZGF0YT1ZVldIQUZiWVJqRyUyRmxXUGJwdzJy Vzh1R1E2UVhzczNkdWZtJTJGcUhnUnZEdyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0yNyNz ZWN0aW9uLTE8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5bPC9z cGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNz YWdlcy0yNyUyM3JlZi1JLUQuaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbCZhbXA7ZGF0YT0wMiU3 QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJiOGE5NDNlNjE0YjE2MzdmMzA4 ZDY4NjA4ZDZjZCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2 MzY4NDM3Njk4NTkxNjUwNDMmYW1wO3NkYXRhPXVaUyUyQmJOOXY1Y2lyMm81TDNVM2pQMnhGUGJZ NFR6JTJGTm5CUGZkSDdpRGYwJTNEJmFtcDtyZXNlcnZlZD0wIiB0aXRsZT0iJnF1b3Q7QkdQU0VD IFByb3RvY29sIFNwZWNpZmljYXRpb24mcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5JLUQuaWV0 Zi1zaWRyLWJncHNlYy1wcm90b2NvbDwvc3Bhbj48L2E+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+aXMgbm93IFJGQyA4MjA1ICh0aGFua3MgZm9yIHVwZGF0aW5nIHRoZSByZWZl cmVuY2UpLiBJdCBoYXMgcmVtb3ZlZCB0aGUgbm9ybWF0aXZlL2FueSByZWZlcmVuY2UgdG8gZHJh ZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLiBTbyBwcmVzdW1hYmx5IEJHUCBTZWMg ZG9lcyBub3QgbmVlZCBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNhbiB3ZSBoYXZlIGFuIHVwZGF0ZSBv biB0aGlzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYW4gdGhlIGlu dHJvZHVjdGlvbiBvZg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5kcmFmdC1pZXRmLWlkci1i Z3AtZXh0ZW5kZWQtbWVzc2FnZXMgYmUgdXBkYXRlZCB0byBpbnRyb2R1Y2Ugb24gdGhlIHJlYWwg cmVhc29ucy9uZWVkcz88L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7CpzQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij7CpzMgc2F5cyDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkEgcGVlciB3aGljaCBkb2VzIG5vdCBhZHZl cnRpc2UgdGhpcyBjYXBhYmlsaXR5IE1VU1QgTk9UIHNlbmQgQkdQPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7ICZuYnNwO0V4dGVuZGVkIE1lc3NhZ2VzLCBhbmQgQkdQIEV4dGVuZGVk IE1lc3NhZ2VzIE1VU1QgTk9UIGJlIHNlbnQgdG8gaXQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+RmluZS4gVGV4dCBpbiDCpzQgc2hvdWxkIHByb2JhYmx5IGJlIGFsaWduZWQgd2l0 aCB0aGUgYWJvdmUgLi5lLmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+T0xE OiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPkEgQkdQIHNwZWFrZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgTUFZIHNlbmQgRXh0ZW5kZWQgTWVzc2FnZXMgdG8gaXRzIHBlZXIgb25s eSBpZiBpdCBoYXMgcmVjZWl2ZWQgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgRXh0ZW5kZWQgTWVzc2FnZSBDYXBhYmlsaXR5IGZyb20gdGhhdCBwZWVyLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TkVXOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+QSBCR1Agc3BlYWtlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IE1BWSBzZW5kIEV4dGVuZGVkIE1lc3NhZ2VzIHRvIGl0cyBwZWVyIG9ubHkgaWYgaXQgaGFz IHNlbnQgYW5kIHJlY2VpdmVkIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eSB0byBhbmQgZnJvbSB0aGF0IHBlZXIuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS08L3NwYW4+ PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj7igJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBBcHBsaWNhdGlvbnMgZ2VuZXJhdGluZyBpbmZvcm1hdGlvbiB3aGljaCBtaWdodCBiZSBl bmNhcHN1bGF0ZWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgd2l0aGlu IEJHUCBtZXNzYWdlcyBNVVNUIGxpbWl0IHRoZSBzaXplIG9mIHRoZWlyIHBheWxvYWQgdG8gdGFr ZSB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBtYXhpbXVtIG1lc3NhZ2Ug c2l6ZSBpbnRvIGFjY291bnQu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBkb27igJl0IHNlZSB3aGF0IG5ldyBi ZWhhdmlvciBpcyBiZWVuIGRlZmluZWQgaGVyZS4gSWYgdGhlcmUgaXMgbm9uZSwgSSB3b3VsZCBz dWdnZXN0IHRvIHJlbW92ZSB0aGlzIHNlbnRlbmNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgQSBCR1AgYW5ub3VuY2VtZW50IHdpbGwsIGluIHRoZSBub3JtYWwgY2FzZSwgcHJv cGFnYXRlIHRocm91Z2hvdXQgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg QkdQIHNwZWFraW5nIEludGVybmV0OyBhbmQgdGhlcmUgd2lsbCB1bmRvdWJ0ZWRseSBiZSBCR1Ag c3BlYWtlcnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB3aGljaCBkbyBub3Qg aGF2ZSB0aGUgRXh0ZW5kZWQgTWVzc2FnZSBjYXBhYmlsaXR5LiZuYnNwOyBUaGVyZWZvcmUsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcHV0dGluZyBhbiBhdHRyaWJ1dGUgd2hp Y2ggY2FuIG5vdCBiZSBkZWNvbXBvc2VkIHRvIDQwOTYgb2N0ZXRzIG9yPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbGVzcyBpbiBhbiBFeHRlbmRlZCBNZXNzYWdlIGlzIGEgbGlr ZWx5IHBhdGggdG8gcm91dGluZyBmYWlsdXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBpc3N1ZSBpcyBub3Qgc3BlY2lmaWMgdG8gYXR0 cmlidXRlcyBiaWdnZXIgdGhhbiA0MDk2IG9jdGV0cywgYnV0IHRvIEJHUCBtZXNzYWdlIHdob3Nl IGxlbmd0aCBpcyBiaWdnZXIgdGhhbiA0MDk2LCBpcnJlc3BlY3RpdmUgb2YgdGhlDQogc2l6ZSBv ZiBlYWNoIGF0dHJpYnV0ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+UGxlYXNlIGVsYWJvcmF0ZSBvbiB3aGF0IHlvdSBtZWFuIGJ5IOKAnDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+YW4gYXR0cmlidXRlIHdoaWNoIGNhbiBub3QgYmUgZGVjb21wb3NlZA0KIHRv IDQwOTYgb2N0ZXRz4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAnCZuYnNwOyZuYnNwOyBJdCBp cyBSRUNPTU1FTkRFRCB0aGF0IEJHUCBwcm90b2NvbCBkZXZlbG9wZXJzIGFuZCBpbXBsZW1lbnRl cnMgYXJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY29uc2VydmF0aXZlIGlu IHRoZWlyIGFwcGxpY2F0aW9uIGFuZCB1c2Ugb2YgRXh0ZW5kZWQgTWVzc2FnZXMu4oCdPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+V2hhdCBkb2VzIHRoaXMgbWVhbiBleGFjdGx5PyBUaGF0IHRoZXkgZG9u4oCZdCB1c2Ug dGhpcyBleHRlbnNpb24/IFRoYXQgdGhleSBkb27igJl0IHVzZSB0aGlzIGV4dGVuc2lvbiB1bmxl c3MgWFhfVE8gQkUgU1BFQ0lGSUVEX1hYPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+LS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgRnV0 dXJlIHByb3RvY29sIHNwZWNpZmljYXRpb25zIHdpbGwgbmVlZCB0byBkZXNjcmliZSBob3cgdG8g aGFuZGxlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcGVlcnMgd2hpY2ggY2Fu IG9ubHkgYWNjb21tb2RhdGUgNDA5NiBvY3RldCBtZXNzYWdlcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPldoeSBpcyB0aGlzIGxpbWl0ZWQgdG8gZnV0dXJlIHNwZWNp ZmljYXRpb25zPyBBIHByaW9yaSwgdXNpbmcgZXhpc3RpbmcgQkdQIG1lY2hhbmlzbSAoQUZJL1NB RkksIGF0dHJpYnV0ZXMsICogY29tbXVuaXRpZXMpIG9uZSBjb3VsZCBleGNlZWQgdGhlIHNpemUN CiBvZiA0MDk2IG9jdGV0cy4gSG93IGRvZXMgdGhlIEJHUCBzcGVha2VyIHN1cHBvc2VkIHRvIGJl aGF2ZSBpbiB0aGlzIGNhc2U/IFRoaXMgc2hvdWxkIGJlIGRlc2NyaWJlZCBpbiB0aGlzIHNwZWNp ZmljYXRpb24uIE5vdGUgdGhhdCB0aGlzIGlzIG5vdCBhIGNhc2Ugb2YgZXJyb3IgaGFuZGxpbmcs IGFzIGV2ZXJ5IEJHUCBzcGVha2VyIGlzIGJlaGF2aW5nIGFzIHNwZWNpZmllZC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tLS0tPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlcGVuZGlu ZyBvbiB0aGUgYWJvdmUgc3BlY2lmaWNhdGlvbiwgYSBzZWN0aW9uIGRlc2NyaWJpbmcgdGhlIG9w ZXJhdGlvbmFsIGNvbnNlcXVlbmNlcyBpbiBhIG5ldHdvcmsgKHN1Y2ggYXMgdGhlIEludGVybmV0 LCBCR1AgRW5hYmxlZA0KIFNlcnZpY2VTL1ZQTiBuZXR3b3JrcykgaXMgcHJvYmFibHkgbmVlZGVk LiBQb3NzaWJsZSBjb25zZXF1ZW5jZXMgY291bGQgYmUgQkdQIE5MUkkgYmVpbmcgcmVtb3ZlZCBp biB0aGUgbWlkZGxlIG9mIHN1Y2ggbmV0d29yaywgb3IgKGV4dGVuZGVkKSBjb21tdW5pdHkgKHN1 Y2ggYXMgUm91dGUgVGFyZ2V0cykgYmVlbiByZW1vdmVkLiBCb3RoIGhhdmluZyBzaWduaWZpY2Fu dCBjb25zZXF1ZW5jZXMgb24gdGhlIGF2YWlsYWJpbGl0eSBwcm92aWRlZA0KIGJ5IHRoZSBuZXR3 b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ LS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPsKn NDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T0xEOiBUaGUgRXh0ZW5kZWQgTWVzc2FnZSBDYXBhYmls aXR5IG9ubHkgYXBwbGllcyB0byBhbGwgbWVzc2FnZXMgZXhjZXB0IGZvciB0aGUgT1BFTiBtZXNz YWdlLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Qcm9iYWJseTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+TkVXOiBUaGUgRXh0ZW5kZWQgTWVzc2FnZSBDYXBhYmlsaXR5IGFwcGxpZXMgdG8gYWxsIG1l c3NhZ2UgdHlwZXMgZXhjZXB0IGZvciB0aGUgT1BFTiBtZXNzYWdlICh0eXBlIDEpLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7Cpzg8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCc VGhpcyBleHRlbnNpb24gdG8gQkdQIGRvZXMgbm90IGNoYW5nZSBCR1AncyB1bmRlcmx5aW5nIHNl Y3VyaXR5IGlzc3VlcyZuYnNwO8K7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CZWZvcmUgZXZhbHVhdGluZyB0aGlzLCBJ IHRoaW5rIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGZpcnN0IHNwZWNpZmllZCBob3cgYSBCR1AgbWVz c2FnZXMgYmlnZ2VyIHRoYW4gNDA5NiBvY3RldHMgaXMgaGFuZGxlZCB3aGVuIGl0IG5lZWRzIHRv IGJlIHNlbnQgdG8gYSByZWNlaXZlZCBub3Qgc3VwcG9ydGluZyB0aGlzIGV4dGVuc2lvbi48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Tml0czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9MRCZu YnNwOzogdG8gcmVkdWNlIGNvbXBleGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TkVXJm5ic3A7 OiB0byByZWR1Y2UgY29tcGxleGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LS1CcnVubzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJZHIg WzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmlkci1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3VzYW4gSGFyZXM8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAyOSwgMjAxOSAxMjozMyBQTTxicj4NCjxiPlRvOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBbSWRyXSBXRyBMYXN0IENhbGwgb24gRXh0ZW5lZCBNZXNzYWdlIFN1cHBv cnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgYmVn aW5zIGEgMiB3ZWVrIFdHIExDIG9uIEV4dGVuZGVkIE1lc3NhZ2UgU3VwcG9ydCBmb3IgQkdQIChk cmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMjcpLiZuYnNwOyBZb3UgY2FuIGFj Y2VzcyB0aGUgZHJhZnQgYXQ6DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRy YWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2Fn ZXMlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDNDBi YjhhOTQzZTYxNGIxNjM3ZjMwOGQ2ODYwOGQ2Y2QlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1 NWM2MWRlYyU3QzElN0MwJTdDNjM2ODQzNzY5ODU5MzIxMjg5JmFtcDtzZGF0YT1va2pUZUxlNkRj VGFSVjJVU3kyTXk2SFhEUnludXBtWGxCMGk3Z1V3eW5BJTNEJmFtcDtyZXNlcnZlZD0wIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMvPC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlIGF1dGhvcnMgc2hvdWxkIGlu ZGljYXRlIHdoZXRoZXIgdGhleSBrbm93IG9mIGFueSBJUFIuJm5ic3A7Jm5ic3A7IEltcGxlbWVu dGVycyBhcmUgZW5jb3VyYWdlZCB0byB1cGRhdGUgdGhlJm5ic3A7IGltcGxlbWVudGF0aW9uIGRh dGEgYXQ6DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdHJhYy5pZXRmLm9yZyUyRnRy YWMlMkZpZHIlMkZ3aWtpJTJGZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLWltcGxlbWVudGF0 aW9ucyZhbXA7ZGF0YT0wMiU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M0MGJi OGE5NDNlNjE0YjE2MzdmMzA4ZDY4NjA4ZDZjZCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1 YzYxZGVjJTdDMSU3QzAlN0M2MzY4NDM3Njk4NTkzMjEyODkmYW1wO3NkYXRhPVBvUnlGb2ZzMDQl MkZDJTJGJTJGZ2JYTDJ6eUVEM1NXNk1yRVNwSGlJRTJlN3A0Y0ElM0QmYW1wO3Jlc2VydmVkPTAi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lk ci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRhdGlvbnM8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgZHJh ZnQgcHJvdmlkZXMgYSBtZWFucyBmb3IgZXhwYW5kaW5nIHRoZSBCR1AgbWVzc2FnZSB0byA2NTUz NSBvY3RldHMgZm9yIGFsbCBtZXNzYWdlcyBleGNlcHQgT1BFTiBtZXNzYWdlcy4mbmJzcDsgQkdQ IG1lc3NhZ2Ugc3BhY2UgaXMgcnVubmluZw0KIHNob3J0IGZvciBhbGwgb2YgdGhlIHBvdGVudGlh bCBhdHRyaWJ1dGVzIG9yIGFkZGl0aW9ucyBwcm9wb3NlZCBieSBCR1AtTFMgZmVhdHVyZXMuJm5i c3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PlRoZSBXRyBjaGFpcnMgaW50ZW5kIHRvIGZvcndhcmQgdGhpcyBkcmFmdCB0byB0aGUgSUVTRyB3 aXRoIHRoZSBjdXJyZW50IGxldmVsIG9mIGltcGxlbWVudGF0aW9uLiZuYnNwOw0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BcyB5b3UgY29tbWVu dCBvbiB0aGUgZHJhZnQsIHBsZWFzZSBjb25zaWRlciBpZjogYSkgdGhlIHRlY2hub2xvZ3kgaXMg bWF0dXJlLCBiKSB0aGUgYWRkaXRpb25hbCBzcGFjZSBpbiBhIEJHUCBtZXNzYWdlIHdvdWxkIGJl IGhlbHBmdWwNCiBmb3IgdGhvc2UgZGVwbG95aW5nIEJHUC1MUyBvciBTUiwgYW5kIGMpIGlmIHRo ZSBzcGVjaWZpY2F0aW9uIGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4mbmJzcDsNCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U3VlIEhhcmVzIChX RyBDaGFpciwgU2hlcGhlcmQpDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5DZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5w YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25z b2xhcyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXMiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpDb25zb2xhcyI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXMiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDb25zb2xhcyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXMiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpDb25zb2xhcyI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+SWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+QXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPlRoYW5rIHlvdS48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1E129C9297F74E25AB5B6E9A921D679Dciscocom_-- From nobody Tue Feb 12 12:56:54 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EB8130DC2; Tue, 12 Feb 2019 12:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIDlohuEgOdS; Tue, 12 Feb 2019 12:56:47 -0800 (PST) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA0812F1A6; Tue, 12 Feb 2019 12:56:43 -0800 (PST) Received: by mail-ot1-x342.google.com with SMTP id n71so114157ota.10; Tue, 12 Feb 2019 12:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=tSjbW6L7syNMOLBKysWWXBNdgGMH4CjcWCBcczBXh5E=; b=Vdw7Kfy7jSBkvz0m8PXkpyQFMWXP+a4p9+ZDekyvp8oTEifzIiRss7B64tuSzuZDRn tJrEXohFRdSVwpiqZ77INk35lv1na5HoPo3k+eKPLaL03nJXa93va1cMt5PTTjAURKY4 KVuhdajqGTrZtc2h/bmYpW0zOSLbabobZdqmQOQHfcauEeFi2Dxq/ES6APfaqKqTCufi qIBuxy5jMwi4392PXCt1BxLgojP6+fn25k10Oe/YH3eoCq3qZAuYdFYrMW3SyYoTqNRw 6X+t/bCkX+Qs+0iABUhPArNdYS0tc20ZjH/Ja74d37f9/zdu6e5ZuH+wKRNutOTZYB6T 4rBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=tSjbW6L7syNMOLBKysWWXBNdgGMH4CjcWCBcczBXh5E=; b=Z8oP+hacLsnC0/cHLrV2joOILFqo1lvr6u7TMaVr4a5DfeVOZF+cy+Rg5LZwt9an/Z ywhEBDLoIf5wKdcfK6tmw7yMITeFyBSmq/jYoDD8QOKu2/tMHUsOPpYr3LfJFw2vvFtT pbIzEV4muFPFrNkcbCCV65s4PTBTNQLsp1YMW1+H0tIAB52h0GrPX+TwUEBO/42EUk8e MUCdowXzUpGBWDd3/ddwnDFoJ2jf5Y5UQ0emRyHQEsxOdLgq3OEORnhStJl88CJtlGpG /Oxv9A/hsb6DeycVwx/9IQkLmnJrcVOr5POTgRncbXkgz4U5U6w3Yy7PaV6qaNZVRogS WdwA== X-Gm-Message-State: AHQUAubp/Qa/9Wv8TNfXp3AtEHwDT2ORru7dIPNQLB/yhQ8s03vecUsC VTuLDAzj8YqFEsBFTutJmfF/EZz2Ex5YlZKJdYHu3g== X-Google-Smtp-Source: AHgI3IZ75kyIoEbS5Iqo05UFRJQYB+0pojWj6j3N0iDPVxz7nNoFCIvHtbXdF45bcVZweTDs8J89/q4j+e1koZTIw/I= X-Received: by 2002:a9d:3de2:: with SMTP id l89mr5925768otc.239.1550005001687; Tue, 12 Feb 2019 12:56:41 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 12 Feb 2019 15:56:40 -0500 From: Alvaro Retana MIME-Version: 1.0 Date: Tue, 12 Feb 2019 15:56:40 -0500 Message-ID: To: draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org Cc: Susan Hares , idr-chairs@ietf.org, "idr@ietf. org" Content-Type: multipart/alternative; boundary="0000000000008698d60581b8a910" Archived-At: Subject: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext-11 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 20:56:54 -0000 --0000000000008698d60581b8a910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear authors: I just finished my review of this document -- please see inline comments/questions. In general, I think that there is more work needed in at least two fronts: (1) Consistency in the specification of the new TLVs. Most of the descriptions point at other documents, but they don't do so in a consistent manner: some at the start of the section, others when pointing at the values, etc. Please be consistent! Given that =C2=A72.4/2.5 already have = a summary, I personally find the information in the individual sections redundant. Instead of a statement at the start of a section, I prefer you to be specific about the values -- see =C2=A72.1.2 for an example. Please note that most of my comments related to the specification of the TLVs apply to multiple sections, not just the one where I made them. I pointed this out in most cases, but may have missed some. (2) Error Handling. As has been discussed on the list (for example in [1], [2] and [3]), rfc7752 could use enhancements as it relates to considering error handling with applications such as SR, and in general. Those issues don't need to be fixed in this document, but I would like to see in this document some text about the potential effect: maybe in terms of the effect than an error might have from an operations or management point of view... See my comments below for specifics. Again, not looking for this document to "fix" BGP-LS, but to consider the effect on the expected function a controller might have, as described in the Introduction. [1] https://mailarchive.ietf.org/arch/msg/idr/Tm0vlu-ECSnIAyO1byj68AJm2XU [2] https://mailarchive.ietf.org/arch/msg/idr/0qsjuVaEhroKInHZMohP6HnsWd8 [3] https://mailarchive.ietf.org/arch/msg/idr/-CZGAiC8D3KogLnUs6ClW_KlU24 Thanks! Alvaro. [Line numbers come from idnits.] ... 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. [major] Please use the rfc8174 template. ... 99 1. Introduction ... 110 Two types of IGP segments are defined, Prefix segments and Adjacency 111 segments. Prefix segments, by default, represent an ECMP-aware 112 shortest-path to a prefix, as per the state of the IGP topology. 113 Adjacency segments represent a hop over a specific adjacency between 114 two nodes in the IGP. A prefix segment is typically a multi-hop path 115 while an adjacency segment, in most of the cases, is a one-hop path. 116 [RFC8402]. [nit] rfc8402 defines more than 2 IGP segments. [nit] s/one-hop path. [RFC8402]./one-hop path [RFC8402]. 118 When Segment Routing is enabled in a IGP domain, segments are 119 advertised in the form of Segment Identifiers (SIDs). The IGP link- 120 state routing protocols have been extended to advertise SIDs and 121 other SR-related information. IGP extensions are described in: IS-IS 122 [I-D.ietf-isis-segment-routing-extensions], OSPFv2 123 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 124 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Using these 125 extensions, Segment Routing can be enabled within an IGP domain. [nit] s/a IGP domain/an IGP domain 127 +------------+ 128 | Consumer | 129 +------------+ 130 ^ 131 | 132 v 133 +-------------------+ 134 | BGP Speaker | +-----------+ 135 | (Route-Reflector) | | Consumer | 136 +-------------------+ +-----------+ 137 ^ ^ ^ ^ 138 | | | | 139 +---------------+ | +-------------------+ | 140 | | | | 141 v v v v 142 +-----------+ +-----------+ +-----------+ 143 | BGP | | BGP | | BGP | 144 | Speaker | | Speaker | . . . | Speaker | 145 +-----------+ +-----------+ +-----------+ 146 ^ ^ ^ 147 | | | 148 IGP IGP IGP 150 Figure 1: Link State info collection [nit] Maybe move this Figure so it is closer to where it is referenced. ... 159 In order to address the need for applications that require 160 topological visibility across IGP areas, or even across Autonomous 161 Systems (AS), the BGP-LS address-family/sub-address-family have been 162 defined to allow BGP to carry Link-State information. The BGP 163 Network Layer Reachability Information (NLRI) encoding format for 164 BGP-LS and a new BGP Path Attribute called the BGP-LS attribute are 165 defined in [RFC7752]. The identifying key of each Link-State object, 166 namely a node, link, or prefix, is encoded in the NLRI and the 167 properties of the object are encoded in the BGP-LS attribute. 168 Figure 1 describes a typical deployment scenario. In each IGP area, 169 one or more nodes are configured with BGP-LS. These BGP speakers 170 form an IBGP mesh by connecting to one or more route-reflectors. 171 This way, all BGP speakers (specifically the route-reflectors) obtain 172 Link-State information from all IGP areas (and from other ASes from 173 EBGP peers). An external component connects to the route-reflector 174 to obtain this information (perhaps moderated by a policy regarding 175 what information is or isn't advertised to the external component). [minor] The way that the propagation of information can be controlled by policy is important. Please make sure that the text is clear in the fact that the discussion above is referencing rfc7752 (and that the reference to it is not just about the encodings). 177 This document describes extensions to BGP-LS to advertise the SR 178 information. An external component (e.g., a controller) then can 179 collect SR information from across an SR domain and construct the 180 end-to-end path (with its associated SIDs) that need to be applied to 181 an incoming packet to achieve the desired end-to-end forwarding. 182 Here the SR domain is defined as a single administrative domain that 183 may be comprised of a single AS or multiple ASes under consolidated 184 global SID administration. [nit] s/under consolidated/under a consolidated [major] Please don't redefine "SR domain". The definition above is not the same as what rfc8402 says (in =C2=A72). Easy fix: simply put a reference t= o rfc8402 next to the first mention of "SR domain", and delete that last sentence. 186 2. BGP-LS Extensions for Segment Routing 188 This document defines SR extensions to BGP-LS and specifies the TLVs 189 and sub-TLVs for advertising SR information within the BGP-LS 190 Attribute. Section 2.4 and Section 2.5 illustrates the equivalent 191 TLVs and sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols. [nit] "illustrates" sounds like giving examples of equivalent TLVs. But I think that the tables don't show examples, they show/point to the corresponding TLVs. Perhaps use a different word... ... 200 Some of the TLVs defined in this document contain fields (e.g. flags) 201 whose semantics need to be interpreted accordingly to the respective 202 underlying IS-IS, OSPFv2 or OSPFv3 protocol. The receiver of the 203 BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the 204 NLRI and refer to the underlying protocol specification in order to 205 parse such fields. The individual field descriptions in the sub- 206 sections below point to the relevant underlying protocol 207 specifications for such fields. [major] "The receiver of the BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the NLRI and refer to the underlying protocol specification in order to parse such fields." This text is a general statement ("for any of the NLRIs") that seems to want to Update rfc7752, where Protocol-ID is defined...but I don't think that is the intent, right? Note that rfc7752 doesn't explicitly mandate that the "receiver...refer to the underlying protocol specification" -- it just implies it when talking about the Opaque TLVs. IOW, this seems like a significant change as related to other BGP-LS specs. Note also that =C2=A75 (Manageability Considerations) has the following tex= t, which I think is in contradiction of the one above: ... ... The semantic or content checking for the TLVs specified in this document and their association with the BGP-LS NLRI types or their BGP-LS Attribute is left to the consumer of the BGP-LS information (e.g. an application or a controller) and not the BGP protocol. ... The handling of semantic or content errors by the consumer would be dictated by the nature of its application usage and hence is beyond the scope of this document. 209 2.1. Node Attributes TLVs 211 The following Node Attribute TLVs are defined: 213 +-----------------+----------+---------------+ 214 | Description | Length | Section | 215 +-----------------+----------+---------------+ 216 | SID/Label | variable | Section 2.1.1 | 217 | SR Capabilities | variable | Section 2.1.2 | 218 | SR Algorithm | variable | Section 2.1.3 | 219 | SR Local Block | variable | Section 2.1.4 | 220 | SRMS Preference | variable | Section 2.1.5 | 221 +-----------------+----------+---------------+ 223 Table 1: Node Attribute TLVs [minor] It would be nice if the table also contained the TLV Type. This comment applies to other similar tables. [minor] =C2=A72.1.2/2.1.3 use a "-" in the name of the TLV. Please be consistent as both versions are used throughout the document. [nit] Yes, the length is variable, but in some cases the possible values are known. For example, the length of the SID/Label sub-TLV can only be 3 or 4. Consider indicating that. OTOH, I don't see why indicating the Length is significant at this point -- IOW, I would even suggest removing that column. 225 These TLVs can ONLY be added to the BGP-LS Attribute associated with 226 the Node NLRI that originates the corresponding underlying IGP TLV/ 227 sub-TLV described below. [minor] "the Node NLRI that originates the corresponding underlying IGP..." The Node NLRI doesn't originate anything...it describes the IGP node that originates something... Please be specific. [major] The text above sounds as if you want to mandate something... Writing "ONLY" in caps doesn't have a Normative effect. Should there be a "MUST" somewhere? Or perhaps soften a little: s/can ONLY/should only The next question is: what if they are added somewhere else? There doesn't seem to be a way for the receiver to know if the TLVs are associated with the correct Node NLRI... I'm guessing that all the receiver can do is assume that the TLV is referring to the right node... >From the text, I'm assuming that the use is intended to be limited to the Node NLRI. Unfortunately, rfc7752 doesn't specify actions to be taken if that is not the case. This comment applies to other places where the "ONLY be added" phrase exists. 229 2.1.1. SID/Label Sub-TLV 231 The SID/Label TLV is used as sub-TLV by the SR-Capabilities 232 (Section 2.1.2) and SRLB (Section 2.1.4) TLVs and has the following 233 format: [nit] s/used as sub-TLV/used as a sub-TLV [minor] This is the first time that SRLB is used in this document, please use the extended version here: s/SRLB/SR Local Block (SRLB) ... 245 Type: TBD, see Section 4. [minor] The code points have already been assigned (early allocation). Please change "TBD" for the actual values. 247 Length: Variable, 3 or 4. [nit] The Length is really not variable...it's 3 or 4. ... 254 The receiving router MUST ignore the SID/Label sub-TLV if the 255 length is other then 3 or 4. [major] If the sub-TLV is ignored, the information in the SR-Capabilities or SR Local Block TLVs will be incomplete (at best). What is the potential impact of that? Is the received information still useful? Should other actions be taken? 257 2.1.2. SR-Capabilities TLV 259 The SR-Capabilities TLV is used in order to advertise the node's SR 260 Capabilities including its Segment Routing Global Base (SRGB) 261 range(s). In the case of IS-IS, the capabilities also include the 262 IPv4 and IPv6 support for SR-MPLS forwarding plane. This information 263 is derived from the protocol specific advertisements. [nit] s/support for SR-MPLS forwarding plane/support for the SR-MPLS forwarding plane 265 o IS-IS, as defined by the SR-Capabilities sub-TLV in 266 [I-D.ietf-isis-segment-routing-extensions]. 268 o OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in 269 [I-D.ietf-ospf-segment-routing-extensions] and 270 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [minor] The text above, pointing at the individual IGP specs is present in many of the descriptions for the TLVs, but not all. Sections 2.4/2.5 have tables that also point at the equivalent TLVs. I'm looking for consistency: either indicate in each section where the information is derived from, or not. Given that =C2=A72.4/2.5 already have a summary, I personally find the information (like the one above) in the individual sections redundant. Instead of the statement above, I prefer you to be specific about the values described below -- for example, when describing the Range Size field below, you could say something like this: OLD> Range Size: 3 octet value indicating the number of labels in the range. NEW> Range Size: 3 octet value indicating the number of labels in the range. The value and characteristics of this field are derived from the Range field in the SR-Capabilities sub-TLV in [I-D.ietf-isis-segment-routing-extensions], or from the Range Size field in the SID/Label Range TLV in [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Note that doing it this way saves you the need to define the characteristics of each field (because even if the values are derived, the TLVs here are new). This comment obviously applies to all similar instances in the document. 272 The SR Capabilities TLV has following format: [nit] s/has following format/has the following format ... 290 Length: Variable. [major] Yes, it's variable, but it has to be at least 12. What should a router do if the length is < 12? After that, there are only specific valid lengths: 12, 13, 19, 21, etc. What if the length is not one of those values? I couldn't find guidance in rfc7752. The closest statement is from =C2=A76= .2.2 (Fault Management), where one of the "checks for determining if a message is malformed...Does any fixed-length TLV correspond to the TLV Length field in this document?" This TLV is not fixed-length, but the possibilities are finite. Note that rfc7752 says that if the length is not the expected one, then the whole BGP-LS attribute is discarded. For this specific case, it means that the controller wouldn't have complete knowledge of the network, even if the information derived from the IGP is correct... This comment applies to other similar instances. 292 Flags: 1 octet of flags as defined in 293 [I-D.ietf-isis-segment-routing-extensions]. [major] When the BGP-LS information comes from OSPF, how should the flags be interpreted? There is no indication in the corresponding OSPF drafts of "IPv4 and IPv6 support for SR-MPLS" -- should the bits always be unset? ... 300 Range Size: 3 octet value indicating the number of labels in 301 the range. [nit] s/labels/labels or SIDs [major] What numbers are valid in the Range Size field? Can it be 0? Take a look above at my comments about derived values. 303 SID/Label sub-TLV (as defined in Section 2.1.1) which encodes 304 the first label in the range. [nit] s/first label/first label or SID ... 339 2.1.4. SR Local Block TLV ... 380 Flags: 1 octet of flags. None are defined at this stage. [major] Only the corresponding ISIS sub-TLV has Flags defined -- and I realize that the text above is the same as in draft-ietf-isis-segment-routing-extensions. I think you really don't want this field to evolve independently. IOW, please use a description like the you used for the Flags in the SR-Capabilities TLV. ... 393 2.1.5. SRMS Preference TLV ... 427 The use of the SRMS Preference TLV is defined in 428 [I-D.ietf-isis-segment-routing-extensions], 429 [I-D.ietf-ospf-segment-routing-extensions] and 430 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [major] This document only defines how to carry information in BGP-LS, not what to do with it. IOW, I think that the last paragraph is not needed, it is out of scope of this document... 432 2.2. Link Attribute TLVs 434 The following Link Attribute TLVs are are defined: 436 +----------------------------------------+----------+---------------+ 437 | Description | Length | Section | 438 +----------------------------------------+----------+---------------+ 439 | Adjacency Segment Identifier (Adj-SID) | variable | Section 2.2.1 | 440 | TLV | | | 441 | LAN Adjacency Segment Identifier (Adj- | variable | Section 2.2.2 | 442 | SID) TLV | | | 443 | L2 Bundle Member TLV | variable | Section 2.2.3 | 444 +----------------------------------------+----------+---------------+ 446 Table 2: Link Attribute TLVs [minor] The names used above don't match the names used in the sections below. ... 452 For a LAN, normally a node only announces its adjacency to the IS-IS 453 pseudo-node (or the equivalent OSPF Designated and Backup Designated 454 Routers)[I-D.ietf-isis-segment-routing-extensions]. The LAN 455 Adjacency Segment TLV allows a node to announce adjacencies to all 456 other nodes attached to the LAN in a single instance of the BGP-LS 457 Link NLRI. Without this TLV, the corresponding BGP-LS link NLRI 458 would need to be originated for each additional adjacency in order to 459 advertise the SR TLVs for these neighbor adjacencies. [minor] This paragraph maybe fits better in =C2=A72.2.2. 461 2.2.1. Adjacency SID TLV ... 482 Flags. 1 octet field of following flags as defined in 483 [I-D.ietf-isis-segment-routing-extensions], 484 [I-D.ietf-ospf-segment-routing-extensions] and 485 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. NEW> Flags: 1 octet field. The value corresponds to the Flags specified for the Adj-SID Sub-TLV in [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] or [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 487 Weight: Weight used for load-balancing purposes. [minor] Similar to the above text... 489 Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on 490 receipt. 492 SID/Index/Label: Label or index value depending on the flags 493 setting as defined in [I-D.ietf-isis-segment-routing-extensions], 494 [I-D.ietf-ospf-segment-routing-extensions] and 495 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [minor] Similar text here too... 497 2.2.2. LAN Adjacency SID TLV ... [major] The OSPF Neighbor ID / IS-IS System-ID field is not defined. 542 2.2.3. L2 Bundle Member [nit] s/L2 Bundle Member/L2 Bundle Member Attribute TLV 544 The L2 Bundle Member Attribute TLV identifies an L2 Bundle Member 545 link which in turn is associated with a parent L3 link. The L3 link 546 is described by the Link NLRI defined in [RFC7752] and the L2 Bundle 547 Member Attribute TLV is associated with the Link NLRI. The TLV MAY 548 include sub-TLVs which describe attributes associated with the bundle 549 member. The identified bundle member represents a unidirectional 550 path from the originating router to the neighbor specified in the 551 parent L3 Link. Multiple L2 Bundle Member Attribute TLVs MAY be 552 associated with a Link NLRI. [minor] "identifies an L2 Bundle Member link...The identified bundle member". Are we talking about a link or just the members? ... 574 L2 Bundle Member Descriptor: A Link Local Identifier as defined in 575 [RFC4202]. [major] From the text, it looks like this information is not something that is learned from the IGP, which is then just transported by BGP-LS (just like the rest of the TLVs in this document), but table 5 points at draft-ietf-isis-l2bundles. Why is draft-ietf-isis-l2bundles not used to describe this TLV? [major] rfc4202 is not IS-IS-specific. What about OSPF? I note that rfc4203 defines OSPF extensions that include the Link Local Identifier, so this concept is not foreign to it. 577 Link attributes for L2 Bundle Member Links are advertised as sub-TLVs 578 of the L2Bundle Member Attribute TLV. The sub-TLVs are identical to 579 existing BGP-LS TLVs as identified in the table below. [nit] s/L2Bundle/L2 Bundle ... 633 2.3.1. Prefix-SID TLV ... [major] draft-ietf-ospf-segment-routing-extensions also includes the MT-ID in the Prefix SID Sub-TLV. Is that not needed by a controller? 691 2.3.2. Prefix Attribute Flags TLV ... 711 Length: variable. [minor] The length of the flags fields in rfc7794/rfc7684 are both one octet long. Can this length be made fixed? [major] I could not find a Flags field for OSPFv3 in rfc5340. [minor] From Table 7, it seems that the reference to rfc8362 points to the "Prefix Options Field", is that correct? 713 Flags: a variable length flag field (according to the length 714 field). Flags are routing protocol specific and are to be parsed 715 as below: 717 * IS-IS flags are defined in [RFC7794] 719 * OSPFv2 flags are defined in [RFC7684] 721 * OSPFv3 flags map to the Prefix Options field defined in 722 [RFC7794] and extended via [RFC8362] [nit] The text at the top of this section refers to rfc5340... [major] rfc7794 only talks about IS-IS, not OSPFv3. 724 2.3.3. Source Router Identifier (Source Router-ID) TLV 726 The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the 727 originator of the Prefix. For IS-IS protocol this is as defined in 728 [RFC7794]. The Source Router-ID TLV may be used to carry the OSPF 729 Router-ID of the prefix originator. [major] Reference for OSPF? Only "may"?? [major] rfc7752 defines the IGP Router-ID TLV to carry the same information. What is the relationship between these two TLVs? Since the IGP Router-ID TLV is mandatory, are there cases where this one may not be needed? ... 745 Length: 4 or 16. [major] OSPF always uses a 32-bit number. IOW, the length is fixed for OSPF. ... 749 2.3.4. Range TLV 751 The range TLV is used in order to advertise a range of prefix-to-SID 752 mappings as part of the Segment Routing Mapping Server functionality 753 [I-D.ietf-spring-segment-routing-ldp-interop], as defined in the 754 respective underlying IGP SR extensions 755 [I-D.ietf-ospf-segment-routing-extensions], 756 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] and 757 [I-D.ietf-isis-segment-routing-extensions]. The Prefix-NLRI to which 758 the Range TLV is attached MUST be advertised as a non-routing prefix 759 where no IGP metric TLV (TLV 1095) is attached. [major] What do you mean in the final sentence? It sounds as if the IGP metric TLV and the Range TLV are mutually exclusive and should never be advertised together. Is that it? If so, what should the receiver do if they are? 761 The format of the Range TLV is as follows: 763 0 1 2 3 764 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type | Length | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Flags | Reserved | Range Size | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 // sub-TLVs // 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 where: [nit] That "where" should be after the Figure title. 775 Figure 2: Range TLV format ... [minor] As will all the other sections, please be consistent and fold the sub-sections below into the description above. 804 2.3.4.1. Advertisement Procedure for OSPF 806 The OSPFv2/OSPFv3 Extended Prefix Range TLV is encoded in the Range 807 TLV. The flags of the Range TLV have the semantic mapped to the 808 definition in [I-D.ietf-ospf-segment-routing-extensions] section 4 or 809 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] section 4. 811 Then the prefix-to-SID mapping from the OSPF Prefix SID sub-TLV is 812 encoded using the BGP-LS Prefix-SID TLV as defined in Section 2.3.1 813 with the flags set according to the definition in 814 [I-D.ietf-ospf-segment-routing-extensions] section 5 or 815 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] section 5. [major] The Extended Prefix Range TLV contains other fields not present here: AF, for instance. The last paragraph seems to indicate that the prefix information will be in the BGP-LS Prefix-SID TLV, but that information doesn't come from the Extended Prefix Range TLV (and it doesn't include the AF). What am I missing? [major] The text above seems to imply that the Range TLV and the Prefix-SID TLV should always be included together. Is that true? If so, please make it more explicit. 817 2.3.4.2. Advertisement Procedure for IS-IS 819 The IS-IS SID/Label Binding TLV, when used to signal mapping server 820 label bindings, is encoded in the Range TLV. The flags of the Range 821 TLV have the sematic mapped to the definition in 822 [I-D.ietf-isis-segment-routing-extensions] section 2.4.1. 824 Then the prefix-to-SID mappings from the IS-IS Prefix SID sub-TLV is 825 encoded using the BGP-LS Prefix-SID TLV as defined in Section 2.3.1 826 with the flags set according to the definition in 827 [I-D.ietf-isis-segment-routing-extensions] section 2.4.4.1. [major] Same questions (as above) related to the other fields in the SID/Label Binding TLV, and the relationship between the Range TLV and the Prefix-SID TLV. 829 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs ... 837 +---------------------------------------+----------+----------------+ 838 | Description | Length | IS-IS TLV/sub- | 839 | | | TLV | 840 +---------------------------------------+----------+----------------+ 841 | SR Capabilities | variable | 2 [1] | 842 | SR Algorithm | variable | 19 [2] | 843 | SR Local Block | variable | 22 [3] | 844 | SRMS Preference | 1 | 19 [4] | 845 | Adjacency Segment Identifier (Adj- | variable | 31 [5] | 846 | SID) | | | 847 | LAN Adjacency Segment Identifier | variable | 32 [6] | 848 | (LAN-Adj-SID) | | | 849 | Prefix SID | variable | 3 [7] | 850 | Range | variable | 149 [8] | 851 | SID/Label TLV | variable | 1 [9] | 852 | Prefix Attribute Flags | variable | 4 [10] | 853 | Source Router ID | variable | 11/12 [11] | 854 | L2 Bundle Member TLV | variable | 25 [12] | 855 +---------------------------------------+----------+----------------+ [major] Instead of using URIs, please put an explicit pointer to the RFC/ID (and if desired, the section)...and make sure that there are corresponding References. If a document is referenced only in this table, then the Reference can be Informative. [nit] For Tables 5-7: No need to use "TLV" in the description. 857 Table 5: IS-IS Segment Routing Extensions TLVs/Sub-TLVs 859 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs ... 886 Table 6: OSPF Segment Routing Extensions TLVs/Sub-TLVs [nit] s/OSPF/OSPFv2 [minor] The OSPF tables don't include the Source Router ID or the L2 Bundle Member TLVs. Is there a reason for that, or just an oversight? ... 908 3. Implementation Status [nit] This section says nothing. :-( At least a pointer to https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-e= xt-implementations might be nice. OR, you can just remove it. ... 943 4. IANA Considerations 945 This document requests assigning code-points from the registry "BGP- 946 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 947 TLVs" based on table Table 8. The column "IS-IS TLV/Sub-TLV" defined 948 in the registry does not require any value and should be left empty. [major] The early allocation has already been done...so this document doesn't request assignment from IANA. Please update. ... 977 5. Manageability Considerations 979 This section is structured as recommended in [RFC5706]. 981 The new protocol extensions introduced in this document augment the 982 existing IGP topology information that was distributed via [RFC7752]. 983 Procedures and protocol extensions defined in this document do not 984 affect the BGP protocol operations and management other than as 985 discussed in the Manageability Considerations section of [RFC7752]. 986 Specifically, the malformed attribute tests for syntactic checks in 987 the Fault Management section of [RFC7752] now encompass the new BGP- 988 LS Attribute TLVs defined in this document. The semantic or content 989 checking for the TLVs specified in this document and their 990 association with the BGP-LS NLRI types or their BGP-LS Attribute is 991 left to the consumer of the BGP-LS information (e.g. an application 992 or a controller) and not the BGP protocol. [nit] s/that was distributed/that is distributed 994 A consumer of the BGP-LS information is retrieving this information 995 from a BGP protocol component that is doing the signaling over a BGP- 996 LS session, via some APIs or a data model (refer Section 1 and 2 of 997 [RFC7752]). The handling of semantic or content errors by the 998 consumer would be dictated by the nature of its application usage and 999 hence is beyond the scope of this document. This document only 1000 introduces new Attribute TLVs and an error in them would result in 1001 only that specific attribute being discarded with an error log. [nit] s/is retrieving this/retrieves this [minor] "...retrieving this information...over a BGP-LS session, via some APIs or a data model (refer Section 1 and 2 of [RFC7752])." I think that even mentioning that an API or data model can be used instead of BGP-LS is a stretch -- that is not how I interpret the initial sections in rfc7752 (which are just background sections), and there are no formal API/data model definition. [major] "...new Attribute TLVs and an error in them would result in only that specific attribute being discarded with an error log." According to rfc7752, this statement is true only for syntactic errors, not semantic ones. Semantic errors ("left to the consumer", as mentioned above) means that the BGP-LS session can be used to transport trash (trash-in-trash-out). Jeff Haas brought this up during the WGLC [4]. I agree (with the Chairs' conclusion) that this issue is bigger than this document -- but (because we don't have a current solution) I would like to see it mentioned somewhere as a potential issue (maybe in the Management or Security Considerations sections, your choice). [4] https://mailarchive.ietf.org/arch/msg/idr/Yfp6WyqnRtMAOeZvSvK7rYCUkHg [major] rfc7752 does mandate the use of "attribute discard" (rfc7606). I would really like to see a discussion (or at least a mention) around the fact that discarding an attribute may result in the receiver not having complete information. In the case of SR, this implies that the controller may not have complete information to calculate the paths. I think this is an issue bigger than this document, so I am not asking you to solve it...I'm just asking for the document to acknowledge that it exists and to mention what the potential impact may be. 1003 The extensions, specified in this document, do not introduce any new 1004 configuration or monitoring aspects in BGP or BGP-LS other than as 1005 discussed in [RFC7752]. The manageability aspects of the underlying 1006 SR features are covered by [I-D.ietf-spring-sr-yang], 1007 [I-D.ietf-isis-sr-yang] and [I-D.ietf-ospf-sr-yang]. [minor] While the Yang models have to do with management, there are no "manageability aspects of the underlying SR features" included there. [major] Following the recommendations from rfc5706, a Fault Management section would be appropriate to include considerations related to the use of BGP-LS as a transport for SR information (given this is the first draft to propose it), and the possible errors mentioned here... Again, not looking for solutions, just acknowledgement. 1009 6. Security Considerations 1011 The new protocol extensions introduced in this document augment the 1012 existing IGP topology information that was distributed via [RFC7752]= . 1013 The Security Considerations section of [RFC7752] also applies to 1014 these extensions. The procedures and new TLVs defined in this 1015 document, by themselves, do not affect the BGP-LS security model 1016 discussed in [RFC7752]. [nit] s/that was distributed/that is distributed 1018 BGP-LS SR extensions enable traffic engineering use-cases within the 1019 Segment Routing domain. SR operates within a trusted domain (refer 1020 Security Considerations section in [RFC8402] for more detail) and it= s 1021 security considerations also apply to BGP-LS sessions when carrying 1022 SR information.The SR traffic engineering policies using the SIDs 1023 advertised via BGP-LS are expected to be used entirely within this 1024 trusted SR domain (e.g. between multiple AS/domains within a single 1025 provider network). Therefore, precaution is necessary to ensure tha= t 1026 the SR information collected via BGP-LS is limited to specific 1027 controllers or applications in a secure manner within this SR domain= . [nit] s/trusted domain (refer Security Considerations section in [RFC8402] for more detail)/trusted domain [RFC8402] [nit] s/SR information.The SR traffic/SR information. The SR traffic [major] "SR operates within a trusted domain...[RFC8402]...and its security considerations also apply to BGP-LS sessions when carrying SR information." The Security Considerations in rfc8404 really only talk about the data plane -- I don't see how they apply to the BGP-LS sessions. [major] "...precaution is necessary to ensure that the SR information collected via BGP-LS is limited to specific controllers or applications..." This sounds as if you're referring to information that (once collected) can be shared between controllers -- I think that case is out of scope. If you are trying to talk about the BGP sessions, then I think the language needs a little more work. BTW, the paragraph below also talks about BGP sessions; suggestion: keep the common topics together. [major] The end of the last sentence says "...in a secure manner within this SR domain". Assuming that we're talking about BGP sessions, what does that mean? Does it mean anything beyond what BGP is normally specified to do? If not, then I would recommend taking that piece of text out to not invite more questions than needed. [minor] You talk about "controllers or applications", but in the rest of the document you have mostly used "consumer" (which is a good thing because it shows consistency with rfc8402). Suggestion: use "consumers" here as well. 1029 The isolation of BGP-LS peering sessions is also required to ensure 1030 that BGP-LS topology information (including the newly added SR 1031 information) is not advertised to an external BGP peering session 1032 outside an administrative domain. [major] What does "isolation of BGP-LS peering sessions" mean? Why is it not Normatively REQUIRED? [major] From prior experience (see draft-ietf-idr-te-pm-bgp), the SecDir/Sec ADs asked for text related to why it is ok to transport the new information in BGP. This is the text that resulted from that discussion: The TLVs introduced in this document are used to propagate IGP defined information ([I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471].) These TLVs represent the state and resource availability of the IGP link. The IGP instances originating these TLVs are assumed to support all the required security and authentication mechanisms (as described in [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471]) in order to prevent any security issue when propagating the TLVs into BGP-LS. The advertisement of the link attribute information defined in this document presents no additional risk beyond that associated with the existing set of link attribute information already supported in [RFC7752]. Note that this text is complementary to what is already stated in the first paragraph -- but goes into a more explicit explanation and brings in the security considerations from the documents where the IGP extensions are defined. Consider adding something similar here. ... 1126 9.2. Informative References ... 1159 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1160 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1161 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1162 July 2018, . [major] I think this should be a Normative reference. 1164 9.3. URIs [major] As mentioned before, please use References (above) instead of URIs. ... 1197 [12] http://tools.ietf.org/html/draft-ietf-isis-l2bundles-07 [major] The reference should become Normative (see =C2=A72.2.3). --0000000000008698d60581b8a910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Dear authors:

I just finished my review of this document -- pl= ease see inline comments/questions.

In general, I think that there is more work nee= ded in at least two fronts:

(1) Consistency in the specification of the new TLVs.= =C2=A0 Most of the descriptions point at other documents, but they don'= t do so in a consistent manner: some at the start of the section, others wh= en pointing at the values, etc.=C2=A0 Please be consistent!=C2=A0 Given tha= t =C2=A72.4/2.5 already have a summary, I personally find the information i= n the individual sections redundant.=C2=A0 Instead of a statement at the st= art of a section, I prefer you to be specific about the values -- see =C2= =A72.1.2 for an example.

Please note that most of my comments related to the specif= ication of the TLVs apply to multiple sections, not just the one where I ma= de them.=C2=A0 I pointed this out in most cases, but may have missed some.<= /div>


(2) Error Handling.=C2=A0 As has been discussed= on the list (for example in [1], [2] and [3]), rfc7752 could use enhanceme= nts as it relates to considering error handling with applications such as S= R, and in general.=C2=A0 Those issues don't need to be fixed in this do= cument, but I would like to see in this document some text about the potent= ial effect: maybe in terms of the effect than an error might have from an o= perations or management point of view... See my comments below for specific= s.=C2=A0 Again, not looking for this document to "fix" BGP-LS, bu= t to consider the effect on the expected function a controller might have, = as described in the Introduction.

=
<= br>

Than= ks!

Alva= ro.


=
[Line numbers come from idnits.]

...
27 Requirements Language

29 =C2=A0 The key words "MUST", "MUST NOT"= , "REQUIRED", "SHALL", "SHALL NOT",
30 =C2=A0 "SHOULD", "SHOULD NOT", "REC= OMMENDED", "MAY", and "OPTIONAL" in this
31 =C2=A0 document are to be interpreted as described in RFC 21= 19 [RFC2119].

[major] Please use the rfc8174 template.


= ...
99 1.=C2=A0 Introduction
...
110 =C2=A0 Two types of IGP segments are de= fined, Prefix segments and Adjacency
111 =C2=A0 segmen= ts.=C2=A0 Prefix segments, by default, represent an ECMP-aware
112 =C2=A0 shortest-path to a prefix, as per the state of the IGP = topology.
113 =C2=A0 Adjacency segments represent a ho= p over a specific adjacency between
114 =C2=A0 two nod= es in the IGP.=C2=A0 A prefix segment is typically a multi-hop path
115 =C2=A0 while an adjacency segment, in most of the cases, = is a one-hop path.
116 =C2=A0 [RFC8402].

[nit] rfc8402 defines= more than 2 IGP segments.

[nit] s/one-hop path. [RFC8402]./one-hop path [RFC8402].=

118 =C2=A0 When S= egment Routing is enabled in a IGP domain, segments are
119 =C2=A0 advertised in the form of Segment Identifiers (SIDs).=C2=A0 Th= e IGP link-
120 =C2=A0 state routing protocols have be= en extended to advertise SIDs and
121 =C2=A0 other SR-= related information.=C2=A0 IGP extensions are described in: IS-IS
122 =C2=A0 [I-D.ietf-isis-segment-routing-extensions], OSPFv2
123 =C2=A0 [I-D.ietf-ospf-segment-routing-extensions] a= nd OSPFv3
124 =C2=A0 [I-D.ietf-ospf-ospfv3-segment-rou= ting-extensions].=C2=A0 Using these
125 =C2=A0 extensi= ons, Segment Routing can be enabled within an IGP domain.

[nit] s/a IGP domain/an= IGP domain

127 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +------------+
128 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0Consumer =C2=A0|
129 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-------= -----+
130 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^
131 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
132 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
133 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +-------------------+
134 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0BGP Spe= aker =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------+
135 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | (Route-Reflector) | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Consumer = =C2=A0|
136 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-------------------+ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +-----------+
137 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^= =C2=A0 ^ =C2=A0 ^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 ^
138 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 | =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
139 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +---------------+ =C2=A0 | =C2=A0 +-------------------+ =C2= =A0 |
140 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0= |
141 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0= v
142 =C2=A0 =C2=A0 =C2=A0 +-----------+ =C2=A0 =C2= =A0 =C2=A0 +-----------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-------= ----+
143 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0BGP =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0BGP =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0BGP =C2=A0 =C2=A0|
<= div style=3D"margin:0px">144 =C2=A0 =C2=A0 =C2=A0 | =C2=A0Speaker =C2=A0| =C2=A0 =C2= =A0 =C2=A0 | =C2=A0Speaker =C2=A0| =C2=A0 =C2=A0. . . =C2=A0 =C2=A0| =C2=A0= Speaker =C2=A0|
145 =C2=A0 =C2=A0 =C2=A0 +-----------+= =C2=A0 =C2=A0 =C2=A0 +-----------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +-----------+
146 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= ^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ^
147 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
148 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0IGP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IGP =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I= GP

150 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 1: Link State i= nfo collection

[nit] Maybe move this Figure so it is closer to where it is referenc= ed.

...<= /div>
159 =C2=A0 In order to address the need for applicatio= ns that require
160 =C2=A0 topological visibility acro= ss IGP areas, or even across Autonomous
161<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 Sys= tems (AS), the BGP-LS address-family/sub-address-family have been
162 =C2=A0 defined to allow BGP to carry Link-State information= .=C2=A0 The BGP
163 =C2=A0 Network Layer Reachability = Information (NLRI) encoding format for
164 =C2=A0 BGP-= LS and a new BGP Path Attribute called the BGP-LS attribute are
165 =C2=A0 defined in [RFC7752].=C2=A0 The identifying key of eac= h Link-State object,
166 =C2=A0 namely a node, link, o= r prefix, is encoded in the NLRI and the
167= =C2=A0 pr= operties of the object are encoded in the BGP-LS attribute.
168 =C2=A0 Figure 1 describes a typical deployment scenario.=C2=A0 In= each IGP area,
169 =C2=A0 one or more nodes are confi= gured with BGP-LS.=C2=A0 These BGP speakers
= 170 =C2=A0= form an IBGP mesh by connecting to one or more route-reflectors.
171 =C2=A0 This way, all BGP speakers (specifically the route-r= eflectors) obtain
172 =C2=A0 Link-State information fr= om all IGP areas (and from other ASes from
1= 73 =C2=A0 = EBGP peers).=C2=A0 An external component connects to the route-reflector
174 =C2=A0 to obtain this information (perhaps moderated= by a policy regarding
175 =C2=A0 what information is = or isn't advertised to the external component).

[minor] The way that the propag= ation of information can be controlled by policy is important.=C2=A0 Please= make sure that the text is clear in the fact that the discussion above is = referencing rfc7752 (and that the reference to it is not just about the enc= odings).

177 =C2= =A0 This document describes extensions to BGP-LS to advertise the SR
<= div style=3D"margin:0px">178 =C2=A0 information.=C2=A0 An external component (e.g., a= controller) then can
179 =C2=A0 collect SR informatio= n from across an SR domain and construct the
180 =C2= =A0 end-to-end path (with its associated SIDs) that need to be applied to
181 =C2=A0 an incoming packet to achieve the desired en= d-to-end forwarding.
182 =C2=A0 Here the SR domain is = defined as a single administrative domain that
183 =C2= =A0 may be comprised of a single AS or multiple ASes under consolidated
184 =C2=A0 global SID administration.

[nit] s/under consolidated/= under a consolidated

[major] Please don't redefine "SR domain".=C2=A0= The definition above is not the same as what rfc8402 says (in =C2=A72).=C2= =A0 Easy fix: simply put a reference to rfc8402 next to the first mention o= f "SR domain", and delete that last sentence.

186 2.=C2=A0 BGP-LS Extensions for Seg= ment Routing

188 = =C2=A0 This document defines SR extensions to BGP-LS and specifies the TLVs=
189 =C2=A0 and sub-TLVs for advertising SR informatio= n within the BGP-LS
190 =C2=A0 Attribute.=C2=A0 Sectio= n 2.4 and Section 2.5 illustrates the equivalent
191 = =C2=A0 TLVs and sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols.

[nit] "illustr= ates" sounds like giving examples of equivalent TLVs.=C2=A0 But I thin= k that the tables don't show examples, they show/point to the correspon= ding TLVs.=C2=A0 Perhaps use a different word...


...
200 =C2=A0 Some of the TLVs defined in this docu= ment contain fields (e.g. flags)
201 =C2=A0 whose sema= ntics need to be interpreted accordingly to the respective
202 =C2=A0 underlying IS-IS, OSPFv2 or OSPFv3 protocol.=C2=A0 The rec= eiver of the
203 =C2=A0 BGP-LS update for any of the N= LRIs MUST check the Protocol-ID of the
204 =C2=A0 NLRI= and refer to the underlying protocol specification in order to
205 =C2=A0 parse such fields.=C2=A0 The individual field descript= ions in the sub-
206 =C2=A0 sections below point to th= e relevant underlying protocol
207 =C2=A0 specificatio= ns for such fields.

[major] "The receiver of the BGP-LS update for any of the = NLRIs MUST check the Protocol-ID of the NLRI and refer to the underlying pr= otocol specification in order to parse such fields." =C2=A0This text i= s a general statement ("for any of the NLRIs") that seems to want= to Update rfc7752, where Protocol-ID is defined...but I don't think th= at is the intent, right?=C2=A0 Note that rfc7752 doesn't explicitly man= date that the "receiver...refer to the underlying protocol specificati= on" -- it just implies it when talking about the Opaque TLVs.

IOW, this seems = like a significant change as related to other BGP-LS specs.

Note also that =C2=A75 = (Manageability Considerations) has the following text, which I think is in = contradiction of the one above:

...
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0... = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The semantic or cont= ent
=C2=A0 =C2=A0checking for the TLVs speci= fied in this document and their
=C2=A0 =C2= =A0association with the BGP-LS NLRI types or their BGP-LS Attribute is
=C2=A0 =C2=A0left to the consumer of the BGP-LS = information (e.g. an application
=C2=A0 =C2= =A0or a controller) and not the BGP protocol.

=C2=A0 =C2=A0... =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 The handling of semantic or content errors by = the
=C2=A0 =C2=A0consumer would be dictated = by the nature of its application usage and
= =C2=A0 =C2=A0hence is beyond the scope of this document.

209 2.1.=C2=A0 Node Attributes TLVs

211 =C2=A0 The foll= owing Node Attribute TLVs are defined:

<= /div>
213 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-= ----------------+----------+---------------+
214 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Description =C2=A0 =C2=A0 | = Length =C2=A0 | =C2=A0 =C2=A0 =C2=A0 Section |
215 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----------------+----------+= ---------------+
216 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| SID/Label =C2=A0 =C2=A0 =C2=A0 | variable | Section 2.1.= 1 |
217 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| SR Capabilities | variable | Section 2.1.2 |
218 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SR Algorithm =C2=A0 =C2= =A0| variable | Section 2.1.3 |
219 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SR Local Block =C2=A0| variable | Section = 2.1.4 |
220 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| SRMS Preference | variable | Section 2.1.5 |
221 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----------------+-----= -----+---------------+

223 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Table 1: Node Attribute TLVs
<= br>
[minor] It would be nice if the table al= so contained the TLV Type.=C2=A0 This comment applies to other similar tabl= es.

[min= or] =C2=A72.1.2/2.1.3 use a "-" in the name of the TLV.=C2=A0 Ple= ase be consistent as both versions are used throughout the document.
<= div style=3D"margin:0px">
[nit] Yes, the= length is variable, but in some cases the possible values are known.=C2=A0= For example, the length of the SID/Label sub-TLV can only be 3 or 4.=C2=A0= Consider indicating that.=C2=A0 OTOH, I don't see why indicating the L= ength is significant at this point -- IOW, I would even suggest removing th= at column.

225 =C2= =A0 These TLVs can ONLY be added to the BGP-LS Attribute associated with
226 =C2=A0 the Node NLRI that originates the correspondi= ng underlying IGP TLV/
227 =C2=A0 sub-TLV described be= low.

[mi= nor] "the Node NLRI that originates the corresponding underlying IGP..= ." =C2=A0The Node NLRI doesn't originate anything...it describes t= he IGP node that originates something...=C2=A0 Please be specific.

[major] The text= above sounds as if you want to mandate something...=C2=A0 Writing "ON= LY" in caps doesn't have a Normative effect.=C2=A0 Should there be= a "MUST" somewhere?=C2=A0 Or perhaps soften a little: s/can ONLY= /should only

The next question is: what if they are added somewhere else?=C2=A0 The= re doesn't seem to be a way for the receiver to know if the TLVs are as= sociated with the correct Node NLRI...=C2=A0 I'm guessing that all the = receiver can do is assume that the TLV is referring to the right node...

From the t= ext, I'm assuming that the use is intended to be limited to the Node NL= RI.=C2=A0 Unfortunately, rfc7752 doesn't specify actions to be taken if= that is not the case.

This comment applies to other places where the "ONLY b= e added" phrase exists.


229 2.1.1.=C2=A0 SID/Label Su= b-TLV

23= 1 =C2=A0 T= he SID/Label TLV is used as sub-TLV by the SR-Capabilities
232 =C2=A0 (Section 2.1.2) and SRLB (Section 2.1.4) TLVs and has the = following
233 =C2=A0 format:

[nit] s/used as sub-TLV/used as a= sub-TLV

[minor] This is the first time that SRLB is used in this document, please = use the extended version here: =C2=A0s/SRLB/SR Local Block (SRLB)

...
245 =C2=A0 =C2=A0 =C2=A0Type: TBD, see Section 4.

[minor] The code points= have already been assigned (early allocation).=C2=A0 Please change "T= BD" for the actual values.

247 =C2=A0 =C2=A0 =C2=A0Length: Variable, 3 or 4.

[nit] The Length is= really not variable...it's 3 or 4.

=
...
254 =C2=A0 =C2=A0 = =C2=A0The receiving router MUST ignore the SID/Label sub-TLV if the
255 =C2=A0 =C2=A0 =C2=A0length is other then 3 or 4.

[major] If the s= ub-TLV is ignored, the information in the SR-Capabilities or SR Local Block= TLVs will be incomplete (at best).=C2=A0 What is the potential impact of t= hat?=C2=A0 Is the received information still useful?=C2=A0 Should other act= ions be taken?

257 = 2.1.2.=C2=A0 SR-Capabilities TLV

<= div style=3D"margin:0px">259 =C2=A0 The SR-Capabilities TLV is used in order to adver= tise the node's SR
260 =C2=A0 Capabilities includi= ng its Segment Routing Global Base (SRGB)
26= 1 =C2=A0 r= ange(s).=C2=A0 In the case of IS-IS, the capabilities also include the
262 =C2=A0 IPv4 and IPv6 support for SR-MPLS forwarding pl= ane.=C2=A0 This information
263 =C2=A0 is derived fr= om the protocol specific advertisements.
[nit] s/support for SR-MPLS forwarding pla= ne/support for the SR-MPLS forwarding plane
=
265 =C2=A0 o =C2=A0IS-IS, as defined by the SR-Ca= pabilities sub-TLV in
266 =C2=A0 =C2=A0 =C2=A0[I-D.iet= f-isis-segment-routing-extensions].

268 =C2=A0 o =C2=A0OSPFv2/OSPFv3, as defined by the SID/L= abel Range TLV in
269 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-os= pf-segment-routing-extensions] and
270 =C2=A0 =C2=A0 = =C2=A0[I-D.ietf-ospf-ospfv3-segment-routing-extensions].

[minor] The text above, po= inting at the individual IGP specs is present in many of the descriptions f= or the TLVs, but not all.=C2=A0 Sections 2.4/2.5 have tables that also poin= t at the equivalent TLVs.=C2=A0 I'm looking for consistency: either ind= icate in each section where the information is derived from, or not.=C2=A0 = Given that =C2=A72.4/2.5 already have a summary, I personally find the info= rmation (like the one above) in the individual sections redundant.=C2=A0 In= stead of the statement above, I prefer you to be specific about the values = described below -- for example, when describing the Range Size field below,= you could say something like this:

OLD>
=C2=A0 = =C2=A0Range Size: 3 octet value indicating the number of labels in
=C2=A0 =C2=A0the range.

NEW>
=C2=A0 =C2=A0Range Size: 3 octet value indicating the number of labels i= n
=C2=A0 =C2=A0the range.=C2=A0 The value an= d characteristics of this field are derived from the Range field in the SR-= Capabilities sub-TLV in [I-D.ietf-isis-segment-routing-extensions], or from= the Range Size field in the SID/Label Range TLV in [I-D.ietf-ospf-segment-= routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions].<= /div>

Note tha= t doing it this way saves you the need to define the characteristics of eac= h field (because even if the values are derived, the TLVs here are new).

This comme= nt obviously applies to all similar instances in the document.

272 =C2=A0 The SR Capabilities= TLV has following format:

[nit] s/has following format/has the following format


=
...
290 =C2=A0 =C2=A0 =C2=A0= Length: Variable.

[major] Yes, it's variable, but it has to be at least 12.=C2= =A0 What should a router do if the length is < 12?=C2=A0 After that, the= re are only specific valid lengths: 12, 13, 19, 21, etc.=C2=A0 What if the = length is not one of those values?

I couldn't find guidance in rfc7752.=C2=A0 T= he closest statement is from =C2=A76.2.2 (Fault Management), where one of t= he "checks for determining if a message is malformed...Does any fixed-= length TLV correspond to the TLV Length field in this document?" =C2= =A0This TLV is not fixed-length, but the possibilities are finite.

Note that rfc775= 2 says that if the length is not the expected one, then the whole BGP-LS at= tribute is discarded.=C2=A0 For this specific case, it means that the contr= oller wouldn't have complete knowledge of the network, even if the info= rmation derived from the IGP is correct...
<= br>
This comment applies to other similar in= stances.

292 =C2= =A0 =C2=A0 =C2=A0Flags: 1 octet of flags as defined in
293 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-isis-segment-routing-extensions].
<= div style=3D"margin:0px">
[major] When t= he BGP-LS information comes from OSPF, how should the flags be interpreted?= =C2=A0 There is no indication in the corresponding OSPF drafts of "IPv= 4 and IPv6 support for SR-MPLS" -- should the bits always be unset?


=
...
300 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Range Size: 3 octet value indicating the number of labels in
<= div style=3D"margin:0px">301 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the range.

[nit] s/labels/labels o= r SIDs

[= major] What numbers are valid in the Range Size field?=C2=A0 Can it be 0?= =C2=A0 Take a look above at my comments about derived values.

303 =C2=A0 =C2=A0 =C2=A0 =C2=A0= SID/Label sub-TLV (as defined in Section 2.1.1) which encodes
304 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the first label in the range.

[nit] s/firs= t label/first label or SID


...
339 2.1.4.=C2=A0 SR Local Block TLV
...=
380 =C2=A0 =C2=A0 =C2=A0Flags: 1 octet of flags.=C2= =A0 None are defined at this stage.

[major] Only the corresponding ISIS sub-TLV has= Flags defined -- and I realize that the text above is the same as in draft= -ietf-isis-segment-routing-extensions.=C2=A0 I think you really don't w= ant this field to evolve independently.=C2=A0 IOW, please use a description= like the you used for the Flags in the SR-Capabilities TLV.


...
393 2.1.5.=C2=A0 SRMS Preference TL= V
...
427 =C2=A0 The us= e of the SRMS Preference TLV is defined in
4= 28 =C2=A0 = [I-D.ietf-isis-segment-routing-extensions],
= 429 =C2=A0= [I-D.ietf-ospf-segment-routing-extensions] and
430 = =C2=A0 [I-D.ietf-ospf-ospfv3-segment-routing-extensions].

[major] This document o= nly defines how to carry information in BGP-LS, not what to do with it.=C2= =A0 IOW, I think that the last paragraph is not needed, it is out of scope = of this document...

432 2.2.=C2=A0 Link Attribute TLVs

434 =C2=A0 The following Link Attribute TLVs are are defi= ned:

436= =C2=A0 +-= ---------------------------------------+----------+---------------+
437 =C2=A0 | Description =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 Leng= th | =C2=A0 =C2=A0 =C2=A0 Section |
438 =C2=A0 +------= ----------------------------------+----------+---------------+
439 =C2=A0 | Adjacency Segment Identifier (Adj-SID) | variable | S= ection 2.2.1 |
440 =C2=A0 | TLV =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
441 =C2= =A0 | LAN Adjacency Segment Identifier (Adj- | variable | Section 2.2.2 |
442 =C2=A0 | SID) TLV =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
443 =C2=A0 | L2 Bundle Member TLV =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | variable | Sectio= n 2.2.3 |
444 =C2=A0 +--------------------------------= --------+----------+---------------+

446 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Table 2: Link Attribute TLVs

[minor] The names used above = don't match the names used in the sections below.

...
452 = =C2=A0 For a LAN, normally a node only announces its adjacency to the IS-IS=
453 =C2=A0 pseudo-node (or the equivalent OSPF Design= ated and Backup Designated
454 =C2=A0 Routers)[I-D.iet= f-isis-segment-routing-extensions].=C2=A0 The LAN
455 = =C2=A0 Adjacency Segment TLV allows a node to announce adjacencies to all
456 =C2=A0 other nodes attached to the LAN in a single = instance of the BGP-LS
457 =C2=A0 Link NLRI.=C2=A0 Wit= hout this TLV, the corresponding BGP-LS link NLRI
458 = =C2=A0 would need to be originated for each additional adjacency in order t= o
459 =C2=A0 advertise the SR TLVs for these neighbor = adjacencies.

[minor] This paragraph maybe fits better in =C2=A72.2.2.


461 2.2.1.=C2=A0 Adjacency SID TLV
...<= /div>
482 =C2=A0 =C2=A0 =C2=A0Flags. 1 octet field of follow= ing flags as defined in
483 =C2=A0 =C2=A0 =C2=A0[I-D.i= etf-isis-segment-routing-extensions],
484 =C2=A0 =C2= =A0 =C2=A0[I-D.ietf-ospf-segment-routing-extensions] and
485 <= /span> =C2=A0 =C2=A0 =C2=A0[I-D.ietf-ospf-ospfv3-segment-routing-extensions= ].

NEW&g= t;
=C2=A0 =C2=A0Flags: 1 octet field.=C2=A0 = The value corresponds to the Flags specified for the
=C2=A0 =C2=A0Adj-SID Sub-TLV in [I-D.ietf-isis-segment-routing-ext= ensions],
=C2=A0 =C2=A0[I-D.ietf-ospf-segmen= t-routing-extensions] or
=C2=A0 =C2=A0[I-D.i= etf-ospf-ospfv3-segment-routing-extensions].

487 =C2=A0 =C2=A0 =C2=A0Weight: Weight used for = load-balancing purposes.

[minor] Similar to the above text...

489 =C2=A0 =C2=A0 =C2=A0Reserved: 2 oct= ets that SHOULD be set to 0 and MUST be ignored on
490 = =C2=A0 =C2=A0 =C2=A0receipt.

492 =C2=A0 =C2=A0 =C2=A0SID/Index/Label: Label or index value d= epending on the flags
493 =C2=A0 =C2=A0 =C2=A0setting = as defined in [I-D.ietf-isis-segment-routing-extensions],
494 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-ospf-segment-routing-extensions] an= d
495 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-ospf-ospfv3-segmen= t-routing-extensions].

[minor] Similar text here too...


497 2.2.2= .=C2=A0 LAN Adjacency SID TLV
...
[major] The OSPF Neighbor ID / IS-IS System-ID field i= s not defined.


542 2.2.3.=C2=A0 L2 Bundle Member

[nit] s/L2 Bundle= Member/L2 Bundle Member Attribute TLV

<= /div>
544 =C2=A0 The L2 Bundle Member Attribute TLV identifi= es an L2 Bundle Member
545 =C2=A0 link which in turn i= s associated with a parent L3 link.=C2=A0 The L3 link
546 =C2=A0 is described by the Link NLRI defined in [RFC7752] and the L2 Bu= ndle
547 =C2=A0 Member Attribute TLV is associated wit= h the Link NLRI.=C2=A0 The TLV MAY
548 =C2=A0 include = sub-TLVs which describe attributes associated with the bundle
549 =C2=A0 member.=C2=A0 The identified bundle member represents a = unidirectional
550 =C2=A0 path from the originating ro= uter to the neighbor specified in the
551 =C2=A0 paren= t L3 Link.=C2=A0 Multiple L2 Bundle Member Attribute TLVs MAY be
552 =C2=A0 associated with a Link NLRI.

[minor] "identifies an L2 B= undle Member link...The identified bundle member".=C2=A0 Are we talkin= g about a link or just the members?

...
574 =C2=A0 =C2=A0 =C2= =A0L2 Bundle Member Descriptor: A Link Local Identifier as defined in
=
575 =C2=A0 =C2=A0 =C2=A0[RFC4202].

[major] From the text, it looks = like this information is not something that is learned from the IGP, which = is then just transported by BGP-LS (just like the rest of the TLVs in this = document), but table 5 points at draft-ietf-isis-l2bundles.=C2=A0 Why is dr= aft-ietf-isis-l2bundles not used to describe this TLV?

[major] rfc4202 is not IS-IS= -specific.=C2=A0 What about OSPF?=C2=A0 I note that rfc4203 defines OSPF ex= tensions that include the Link Local Identifier, so this concept is not for= eign to it.

577 = =C2=A0 Link attributes for L2 Bundle Member Links are advertised as sub-TLV= s
578 =C2=A0 of the L2Bundle Member Attribute TLV.=C2= =A0 The sub-TLVs are identical to
579 =C2=A0 existing = BGP-LS TLVs as identified in the table below.

[nit] s/L2Bundle/L2 Bundle


...
633 2.3.1.=C2=A0 Prefix-SID TLV
...
[major] dr= aft-ietf-ospf-segment-routing-extensions also includes the MT-ID in the Pre= fix SID Sub-TLV.=C2=A0 Is that not needed by a controller?

691 2.3.2.=C2=A0 Prefix Attribute = Flags TLV
...
711 =C2= =A0 =C2=A0 =C2=A0Length: variable.

[minor] The length of the flags fields in rfc779= 4/rfc7684 are both one octet long.=C2=A0 Can this length be made fixed?

[major] I c= ould not find a Flags field for OSPFv3 in rfc5340.

[minor] From Table 7, it seems t= hat the reference to rfc8362 points to the "Prefix Options Field"= , is that correct?

713 =C2=A0 =C2=A0 =C2=A0Flags: a variable length flag field (according to = the length
714 =C2=A0 =C2=A0 =C2=A0field).=C2=A0 Flags= are routing protocol specific and are to be parsed
715 =C2=A0 =C2=A0 =C2=A0as below:

717 =C2=A0 =C2=A0 =C2=A0* =C2=A0IS-IS flags are defined in [R= FC7794]

= 719 =C2=A0= =C2=A0 =C2=A0* =C2=A0OSPFv2 flags are defined in [RFC7684]

721 =C2=A0 =C2=A0 =C2=A0* =C2=A0O= SPFv3 flags map to the Prefix Options field defined in
722 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC7794] and extended via [RFC8362]
=

[nit] The tex= t at the top of this section refers to rfc5340...

[major] rfc7794 only talks about = IS-IS, not OSPFv3.


724 2.3.3.=C2=A0 Source Router Identifi= er (Source Router-ID) TLV

726 =C2=A0 The Source Router-ID TLV contains the IPv4 or IPv6 Route= r-ID of the
727 =C2=A0 originator of the Prefix.=C2=A0= For IS-IS protocol this is as defined in
72= 8 =C2=A0 [= RFC7794].=C2=A0 The Source Router-ID TLV may be used to carry the OSPF
729 =C2=A0 Router-ID of the prefix originator.

[major] Reference f= or OSPF?=C2=A0 Only "may"??

[major] rfc7752 defines the IGP Router-ID TLV= to carry the same information.=C2=A0 What is the relationship between thes= e two TLVs?=C2=A0 Since the IGP Router-ID TLV is mandatory, are there cases= where this one may not be needed?


...
745 =C2=A0 =C2=A0 =C2=A0Length: 4 or 16.

[major] OSPF always uses a 32= -bit number.=C2=A0 IOW, the length is fixed for OSPF.

...
749 2= .3.4.=C2=A0 Range TLV

751 =C2=A0 The range TLV is used in order to advertise a range of pre= fix-to-SID
752 =C2=A0 mappings as part of the Segment = Routing Mapping Server functionality
753 =C2=A0 [I-D.i= etf-spring-segment-routing-ldp-interop], as defined in the
754 =C2=A0 respective underlying IGP SR extensions
755 <= /span> =C2=A0 [I-D.ietf-ospf-segment-routing-extensions],
756 =C2=A0 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] and
757 =C2=A0 [I-D.ietf-isis-segment-routing-extensions].=C2= =A0 The Prefix-NLRI to which
758 =C2=A0 the Range TLV= is attached MUST be advertised as a non-routing prefix
759 =C2=A0 where no IGP metric TLV (TLV 1095) is attached.

[major] What do you me= an in the final sentence?=C2=A0 It sounds as if the IGP metric TLV and the = Range TLV are mutually exclusive and should never be advertised together.= =C2=A0 Is that it?=C2=A0 If so, what should the receiver do if they are?


=
761 =C2=A0 The format of the Range TLV is as follows:
=

763 =C2=A0 =C2=A00 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
= 764 =C2=A0= =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
765 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
766 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
767 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
76= 8 =C2=A0 |= =C2=A0 =C2=A0 Flags =C2=A0 =C2=A0 | Reserved =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Range Size =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= /div>
769 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+
770 =C2=A0 // =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0su= b-TLVs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 //
771 =C2=A0 +-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

773 =C2=A0 where:

[nit] That "where" s= hould be after the Figure title.

<= div style=3D"margin:0px">775 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2: Range TLV format


...
[minor] As will all the other sec= tions, please be consistent and fold the sub-sections below into the descri= ption above.

804 2.= 3.4.1.=C2=A0 Advertisement Procedure for OSPF

806 =C2=A0 The OSPFv2/OSPFv3 Extended Prefix Ra= nge TLV is encoded in the Range
807 =C2=A0 TLV.=C2=A0 = The flags of the Range TLV have the semantic mapped to the
808 =C2=A0 definition in [I-D.ietf-ospf-segment-routing-extensions] s= ection 4 or
809 =C2=A0 [I-D.ietf-ospf-ospfv3-segment-r= outing-extensions] section 4.

811 =C2=A0 Then the prefix-to-SID mapping from the OSPF Prefix = SID sub-TLV is
812 =C2=A0 encoded using the BGP-LS Pre= fix-SID TLV as defined in Section 2.3.1
813<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 wit= h the flags set according to the definition in
814 =C2= =A0 [I-D.ietf-ospf-segment-routing-extensions] section 5 or
815 =C2=A0 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] section = 5.

[majo= r] The Extended Prefix Range TLV contains other fields not present here: AF= , for instance.=C2=A0 The last paragraph seems to indicate that the prefix = information will be in the BGP-LS Prefix-SID TLV, but that information does= n't come from the Extended Prefix Range TLV (and it doesn't include= the AF).=C2=A0 What am I missing?

[major] The text above seems to imply that the R= ange TLV and the Prefix-SID TLV should always be included together.=C2=A0 I= s that true?=C2=A0 If so, please make it more explicit.

817 2.3.4.2.=C2=A0 Advertisement Proce= dure for IS-IS

819 = =C2=A0 The IS-IS SID/Label Binding TLV, when used to signal mapping server=
820 =C2=A0 label bindings, is encoded in the Range TL= V.=C2=A0 The flags of the Range
821 =C2=A0 TLV have th= e sematic mapped to the definition in
822 =C2=A0 [I-D.= ietf-isis-segment-routing-extensions] section 2.4.1.

824 =C2=A0 Then the prefix-to-SID mappin= gs from the IS-IS Prefix SID sub-TLV is
825<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 enc= oded using the BGP-LS Prefix-SID TLV as defined in Section 2.3.1
826 =C2=A0 with the flags set according to the definition in
827 =C2=A0 [I-D.ietf-isis-segment-routing-extensions] sec= tion 2.4.4.1.

[major] Same questions (as above) related to the other fields in the = SID/Label Binding TLV, and the relationship between the Range TLV and the P= refix-SID TLV.


829 2.4.=C2=A0 Equivalent IS-IS Segment Rou= ting TLVs/Sub-TLVs
...
837 =C2=A0 +---------------------------------------+----------+------------= ----+
838 =C2=A0 | Description =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Len= gth =C2=A0 | IS-IS TLV/sub- |
839 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| TLV =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
840 =C2=A0 +---------------------------------------+----------+------= ----------+
841 =C2=A0 | SR Capabilities =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | variable = | 2 [1] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
= 842 =C2=A0= | SR Algorithm =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| variable | 19 [2] =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
843 =C2=A0 | SR Local Block =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| variable |= 22 [3] =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
844 =C2=A0 | SRM= S Preference =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 | 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 19 [4] =C2=A0 =C2=A0 =C2=A0= =C2=A0 |
845 =C2=A0 | Adjacency Segment Identifier (A= dj- =C2=A0 =C2=A0| variable | 31 [5] =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
846 =C2=A0 | SID) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|
847 =C2=A0 | LAN Adjacency Segm= ent Identifier =C2=A0 =C2=A0 =C2=A0| variable | 32 [6] =C2=A0 =C2=A0 =C2=A0= =C2=A0 |
848 =C2=A0 | (LAN-Adj-SID) =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
849 =C2=A0 | Prefix SID =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| variable | 3 [7] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
850 =C2=A0 | Range =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | variable |= 149 [8] =C2=A0 =C2=A0 =C2=A0 =C2=A0|
851 =C2=A0 | SID= /Label TLV =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | variable | 1 [9] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
852 =C2=A0 | Prefix Attribute Flags =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| variable | 4 [10] =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
853 =C2=A0 | Source Router ID =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| variabl= e | 11/12 [11] =C2=A0 =C2=A0 |
854 =C2=A0 | L2 Bundle = Member TLV =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = variable | 25 [12] =C2=A0 =C2=A0 =C2=A0 =C2=A0|
855 = =C2=A0 +---------------------------------------+----------+----------------= +

[major= ] Instead of using URIs, please put an explicit pointer to the RFC/ID (and = if desired, the section)...and make sure that there are corresponding Refer= ences.=C2=A0 If a document is referenced only in this table, then the Refer= ence can be Informative.

[nit] For Tables 5-7: No need to use "TLV" in th= e description.

857 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Table 5: IS-IS Segment Routing Extension= s TLVs/Sub-TLVs

859 2.5.=C2=A0 Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs
...
886 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Table 6: OSPF Segment Routing Extensions TLVs/Sub-TLVs

[nit] s/OSPF/OS= PFv2

[mi= nor] The OSPF tables don't include the Source Router ID or the L2 Bundl= e Member TLVs.=C2=A0 Is there a reason for that, or just an oversight?

...
908 3.=C2=A0 Implementation Status

[nit] This section says nothing. :-(= =C2=A0 At least a pointer to https://trac.i= etf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-ext-implementat= ions might be nice.=C2=A0 OR, you can just remove it.


...
943 4.=C2=A0 IANA Considerations
=

945 =C2=A0 This documen= t requests assigning code-points from the registry "BGP-
946 =C2=A0 LS Node Descriptor, Link Descriptor, Prefix Descriptor, = and Attribute
947 =C2=A0 TLVs" based on table Tab= le 8.=C2=A0 The column "IS-IS TLV/Sub-TLV" defined
948 =C2=A0 in the registry does not require any value and should be = left empty.

[major] The early allocation has already been done...so this document d= oesn't request assignment from IANA.=C2=A0 Please update.


...
977 5.=C2=A0 Manageability Consider= ations

9= 79 =C2=A0 = This section is structured as recommended in [RFC5706].

981 =C2=A0 The new protocol extension= s introduced in this document augment the
98= 2 =C2=A0 e= xisting IGP topology information that was distributed via [RFC7752].
<= div style=3D"margin:0px">983 =C2=A0 Procedures and protocol extensions defined in thi= s document do not
984 =C2=A0 affect the BGP protocol o= perations and management other than as
985 =C2=A0 disc= ussed in the Manageability Considerations section of [RFC7752].
986 =C2=A0 Specifically, the malformed attribute tests for syntac= tic checks in
987 =C2=A0 the Fault Management section = of [RFC7752] now encompass the new BGP-
988<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 LS = Attribute TLVs defined in this document.=C2=A0 The semantic or content
989 =C2=A0 checking for the TLVs specified in this documen= t and their
990 =C2=A0 association with the BGP-LS NLR= I types or their BGP-LS Attribute is
991 =C2=A0 left t= o the consumer of the BGP-LS information (e.g. an application
992 =C2=A0 or a controller) and not the BGP protocol.

[nit] s/that was dist= ributed/that is distributed

994 =C2=A0 A consumer of the BGP-LS information is retrieving thi= s information
995 =C2=A0 from a BGP protocol component= that is doing the signaling over a BGP-
996= =C2=A0 LS= session, via some APIs or a data model (refer Section 1 and 2 of
997 =C2=A0 [RFC7752]).=C2=A0 The handling of semantic or conten= t errors by the
998 =C2=A0 consumer would be dictated = by the nature of its application usage and
9= 99 =C2=A0 = hence is beyond the scope of this document.=C2=A0 This document only
<= div style=3D"margin:0px">1000 =C2=A0 introduces new Attribute TLVs and an error in th= em would result in
1001 =C2=A0 only that specific attr= ibute being discarded with an error log.
[nit] s/is retrieving this/retrieves this<= /div>

[minor] = "...retrieving this information...over a BGP-LS session, via some APIs= or a data model (refer Section 1 and 2 of [RFC7752])." =C2=A0I think = that even mentioning that an API or data model can be used instead of BGP-L= S is a stretch -- that is not how I interpret the initial sections in rfc77= 52 (which are just background sections), and there are no formal API/data m= odel definition.

[major] "...new Attribute TLVs and an error in them would res= ult in only that specific attribute being discarded with an error log."= ; =C2=A0According to rfc7752, this statement is true only for syntactic err= ors, not semantic ones.

Semantic errors ("left to the consumer", as menti= oned above) means that the BGP-LS session can be used to transport trash (t= rash-in-trash-out).=C2=A0 Jeff Haas brought this up during the WGLC [4].=C2= =A0 I agree (with the Chairs' conclusion) that this issue is bigger tha= n this document -- but (because we don't have a current solution) I wou= ld like to see it mentioned somewhere as a potential issue (maybe in the Ma= nagement or Security Considerations sections, your choice).


[major] rfc7752 does = mandate the use of "attribute discard" (rfc7606). I would really = like to see a discussion (or at least a mention) around the fact that disca= rding an attribute may result in the receiver not having complete informati= on.=C2=A0 In the case of SR, this implies that the controller may not have = complete information to calculate the paths.

I think this is an issue bigger than t= his document, so I am not asking you to solve it...I'm just asking for = the document to acknowledge that it exists and to mention what the potentia= l impact may be.


1003 =C2=A0 The extensions, specified in= this document, do not introduce any new
100= 4 =C2=A0 c= onfiguration or monitoring aspects in BGP or BGP-LS other than as
1005 =C2=A0 discussed in [RFC7752].=C2=A0 The manageability asp= ects of the underlying
1006 =C2=A0 SR features are cov= ered by [I-D.ietf-spring-sr-yang],
1007 =C2=A0 [I-D.ie= tf-isis-sr-yang] and [I-D.ietf-ospf-sr-yang].

[minor] While the Yang models have to= do with management, there are no "manageability aspects of the underl= ying SR features" included there.

<= /div>
[major] Following the recommendations from r= fc5706, a Fault Management section would be appropriate to include consider= ations related to the use of BGP-LS as a transport for SR information (give= n this is the first draft to propose it), and the possible errors mentioned= here...=C2=A0 Again, not looking for solutions, just acknowledgement.


1009 6.=C2=A0 Security Considerations

1011 =C2=A0 The new protocol extensions in= troduced in this document augment the
1012 =C2=A0 exis= ting IGP topology information that was distributed via [RFC7752].
1013 =C2=A0 The Security Considerations section of [RFC7752] al= so applies to
1014 =C2=A0 these extensions.=C2=A0 The = procedures and new TLVs defined in this
1015= =C2=A0 do= cument, by themselves, do not affect the BGP-LS security model
1016 =C2=A0 discussed in [RFC7752].

[nit] s/that was distributed/that is d= istributed

1018 = =C2=A0 BGP-LS SR extensions enable traffic engineering use-cases within the=
1019 =C2=A0 Segment Routing domain.=C2=A0 SR operates= within a trusted domain (refer
1020 =C2=A0 Security C= onsiderations section in [RFC8402] for more detail) and its
1021 =C2=A0 security considerations also apply to BGP-LS sessions whe= n carrying
1022 =C2=A0 SR information.The SR traffic e= ngineering policies using the SIDs
1023 =C2=A0 adverti= sed via BGP-LS are expected to be used entirely within this
1024 =C2=A0 trusted SR domain (e.g. between multiple AS/domains withi= n a single
1025 =C2=A0 provider network).=C2=A0 Theref= ore, precaution is necessary to ensure that
= 1026 =C2= =A0 the SR information collected via BGP-LS is limited to specific
1027 =C2=A0 controllers or applications in a secure manner wit= hin this SR domain.

[nit] s/trusted domain (refer Security Considerations section i= n [RFC8402] for more detail)/trusted domain [RFC8402]

[nit] s/SR information.The SR= traffic/SR information. The SR traffic

=
[major] "SR operates within a trusted = domain...[RFC8402]...and its security considerations also apply to BGP-LS s= essions when carrying SR information." =C2=A0The Security Consideratio= ns in rfc8404 really only talk about the data plane -- I don't see how = they apply to the BGP-LS sessions.

[major] "...precaution is necessary to ensu= re that the SR information collected via BGP-LS is limited to specific cont= rollers or applications..." =C2=A0This sounds as if you're referri= ng to information that (once collected) can be shared between controllers -= - I think that case is out of scope.=C2=A0 If you are trying to talk about = the BGP sessions, then I think the language needs a little more work.=C2=A0= BTW, the paragraph below also talks about BGP sessions; suggestion: keep t= he common topics together.

[major] The end of the last sentence says "...in a = secure manner within this SR domain".=C2=A0 Assuming that we're ta= lking about BGP sessions, what does that mean?=C2=A0 Does it mean anything = beyond what BGP is normally specified to do?=C2=A0 If not, then I would rec= ommend taking that piece of text out to not invite more questions than need= ed.

[min= or] You talk about "controllers or applications", but in the rest= of the document you have mostly used "consumer" (which is a good= thing because it shows consistency with rfc8402).=C2=A0 Suggestion: use &q= uot;consumers" here as well.

=
1029 =C2=A0 The isolation of BGP-LS peering sessions is als= o required to ensure
1030 =C2=A0 that BGP-LS topology = information (including the newly added SR
10= 31 =C2=A0 = information) is not advertised to an external BGP peering session
1032 =C2=A0 outside an administrative domain.

[major] What does "= ;isolation of BGP-LS peering sessions" mean?=C2=A0 Why is it not Norma= tively REQUIRED?

[major] From prior experience (see draft-ietf-idr-te-pm-bgp), the = SecDir/Sec ADs asked for text related to why it is ok to transport the new = information in BGP.=C2=A0 This is the text that resulted from that discussi= on:

=C2= =A0 =C2=A0The TLVs introduced in this document are used to propagate IGP
=C2=A0 =C2=A0defined information ([I-D.ietf-ls= r-isis-rfc7810bis] and [RFC7471].)
=C2=A0 = =C2=A0These TLVs represent the state and resource availability of the IGP
=C2=A0 =C2=A0link.=C2=A0 The IGP instances or= iginating these TLVs are assumed to
=C2=A0 = =C2=A0support all the required security and authentication mechanisms (as
=C2=A0 =C2=A0described in [I-D.ietf-lsr-isis-= rfc7810bis] and [RFC7471]) in order
=C2=A0 = =C2=A0to prevent any security issue when propagating the TLVs into BGP-LS.<= /div>
=C2=A0 =C2=A0The advertisement of the link a= ttribute information defined in this
=C2=A0 = =C2=A0document presents no additional risk beyond that associated with the<= /div>
=C2=A0 =C2=A0existing set of link attribute = information already supported in
=C2=A0 =C2= =A0[RFC7752].

Note that this text is complementary to what is already stated in the= first paragraph -- but goes into a more explicit explanation and brings in= the security considerations from the documents where the IGP extensions ar= e defined.=C2=A0 Consider adding something similar here.


...
1126 9.2.=C2=A0 Informative References
...
1159 =C2=A0 [RFC8402]= =C2=A0Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
1160 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Decraene, B., Li= tkowski, S., and R. Shakir, "Segment
11= 61 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Routing Architecture", RFC 84= 02, DOI 10.17487/RFC8402,
1162 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[major] I think= this should be a Normative reference.

<= /div>

1164 9.3.=C2=A0 URI= s

[major= ] As mentioned before, please use References (above) instead of URIs.
=


...

[major] The reference should become N= ormative (see =C2=A72.2.3).


--0000000000008698d60581b8a910-- From nobody Wed Feb 13 11:03:06 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E74126F72 for ; Wed, 13 Feb 2019 11:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxMPVy0q59Ss for ; Wed, 13 Feb 2019 11:02:58 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE2C1200D7 for ; Wed, 13 Feb 2019 11:02:57 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.176.248.72; From: "Susan Hares" To: Cc: , "'Jakob Heitz \(jheitz\)'" References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk> <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Date: Wed, 13 Feb 2019 14:02:49 -0500 Message-ID: <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A3_01D4C3A4.CE132100" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rAefZHwsB7dxHTqRpTUcw Content-Language: en-us X-Antivirus: AVG (VPS 190213-2, 02/13/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 19:03:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A3_01D4C3A4.CE132100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno:=20 =20 I=92d like to answer some of the questions you sent Randy based on = comments (public and private) the chairs and I as the shepherd received on this = draft in our last WG LCs. =20 =20 Several of the comments you questioned were put in to answer other questions. This gets into a catch-22=85 problem =96 where you put = changes in for one person/take out the changes out for another. In academic = circles this is called the reviewer #2 problem (reviewer 1 insists changes go = in, reviewer 2 insists changes go out) during publication. Therefore, I=92m = I am going to answer most of your questions where this is the case. =20 =20 I believe that Randy has new version with the changes I=92ve indicated. = I=92m hoping he=92ll just post that version. AFAILK, we do have 2 compliant implementations.=20 =20 Sue=20 =20 =20 =20 This draft=92s technology provides efficient processing for some = application by allow a huge BGP message size. Whether =93chunking=94 BGP to 4096 = byte messages or packing large amounts of data into 65,000 byte message is = more effective for a particular application is something only an implementer = of a particular BGP implementation can decide. This draft simply gives = freedom for applications to not be restrict to an artificially small message = size. The market place will choose whether this technology is used or not. =20 =20 As Jakob pointed out, changing a highly tuned BGP implementation which =93chunks=94 BGP data into 4096 byte messages may involve substantial = rework of the implementation. =20 =20 =20 (snip)=20 From: Idr On Behalf Of bruno.decraene@orange.com Sent: 29 January 2019 13:33 To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Hi WG, =20 >Please find below some comments. >As of today, I don=92t believe this specification is ready to be = progressed to IESG/RFC, especially for a document >updating RFC 4271 (core BGP = spec). =20 > The WG chairs intend to forward this draft to the IESG with the = current level of implementation. =20 =20 >https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended- >implementations says : 5a=20 Does not send Extended Message capability=20 Yes=20 Yes=20 Yes=20 =20 >I may be misunderstanding the implementation report, but my reading of = the above is that none of the reported >implementations sends the capability hence no implementation supports draft-ietf-idr-bgp-extended-messages..=20 >Here this document is updating RFC 4271, so it is not a minor extension = for a niche use case. So I don=92t see the >arguments for not requiring the = IDR=92s usual two interoperable implementations. =20 >In our mail thread, we discovered that the implementation report should have indicate >full support. I=92m waiting for Olivier to update based on the last = point, but my understanding is that=20 All implementations have full support. =20 =20 >---- >=A7 1 >=93 As BGP is extended to support newer AFI/SAFIs and > newer capabilities (e.g., [ I-D.ietf-sidr-bgpsec-protocol]), there is > a need to extend the maximum message size beyond 4096 octets. =93 >=20 > https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on- 1 =20 =20 >[ I-D.ietf-sidr-bgpsec-protocol is now RFC = 8205 (thanks for updating the reference). It has removed the normative/any >reference to draft-ietf-idr-bgp-extended-messages. So presumably BGP = Sec does not need draft-ietf-idr-bgp->extended-messages. Can we have an = update on this? Can the introduction of draft-ietf-idr-bgp-extended-messages = >be updated to introduce on the real reasons/needs? =20 SIDR gave up waiting on IDR=92s work and took a reduced size of = encryption. The security people were very sad about the reduction. How is this = working in practice? WG sidrops can answer this question. =20 =20 The real problem is there is finite message space. =20 =20 There are two ways to send lots of BGP routes and/or attributes =96 to = =93chunk=94 these into small message sizes or place these into a large message. = Some applications may always want to =93chunk=94 into message sizes smaller = than 4096. Some application make work more efficiently utilizing large = message size. As the potential number of NLRI and BGP attributes grows, new applications may consider large message sizes to a more reasonable way = to exchange amounts of BGP data. =20 =20 The decision on how to send BGP messages over the wire is a peer-by-peer decision in a network. Each BGP peer is in charge of reformatting the = BGP message it sends to the remote BGP peer. The BGP capabilities in this draft represent an agreement between two BGP peers. These are facts of basic BGP implementations =96 so I do not believe adding these facts to Randy=92s draft is useful. In fact, in the previous rounds of review = this point was made.=20 =20 Your question (and perhaps Jakob=92s) is whether we have reached a = time/place where the =93chunking=94 approach will fail on a peer-by-peer basis? = This draft does not make this statement. =20 =20 The point of this draft is to enable more efficient processing by = increasing the message size for BGP peers that send a lot of data (e.g. BGP-LS) . = The choice to =93chunk=94 or stream in large BGP message is an = implementation choice for a particular BGP application. =20 =20 ---- =A74 =A73 says =93A peer which does not advertise this capability MUST NOT = send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.=94 =20 [I believe randy accepted this change with the following text in version = 4 [upcoming below]]/.=20 =20 -------------- =20 Fine. Text in =A74 should probably be aligned with the above .e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. =20 NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and = received the Extended Message Capability to and from that peer. =20 =20 =20 ---- >=93 Applications generating information which might be encapsulated > within BGP messages MUST limit the size of their payload to take the > maximum message size into account.=94 >=20 >I don=92t see what new behavior is been defined here. If there is none, = I would suggest to remove this sentence =20 Bruno =96 people asked to put this text in as an operational warning. = At this point, I=92m going to say unless there is harm it should remain. =20 =20 ---- > A BGP announcement will, in the normal case, propagate throughout = the > BGP speaking Internet; and there will undoubtedly be BGP speakers > which do not have the Extended Message capability. Therefore, > putting an attribute which can not be decomposed to 4096 octets or > less in an Extended Message is a likely path to routing failure. >=20 >The issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than >4096, irrespective of the size of = each attribute. >Please elaborate on what you mean by=20 >=20 >=93an attribute which cannot be decomposed to 4096 octets=94 =20 An attribute which cannot be decomposed to 4096 is an attribute with = length 6000 inside of a BGP message which requires the entire attribute to be included. No such attribute exists today. If a small BGP peers = create a =93killer application=94 that uses a 6000 byte attribute, the rest of = the Internet does not have to use it. However, the person defining that attribute must carefully specify it must go with Extended BGP messages.=20 =20 This text was added during an earlier discussion where the error cases = of a large BGP attribute was given. The originator of the common could not provide the exact description, but we agreed to put this =93warning = label=94 into the draft. This is one of the cases where adding/removing text = gets to be problematic.=20 =20 >--- >=93 It is RECOMMENDED that BGP protocol developers and implementers = are > conservative in their application and use of Extended Messages.=94 >=20 >What does this mean exactly? That they don=92t use this extension?=20 >That they don=92t use this extension unless XX_TO BE SPECIFIED_XX? =20 This warning was text that other participants asked to be added.=20 =20 It is a common sense warning. Extended messages are enabled on a peer = by peer basis as all BGP capabilities are. If you run into a Peer that = does not support the larger sizes, the BGP messages will need to be = reformatted to the smaller size. Running immediately to the Extended messages as = the default could cause problems.=20 =20 --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages. =20 >Why is this limited to future specifications? A priori, using existing = BGP mechanism (AFI/SAFI, attributes, * >communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = ?>case? This should be described in this specification. Note that this is not a = case of error handling, as every BGP=20 > speaker is behaving as specified. =20 I fail to see your logic. At this point, all BGP data (AFI/SAFI and attributes) must fit within a 4096 message. Therefore, a BGP peer A = which connects on link 1 to BGP peer B with 4096 message and on link to a BGP = peer C with extended messages only has to worry about reformatting the data. = =20 In the future, the first group that defines attribute or an NLRI that = does not fit within a 4096 BGP message and cannot be split, will need to = define how that works in the specification. There is no need to refine the = current set of specifications. =20 =20 >---- >Depending on the above specification, a section describing the = operational consequences in a network (such as the >Internet, BGP Enabled = ServiceS/VPN networks) is probably needed. Possible consequences could be BGP NLRI = >being removed in the middle of such network, or (extended) community (such as Route Targets) been removed. >Both having significant consequences on = the availability provided by the network. =20 At this point, there are no attributes or NLRI groupings that do not fit within 4096. If you define one (as SIDR did), then you will need to = have it reviewed by IDR, BESS, SPRING, and operational groups (GROW, etc). =20 =20 --- >=A74 >OLD: The Extended Message Capability only applies to all messages = except for the >OPEN message.=20 >Probably >NEW: The Extended Message Capability applies to all message types = except for the >OPEN message (type 1).=20 >---- >=A78 >=93This extension to BGP does not change BGP's underlying security = issues =BB >Before evaluating this, I think this document should first specified = how a BGP=20 >messages bigger than 4096 octets is handled when it needs to be sent to = a=20 >received not supporting this extension. =20 Nits: >OLD : to reduce compexity >NEW : to reduce complexity =20 Thanks, --Bruno =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org Subject: [Idr] WG Last Call on Extened Message Support =20 =20 This begins a 2 week WG LC on Extended Message Support for BGP (draft-ietf-idr-bgp-extended-messages-27). You can access the draft at: = =20 = https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ =20 The authors should indicate whether they know of any IPR. Implementers = are encouraged to update the implementation data at:=20 =20 =20 https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ati ons =20 The draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages. BGP message space is running short = for all of the potential attributes or additions proposed by BGP-LS = features. =20 =20 The WG chairs intend to forward this draft to the IESG with the current level of implementation. =20 =20 As you comment on the draft, please consider if: a) the technology is mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for publication. =20 =20 Sue Hares (WG Chair, Shepherd)=20 =20 =20 _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. ------=_NextPart_000_01A3_01D4C3A4.CE132100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno:

 

I’d like to answer some of the questions you sent Randy based = on comments (public and private) the chairs and I as the shepherd = received on this draft in our last WG LCs. = =A0=A0

 

Several of the comments you questioned were put in to answer other = questions.=A0=A0 This gets into a catch-22… problem – where = you put changes in for one person/take out the changes out for = another.=A0 In academic circles this is called the reviewer #2 problem = (reviewer 1 insists changes go in, reviewer 2 insists changes go out) = during publication. =A0Therefore, I’m I am going to answer most of = your questions where this is the case.=A0

 

I believe that Randy has new version with the changes I’ve = indicated.=A0 I’m hoping he’ll just post that version.=A0 = AFAILK, we do have 2 compliant implementations.

 

Sue

 

 

<shepherd hat on>

This draft’s technology provides efficient processing for some = application by allow a huge BGP message size. =A0Whether = “chunking” BGP to 4096 byte messages or packing large = amounts of data into 65,000 byte message is more effective for a = particular application is something only an implementer of a particular = BGP implementation =A0can decide. =A0=A0This draft simply gives freedom = for applications to not be restrict to an artificially small message = size.=A0 The market place will choose whether this technology is used or = not.=A0 =A0

 

As Jakob pointed out, changing a highly tuned BGP implementation = which “chunks” BGP data into 4096 byte messages may involve = substantial rework of the implementation.=A0

=A0

 

(snip)

From: Idr = <idr-bounces@ietf.org> On Behalf Of = bruno.decraene@orange.com
Sent: 29 January 2019 = 13:33
To: Susan Hares <shares@ndzh.com>
Cc: = idr@ietf.org
Subject: Re: [Idr] WG Last Call on Extened = Message Support

 

Hi = WG,

 

>Please find = below some comments.

>As of today, = I don’t believe this specification is ready to be progressed to = IESG/RFC, especially for a document >updating RFC 4271 (core BGP = spec).

 

&= gt; The WG chairs intend to forward this draft to the IESG with the = current level of implementation. 

 

>https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp= -extended->implementations says : 5a =

Does not send Extended Message capability =

Yes

Yes

Yes =

 

>I may be = misunderstanding the implementation report, but my reading of the above = is that none of the reported >implementations sends the capability = hence no implementation supports draft-ietf-idr-bgp-extended-messages.. =

>Here this = document is updating RFC 4271, so it is not a minor extension for a = niche use case. So I don’t see the >arguments for not requiring the = IDR’s usual two interoperable = implementations.

 

>In our mail thread, we discovered that the implementation report = should have indicate

>full support.=A0=A0 I’m waiting for Olivier to update based = on the last point, but my understanding is that

All implementations have full support. =A0

 

>----

>=A7 = 1

>“ As BGP is = extended to support newer AFI/SAFIs and

>   newer = capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there = is

>   a need = to extend the maximum message size beyond 4096 octets.  = “

> 

> = https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-mes= sages-27#section-1

 

 

>[I-D.ietf-sidr-bgpsec-protocol is now RFC = 8205 (thanks for updating the reference). It has removed the = normative/any >reference to = draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not = need draft-ietf-idr-bgp->extended-messages. Can we have an update on this? =A0Can the introduction of draft-ietf-idr-bgp-extended-messages >be = updated to introduce on the real = reasons/needs?

 

SIDR gave up waiting on IDR’s work and took a reduced size of = encryption.=A0=A0 The security people were very sad about the = reduction.=A0 How is this working in practice? WG sidrops can answer = this question.=A0

 

The real problem is there is finite message space.=A0 =

 

There are two ways to send lots of BGP routes and/or attributes = – to “chunk” these into small message sizes or place = these into a large message.=A0=A0 =A0Some applications may always want = to “chunk” into message sizes smaller than 4096.=A0 =A0Some = application make work more efficiently utilizing large message size. = =A0As the potential number of NLRI and BGP attributes grows, new = applications may consider large message sizes to a more reasonable way = to exchange amounts of BGP data.=A0=A0 =A0

 

The decision on how to send BGP messages over the wire is a = peer-by-peer decision in a network.=A0 =A0Each BGP peer is in charge of = reformatting the BGP message it sends to the remote BGP peer.=A0=A0 The = BGP capabilities in this draft represent an agreement between two BGP = peers. =A0These are facts of basic BGP implementations – so I do = not believe adding these facts to Randy’s draft is useful.=A0 In = fact, in the previous rounds of review this point was made. =

 

Your question (and perhaps Jakob’s) is whether we have reached = a time/place where the “chunking” approach will fail on a = peer-by-peer basis? =A0=A0This draft does not make this statement.=A0 =

 

The point of this draft is to enable more efficient processing by = increasing the message size for BGP peers that send a lot of data (e.g. = BGP-LS) .=A0=A0 The choice to “chunk” or stream in large BGP = message is an implementation choice for a particular BGP application.=A0 =

<= o:p> 

----

=A74

=A73 says =
“A peer which does not advertise this capability MUST NOT send =
BGP

  =  Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.”<= /o:p>

 

[I believe randy accepted this change with the following text in = version 4 [upcoming below]]/.

=A0

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

<= o:p> 

F= ine. Text in =A74 should probably be aligned with the above = .e.g.

O=
LD: A =
BGP speaker

   MAY = send Extended Messages to its peer only if it has received = the

   = Extended Message Capability from that peer.

<= o:p> 

N= EW:

A BGP = speaker

   MAY = send Extended Messages to its peer only if it has sent and received = the

   = Extended Message Capability to and from that = peer.

 

 

 

----

>&=
#8220;   Applications generating information which might be =
encapsulated

>   within = BGP messages MUST limit the size of their payload to take = the

>   = maximum message size into account.”

> 

>I = don’t see what new behavior is been defined here. If there is = none, I would suggest to remove this sentence

 

Bruno – people asked to put this text in as an operational = warning. =A0At this point, I’m going to say unless there is harm = it should remain.=A0

<= o:p> 

-= ---

>   A BGP = announcement will, in the normal case, propagate throughout = the

>   BGP = speaking Internet; and there will undoubtedly be BGP = speakers

>   which = do not have the Extended Message capability.  = Therefore,

>   = putting an attribute which can not be decomposed to 4096 octets = or

>   less = in an Extended Message is a likely path to routing = failure.

><= o:p> 

>T= he issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than >4= 096, irrespective of the size of each attribute.

>P= lease elaborate on what you mean by

> 

>&= #8220;an attribute which cannot be decomposed to 4096 octets”

 

An attribute which cannot be decomposed to 4096 is an attribute with = length 6000 inside of a BGP message which requires the entire attribute = to be included.=A0 =A0No such attribute exists today.=A0 =A0If a small = BGP peers create a “killer application” that uses a 6000 = byte attribute, the rest of the Internet does not have to use it.=A0=A0 = However, the person defining that attribute must carefully specify it = must go with Extended BGP messages.

 

This text was added during an earlier discussion where the error = cases of a large BGP attribute was given.=A0 The originator of the = common could not provide the exact description, but we agreed to put = this =A0“warning label” into the draft.=A0=A0 This is one of = the cases where adding/removing text gets to be problematic. =

=A0<= o:p>

>-= --

>“   = It is RECOMMENDED that BGP protocol developers and implementers = are

>   = conservative in their application and use of Extended = Messages.”

> 

>What does = this mean exactly? That they don’t use this extension?

>That they = don’t use this extension unless XX_TO BE SPECIFIED_XX?

 

This warning was text that other participants asked to be added. =

 

It is a common sense warning.=A0 Extended messages are enabled on a = peer by peer basis as all BGP capabilities are.=A0 If you run into a = Peer that does not support the larger sizes, the BGP messages will need = to be reformatted to the smaller size.=A0 =A0Running immediately to the = Extended messages as the default could cause problems. =

<= o:p> 

-= --

  Future = protocol specifications will need to describe how to = handle

   peers = which can only accommodate 4096 octet messages.

<= o:p> 

>Why is this = limited to future specifications? A priori, using existing BGP mechanism = (AFI/SAFI, attributes, * >communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = ?>case? This should be described = in this specification. Note that this is not a case of error handling, = as every BGP

> speaker is = behaving as specified.

 

I fail to see your logic.=A0 At this point, all BGP data (AFI/SAFI = and attributes) must fit within a 4096 message.=A0 =A0Therefore, a BGP = peer A which connects on link 1 to BGP peer B with 4096 message and on = link to a BGP peer C with extended messages only has to worry about = reformatting the data.=A0

 

In the future, the first group that defines attribute or an NLRI that = does not fit within a 4096 BGP message and cannot be split, will need to = define how that works in the specification.=A0 There is no need to = refine the current set of specifications.=A0=A0

 

>-= ---

>D= epending on the above specification, a section describing the = operational consequences in a network (such as the >I= nternet, BGP Enabled ServiceS/VPN networks) is probably needed. Possible = consequences could be BGP NLRI >b= eing removed in the middle of such network, or (extended) community = (such as Route Targets) been removed. >B= oth having significant consequences on the availability provided by the = network.

 

At this point, there are no attributes or NLRI groupings that do not = fit within 4096.=A0 =A0If you define one (as SIDR did), then you will = need to have it reviewed by IDR, BESS, SPRING, and operational groups = (GROW, etc).=A0

<= o:p> 

-= --

>=A7= 4

>OLD: The Extended = Message Capability only applies to all messages except for the >OPEN message. =

>Probably

>NEW: The Extended = Message Capability applies to all message types except for the >OPEN message (type 1). =

>----

>=A78

>“This =
extension to BGP does not change BGP's underlying security =
issues =BB
>Before evaluating =
this, I think this document should first specified how a BGP 
>messages bigger =
than 4096 octets is handled when it needs to be sent to a 
>received not supporting this extension.

 

N= its:

>OLD : to = reduce compexity

>NEW : to = reduce complexity

 

T= hanks,

-= -Bruno

<= o:p> 

From:= Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Tuesday, January 29, = 2019 12:33 PM
To: idr@ietf.org
Subject: [Idr] = WG Last Call on Extened Message = Support

 

<= o:p> 

T= his begins a 2 week WG LC on Extended Message Support for BGP = (draft-ietf-idr-bgp-extended-messages-27).  You can access the = draft at:

<= o:p> 

https://datat= racker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/<= o:p>

<= o:p> 

T= he authors should indicate whether they know of any IPR.   = Implementers are encouraged to update the  implementation data at: =

<= o:p> 

https://trac.= ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations= <= o:p>

<= o:p> 

T= he draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages.  BGP message space is = running short for all of the potential attributes or additions proposed = by BGP-LS features. 

<= o:p> 

T= he WG chairs intend to forward this draft to the IESG with the current = level of implementation. 

<= o:p> 

A= s you comment on the draft, please consider if: a) the technology is = mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for = publication. 

<= o:p> 

S= ue Hares (WG Chair, Shepherd)

<= o:p> 

 = 

_________________________=
_________________________________________________________________________=
_______________________
 <=
/pre>
Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le =
signaler
a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 <=
/pre>
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received =
this email in error, please notify the sender and delete this message =
and its attachments.
As emails may be =
altered, Orange is not liable for messages that have been modified, =
changed or falsified.
Thank =
you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles =
d'alteration,
Orange decline =
toute responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This =
message and its attachments may contain confidential or privileged =
information that may be protected by =
law;
they should not be =
distributed, used or copied without =
authorisation.
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments.
As emails may be altered, Orange is not liable for messages =
that have been modified, changed or =
falsified.
Thank =
you.
------=_NextPart_000_01A3_01D4C3A4.CE132100-- From nobody Wed Feb 13 13:36:19 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B96128766 for ; Wed, 13 Feb 2019 13:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a1gfPqNTD1d for ; Wed, 13 Feb 2019 13:36:17 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2416E12785F for ; Wed, 13 Feb 2019 13:36:17 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gu2CT-0004yy-Cy; Wed, 13 Feb 2019 21:36:13 +0000 Date: Wed, 13 Feb 2019 13:36:12 -0800 Message-ID: From: Randy Bush To: Cc: Susan Hares , "idr@ietf.org" In-Reply-To: <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 21:36:19 -0000 dear reviewer #2: excuse, this has been in an edit buffer for weeks. > [I-D.ietf-sidr-bgpsec-protocol > is now RFC 8205 (thanks for updating the reference). It has removed the n= ormative/any reference to > draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not need= draft-ietf-idr-bgp-extended-messages.=20 > Can we have an update on this? extended-messages authors had $dayjobs and did not have the stamina for the level of dos in the sidr wg. they were desperate to get bgpsec our the door and idr was holding them hostage. and it's not like bgpsec is just around the corner. > Can the introduction of draft-ietf-idr-bgp-extended-messages be > updated to introduce on the real reasons/needs? would you like it if we threw in bgp-ls? no extra charge. > =A73 says "A peer which does not advertise this capability MUST NOT send = BGP > Extended Messages, and BGP Extended Messages MUST NOT be sent to it." >=20 > Fine. Text in =A74 should probably be aligned with the above .e.g. >=20 > OLD: A BGP speaker > MAY send Extended Messages to its peer only if it has received the > Extended Message Capability from that peer. >=20 > NEW: > A BGP speaker > MAY send Extended Messages to its peer only if it has sent and receive= d the > Extended Message Capability to and from that peer. the intent was to allow simplexity, use of extended messages in one direction only. in retrospect, this may be too subtle/clever. it could be as you suggest if no one wants simplexity. > " Applications generating information which might be encapsulated > within BGP messages MUST limit the size of their payload to take the > maximum message size into account." >=20 > I don't see what new behavior is been defined here. If there is none, I w= ould suggest to remove this sentence it was added to reaffirm what to you is obvious. unless you really object, i see no harm in leaving it. > A BGP announcement will, in the normal case, propagate throughout the > BGP speaking Internet; and there will undoubtedly be BGP speakers > which do not have the Extended Message capability. Therefore, > putting an attribute which can not be decomposed to 4096 octets or > less in an Extended Message is a likely path to routing failure. >=20 > The issue is not specific to attributes bigger than 4096 octets, but to B= GP message whose length is bigger than 4096, irrespective of the size of ea= ch attribute. > Please elaborate on what you mean by "an attribute which can not be decom= posed to 4096 octets" a prefix announcement with 200 researcher-invents-massive-attribute? :) [ nanog joke ] > --- > " It is RECOMMENDED that BGP protocol developers and implementers are > conservative in their application and use of Extended Messages." >=20 > What does this mean exactly? That they don't use this extension? That the= y don't use this extension unless XX_TO BE SPECIFIED_XX? >=20 > --- > Future protocol specifications will need to describe how to handle > peers which can only accommodate 4096 octet messages. >=20 > Why is this limited to future specifications? A priori, using existing BG= P mechanism (AFI/SAFI, attributes, * communities) one could exceed the size= of 4096 octets. How does the BGP speaker supposed to behave in this case? = This should be described in this specification. Note that this is not a cas= e of error handling, as every BGP speaker is behaving as specified. > ---- > Depending on the above specification, a section describing the operationa= l consequences in a network (such as the Internet, BGP Enabled ServiceS/VPN= networks) is probably needed. Possible consequences could be BGP NLRI bein= g removed in the middle of such network, or (extended) community (such as R= oute Targets) been removed. Both having significant consequences on the ava= ilability provided by the network. >=20 > --- > =A74 > OLD: The Extended Message Capability only applies to all messages except = for the OPEN message. > Probably > NEW: The Extended Message Capability applies to all message types except = for the OPEN message (type 1). > ---- > =A78 >=20 > "This extension to BGP does not change BGP's underlying security issues = =BB >=20 > Before evaluating this, I think this document should first specified how = a BGP messages bigger than 4096 octets is handled when it needs to be sent = to a received not supporting this extension. >=20 > Nits: > OLD : to reduce compexity > NEW : to reduce complexity i took some edits, tyvm. randy From nobody Wed Feb 13 13:37:55 2019 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBE212785F; Wed, 13 Feb 2019 13:37:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <155009387335.9606.16099027124917441003@ietfa.amsl.com> Date: Wed, 13 Feb 2019 13:37:53 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-28.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 21:37:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Extended Message support for BGP Authors : Randy Bush Keyur Patel Dave Ward Filename : draft-ietf-idr-bgp-extended-messages-28.txt Pages : 6 Date : 2019-02-13 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs and other features, there is a need to extend the maximum message size beyond 4096 octets. This document updates the BGP specification RFC4271 by providing an extension to BGP to extend its current maximum message size from 4096 octets to 65535 octets for all except the OPEN message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-28 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-extended-messages-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-28 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 13 15:41:59 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6B1130E57 for ; Wed, 13 Feb 2019 15:41:57 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhCgR_zFAJsK for ; Wed, 13 Feb 2019 15:41:55 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C19128B01 for ; Wed, 13 Feb 2019 15:41:54 -0800 (PST) Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id D5A0D242575; Thu, 14 Feb 2019 00:41:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1550101311; bh=74DRdo24XjnxooLBHDybQwh/kKJjvRlE/w2MSVIg1GE=; h=Subject:To:References:From:Date:In-Reply-To; b=regMGwfy6ZuCN56X0CqObh0LdZhrJybpv5+HAmXpxP6j2d4oFoTbcAFivshjq02uq 2G6GOEz37e2QAs6Vs5TlSEq44nVHyo+8N+1rTuiZokdSD7vrmVdV2Y20wX08ZMM2a4 gUfy5NWw3cqhUWRf7grjVMgr8+ThTNbVl41qHixI= To: Susan Hares , idr@ietf.org References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> From: Robert Varga Openpgp: preference=signencrypt Message-ID: Date: Thu, 14 Feb 2019 00:41:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <007b01d4b7c6$5b002210$11006630$@ndzh.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GCQwdBk57nSzjhMdf9uocmtD16wT0QkEE" Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 23:41:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GCQwdBk57nSzjhMdf9uocmtD16wT0QkEE Content-Type: multipart/mixed; boundary="caPeHwWfPVvV1D3VE4AiKb3Luf7fDilSB"; protected-headers="v1" From: Robert Varga To: Susan Hares , idr@ietf.org Message-ID: Subject: Re: [Idr] WG Last Call on Extened Message Support References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> In-Reply-To: <007b01d4b7c6$5b002210$11006630$@ndzh.com> --caPeHwWfPVvV1D3VE4AiKb3Luf7fDilSB Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello everyone, On 29/01/2019 12:32, Susan Hares wrote: > =A0 >=20 > This begins a 2 week WG LC on Extended Message Support for BGP > (draft-ietf-idr-bgp-extended-messages-27).=A0 You can access the draft = at: >=20 > =A0 >=20 > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ >=20 > =A0 >=20 > The authors should indicate whether they know of any IPR.=A0=A0 Impleme= nters > are encouraged to update the=A0 implementation data at: >=20 > =A0 >=20 > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-impleme= ntations I have updated the report with the behavior of OpenDaylight implementation to the extent I could quickly ascertain. I suspect all 12 answers in the Management Information are either Yes, or N/A (in case of CLI), but I currently do not have the cycles to make a definitive answer, sorry :( [snip] > As you comment on the draft, please consider if: a) the technology is > mature, b) the additional space in a BGP message would be helpful for > those deploying BGP-LS or SR, and c) if the specification is ready for > publication.=20 As an implementer: we have implemented this extension many moons ago based on a request from a real-life deployment. I believe the answer to all three questions is yes. Regards, Robert --caPeHwWfPVvV1D3VE4AiKb3Luf7fDilSB-- --GCQwdBk57nSzjhMdf9uocmtD16wT0QkEE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlxkqzkLHG5pdGVAaHEu c2sACgkQJKB0S2uuNduAZQ/9EXGClJccTgePv9no5Jj8qPM9AvcLN+hcXzeJuyjy nZ50WTZHGTezjn9Gv5B+8iMw/9jBwRRYezSbYFrxkmVeVMG0AVe6ERXifEgIOAjq mVAZ6gX2ZTQq2J9IpcypL7cmmmQcm1QlrCEHR8raZEQKfilCuflQ1qXUI9JWWifX 9Ob51+c6WN32bJmMbk86FN5asWUumIubzgKQTWvGEur74QKZ8fcJ7a1Mu7Jwx1yr ZbsjuAhsHCyMDaTX7pLKMr9MOJjgYZVLD1Z3kHsTi3nT1cQQFoGnopyyT5UDUTuf 7AJTc22vYvecdwu+zI82SwgIaGwjJNqBq+yV+ZVWuVSt+MdFYmFc36bTveaX6Ccs QVr7bvcLsi6nV8xRma7q7BXGzj4TSDiBuyZ9omKK1xm7t2tv1VXa3UP47YkiF3vK EvjwbmwVkMF1NSfw2x5CPoe+mhu3SdOMT6i6XmW1000mOFGU48FZ6JAJ6JhQZ4ne e9btbMZMW+977hmQ79b0ZiXZJrCeK4LtGI4uAYU+KMokGdfna87OQE5vBvSLfKI2 LGSEGdCKgEV+V03nFDYWg6mMK1C5z4gQu8Rxxbor9ZmPJTZUTYqZrZzsCJeM2HX0 ohbn1+ZBP5rVLf/XfYE/KkWP20zjaXX85TBhXPNBgw5trpx5s4RYwfKU304oBC52 QiM= =xg2h -----END PGP SIGNATURE----- --GCQwdBk57nSzjhMdf9uocmtD16wT0QkEE-- From nobody Wed Feb 13 16:00:45 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF55130E9C for ; Wed, 13 Feb 2019 16:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isYvVc8HRN0M for ; Wed, 13 Feb 2019 16:00:40 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A926A128B01 for ; Wed, 13 Feb 2019 16:00:39 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.176.248.72; From: "Susan Hares" To: "'Robert Varga'" , References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> In-Reply-To: Date: Wed, 13 Feb 2019 19:00:28 -0500 Message-ID: <001501d4c3f8$4bcc8f70$e365ae50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQKXKlI9pISVkTA= Content-Language: en-us X-Antivirus: AVG (VPS 190213-4, 02/13/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 00:00:42 -0000 Robert:=20 The management section is option and standardization does not depend on = that portion of the implementation report. It is extremely valuable = information that Opendaylight has yes or (n/a).=20 Susan Hares=20 -----Original Message----- From: Robert Varga [mailto:nite@hq.sk]=20 Sent: Wednesday, February 13, 2019 6:42 PM To: Susan Hares; idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support Hello everyone, On 29/01/2019 12:32, Susan Hares wrote: > =A0 >=20 > This begins a 2 week WG LC on Extended Message Support for BGP=20 > (draft-ietf-idr-bgp-extended-messages-27).=A0 You can access the draft = at: >=20 > =A0 >=20 > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ >=20 > =A0 >=20 > The authors should indicate whether they know of any IPR.=A0=A0=20 > Implementers are encouraged to update the=A0 implementation data at: >=20 > =A0 >=20 > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implem > entations I have updated the report with the behavior of OpenDaylight = implementation to the extent I could quickly ascertain. I suspect all 12 answers in the Management Information are either Yes, or N/A (in case of CLI), but I currently do not have the cycles to make a definitive answer, sorry :( [snip] > As you comment on the draft, please consider if: a) the technology is=20 > mature, b) the additional space in a BGP message would be helpful for=20 > those deploying BGP-LS or SR, and c) if the specification is ready for = > publication. As an implementer: we have implemented this extension many moons ago = based on a request from a real-life deployment. I believe the answer to all = three questions is yes. Regards, Robert From nobody Wed Feb 13 19:15:55 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70913130EFF; Wed, 13 Feb 2019 19:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukTxaoVKTghg; Wed, 13 Feb 2019 19:15:51 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CFF12958B; Wed, 13 Feb 2019 19:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48698; q=dns/txt; s=iport; t=1550114151; x=1551323751; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0KFuVCBrgPBdYygRjbM1M0dhVFAWHak/I+nmBjYwFDo=; b=huAp5h1a6lH0ee7vAJbAfXtdjvWI6YCPng1GrLRgSm0EVXPvj8s3KWdh l+gN47ALtvSRI3HDE4IXSnKDyI2K0+jup/vIz3mA7YeS3q/M7Qg+/dLc2 6ubvr4hPPYp3kdlQTfvXNZxA5ExE5RGlxxFfjTqFQQgVVSQGurb+cuMt4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACt3GRc/5pdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBAYFULmeBAycKg3yIGo4DfIgujmkUgWc?= =?us-ascii?q?LAQElhEcCF4NCIjQJDQEDAQECAQECbRwMQgEQAYR2AQEBBBoBCBE+AgUMBAI?= =?us-ascii?q?BCA4DBAEBAwImAgICHxEVCAgCBAENBQgTgwqBaQMVDwOpY4EvhC8Bg14Nghk?= =?us-ascii?q?FgQuLOReBQD+BEAGCFEk1gldHAoEdDBERLQ8Ggl2CVwKKA4Y6hnaLGAUkMwk?= =?us-ascii?q?ChziDbYNxgzMhgW2FUoswiXc+gQ+EMoEqh1yDIQIRFIEnHziBVnAVGiGCbII?= =?us-ascii?q?oF4hfhT9BMYdVhVmBLoEfAQE?= X-IronPort-AV: E=Sophos;i="5.58,367,1544486400"; d="scan'208";a="518219445" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2019 03:15:49 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x1E3FmOZ032092 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Feb 2019 03:15:49 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 13 Feb 2019 21:15:48 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Wed, 13 Feb 2019 21:15:48 -0600 From: "Ketan Talaulikar (ketant)" To: Alvaro Retana , "draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" CC: Susan Hares , "idr-chairs@ietf.org" , "idr@ietf. org" Thread-Topic: AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext-11 Thread-Index: AQHUwxa4VuGTHvZuSEu7H9DbrilWbKXeoMlw Date: Thu, 14 Feb 2019 03:15:47 +0000 Message-ID: <9b284b9d8bfb4f2f9bd4680d0e4278ef@XCH-ALN-008.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.88.99] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext-11 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 03:15:54 -0000 SGkgQWx2YXJvLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4gSSB3aWxs IG9uIHRoZXNlIGFsb25nIHdpdGggY28tYXV0aG9ycyBhbmQgZ2V0IGJhY2sgd2l0aCB1cGRhdGVz Lg0KDQpUaGFua3MsDQpLZXRhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog QWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4gDQpTZW50OiAxMyBGZWJydWFy eSAyMDE5IDAyOjI3DQpUbzogZHJhZnQtaWV0Zi1pZHItYmdwLWxzLXNlZ21lbnQtcm91dGluZy1l eHRAaWV0Zi5vcmcNCkNjOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPjsgaWRyLWNoYWly c0BpZXRmLm9yZzsgaWRyQGlldGYuIG9yZyA8aWRyQGlldGYub3JnPg0KU3ViamVjdDogQUQgUmV2 aWV3IG9mIGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctZXh0LTExDQoNCkRl YXIgYXV0aG9yczoNCg0KSSBqdXN0IGZpbmlzaGVkIG15IHJldmlldyBvZiB0aGlzIGRvY3VtZW50 IC0tIHBsZWFzZSBzZWUgaW5saW5lIGNvbW1lbnRzL3F1ZXN0aW9ucy4NCg0KSW4gZ2VuZXJhbCwg SSB0aGluayB0aGF0IHRoZXJlIGlzIG1vcmUgd29yayBuZWVkZWQgaW4gYXQgbGVhc3QgdHdvIGZy b250czoNCg0KKDEpIENvbnNpc3RlbmN5IGluIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBuZXcg VExWcy4gIE1vc3Qgb2YgdGhlIGRlc2NyaXB0aW9ucyBwb2ludCBhdCBvdGhlciBkb2N1bWVudHMs IGJ1dCB0aGV5IGRvbid0IGRvIHNvIGluIGEgY29uc2lzdGVudA0KbWFubmVyOiBzb21lIGF0IHRo ZSBzdGFydCBvZiB0aGUgc2VjdGlvbiwgb3RoZXJzIHdoZW4gcG9pbnRpbmcgYXQgdGhlIHZhbHVl cywgZXRjLiAgUGxlYXNlIGJlIGNvbnNpc3RlbnQhICBHaXZlbiB0aGF0IMKnMi40LzIuNSBhbHJl YWR5IGhhdmUgYSBzdW1tYXJ5LCBJIHBlcnNvbmFsbHkgZmluZCB0aGUgaW5mb3JtYXRpb24gaW4g dGhlIGluZGl2aWR1YWwgc2VjdGlvbnMgcmVkdW5kYW50LiAgSW5zdGVhZCBvZiBhIHN0YXRlbWVu dCBhdCB0aGUgc3RhcnQgb2YgYSBzZWN0aW9uLCBJIHByZWZlciB5b3UgdG8gYmUgc3BlY2lmaWMg YWJvdXQgdGhlIHZhbHVlcyAtLSBzZWUgwqcyLjEuMiBmb3IgYW4gZXhhbXBsZS4NCg0KUGxlYXNl IG5vdGUgdGhhdCBtb3N0IG9mIG15IGNvbW1lbnRzIHJlbGF0ZWQgdG8gdGhlIHNwZWNpZmljYXRp b24gb2YgdGhlIFRMVnMgYXBwbHkgdG8gbXVsdGlwbGUgc2VjdGlvbnMsIG5vdCBqdXN0IHRoZSBv bmUgd2hlcmUgSSBtYWRlIHRoZW0uICBJIHBvaW50ZWQgdGhpcyBvdXQgaW4gbW9zdCBjYXNlcywg YnV0IG1heSBoYXZlIG1pc3NlZCBzb21lLg0KDQoNCigyKSBFcnJvciBIYW5kbGluZy4gIEFzIGhh cyBiZWVuIGRpc2N1c3NlZCBvbiB0aGUgbGlzdCAoZm9yIGV4YW1wbGUgaW4gWzFdLCBbMl0gYW5k IFszXSksIHJmYzc3NTIgY291bGQgdXNlIGVuaGFuY2VtZW50cyBhcyBpdCByZWxhdGVzIHRvIGNv bnNpZGVyaW5nIGVycm9yIGhhbmRsaW5nIHdpdGggYXBwbGljYXRpb25zIHN1Y2ggYXMgU1IsIGFu ZCBpbiBnZW5lcmFsLiAgVGhvc2UgaXNzdWVzIGRvbid0IG5lZWQgdG8gYmUgZml4ZWQgaW4gdGhp cyBkb2N1bWVudCwgYnV0IEkgd291bGQgbGlrZSB0byBzZWUgaW4gdGhpcyBkb2N1bWVudCBzb21l IHRleHQgYWJvdXQgdGhlIHBvdGVudGlhbCBlZmZlY3Q6IG1heWJlIGluIHRlcm1zIG9mIHRoZSBl ZmZlY3QgdGhhbiBhbiBlcnJvciBtaWdodCBoYXZlIGZyb20gYW4gb3BlcmF0aW9ucyBvciBtYW5h Z2VtZW50IHBvaW50IG9mIHZpZXcuLi4NClNlZSBteSBjb21tZW50cyBiZWxvdyBmb3Igc3BlY2lm aWNzLiAgQWdhaW4sIG5vdCBsb29raW5nIGZvciB0aGlzIGRvY3VtZW50IHRvICJmaXgiIEJHUC1M UywgYnV0IHRvIGNvbnNpZGVyIHRoZSBlZmZlY3Qgb24gdGhlIGV4cGVjdGVkIGZ1bmN0aW9uIGEg Y29udHJvbGxlciBtaWdodCBoYXZlLCBhcyBkZXNjcmliZWQgaW4gdGhlIEludHJvZHVjdGlvbi4N Cg0KWzFdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaWRyL1RtMHZsdS1F Q1NuSUF5TzFieWo2OEFKbTJYVQ0KWzJdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvaWRyLzBxc2p1VmFFaHJvS0luSFpNb2hQNkhuc1dkOA0KWzNdIGh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaWRyLy1DWkdBaUM4RDNLb2dMblVzNkNsV19LbFUyNA0K DQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQoNCltMaW5lIG51bWJlcnMgY29tZSBmcm9tIGlkbml0 cy5dDQoNCi4uLg0KMjcgUmVxdWlyZW1lbnRzIExhbmd1YWdlDQoNCjI5ICAgVGhlIGtleSB3b3Jk cyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0K MzAgICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJP UFRJT05BTCIgaW4gdGhpcw0KMzEgICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMg ZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4NCg0KW21ham9yXSBQbGVhc2UgdXNlIHRo ZSByZmM4MTc0IHRlbXBsYXRlLg0KDQoNCi4uLg0KOTkgMS4gIEludHJvZHVjdGlvbg0KLi4uDQox MTAgICBUd28gdHlwZXMgb2YgSUdQIHNlZ21lbnRzIGFyZSBkZWZpbmVkLCBQcmVmaXggc2VnbWVu dHMgYW5kIEFkamFjZW5jeQ0KMTExICAgc2VnbWVudHMuICBQcmVmaXggc2VnbWVudHMsIGJ5IGRl ZmF1bHQsIHJlcHJlc2VudCBhbiBFQ01QLWF3YXJlDQoxMTIgICBzaG9ydGVzdC1wYXRoIHRvIGEg cHJlZml4LCBhcyBwZXIgdGhlIHN0YXRlIG9mIHRoZSBJR1AgdG9wb2xvZ3kuDQoxMTMgICBBZGph Y2VuY3kgc2VnbWVudHMgcmVwcmVzZW50IGEgaG9wIG92ZXIgYSBzcGVjaWZpYyBhZGphY2VuY3kg YmV0d2Vlbg0KMTE0ICAgdHdvIG5vZGVzIGluIHRoZSBJR1AuICBBIHByZWZpeCBzZWdtZW50IGlz IHR5cGljYWxseSBhIG11bHRpLWhvcCBwYXRoDQoxMTUgICB3aGlsZSBhbiBhZGphY2VuY3kgc2Vn bWVudCwgaW4gbW9zdCBvZiB0aGUgY2FzZXMsIGlzIGEgb25lLWhvcCBwYXRoLg0KMTE2ICAgW1JG Qzg0MDJdLg0KDQpbbml0XSByZmM4NDAyIGRlZmluZXMgbW9yZSB0aGFuIDIgSUdQIHNlZ21lbnRz Lg0KDQpbbml0XSBzL29uZS1ob3AgcGF0aC4gW1JGQzg0MDJdLi9vbmUtaG9wIHBhdGggW1JGQzg0 MDJdLg0KDQoxMTggICBXaGVuIFNlZ21lbnQgUm91dGluZyBpcyBlbmFibGVkIGluIGEgSUdQIGRv bWFpbiwgc2VnbWVudHMgYXJlDQoxMTkgICBhZHZlcnRpc2VkIGluIHRoZSBmb3JtIG9mIFNlZ21l bnQgSWRlbnRpZmllcnMgKFNJRHMpLiAgVGhlIElHUCBsaW5rLQ0KMTIwICAgc3RhdGUgcm91dGlu ZyBwcm90b2NvbHMgaGF2ZSBiZWVuIGV4dGVuZGVkIHRvIGFkdmVydGlzZSBTSURzIGFuZA0KMTIx ICAgb3RoZXIgU1ItcmVsYXRlZCBpbmZvcm1hdGlvbi4gIElHUCBleHRlbnNpb25zIGFyZSBkZXNj cmliZWQgaW46IElTLUlTDQoxMjIgICBbSS1ELmlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0 ZW5zaW9uc10sIE9TUEZ2Mg0KMTIzICAgW0ktRC5pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLWV4 dGVuc2lvbnNdIGFuZCBPU1BGdjMNCjEyNCAgIFtJLUQuaWV0Zi1vc3BmLW9zcGZ2My1zZWdtZW50 LXJvdXRpbmctZXh0ZW5zaW9uc10uICBVc2luZyB0aGVzZQ0KMTI1ICAgZXh0ZW5zaW9ucywgU2Vn bWVudCBSb3V0aW5nIGNhbiBiZSBlbmFibGVkIHdpdGhpbiBhbiBJR1AgZG9tYWluLg0KDQpbbml0 XSBzL2EgSUdQIGRvbWFpbi9hbiBJR1AgZG9tYWluDQoNCjEyNyAgICAgICAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0rDQoxMjggICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBD b25zdW1lciAgfA0KMTI5ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsN CjEzMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4NCjEzMSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCjEzMiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHYNCjEzMyAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rDQoxMzQg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgQkdQIFNwZWFrZXIgICAgfCAgICAgICAgICstLS0t LS0tLS0tLSsNCjEzNSAgICAgICAgICAgICAgICAgICAgICAgfCAoUm91dGUtUmVmbGVjdG9yKSB8 ICAgICAgICAgfCBDb25zdW1lciAgfA0KMTM2ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0tLS0rDQoxMzcgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIF4gICBeICAgXiAgICAgICAgICAgICAgICAgICAgICAgXg0KMTM4ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgfCAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwN CjEzOSAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgIHwgICArLS0tLS0tLS0tLS0tLS0t LS0tLSsgICB8DQoxNDAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICB8ICAgfA0KMTQxICAgICAgICAgICAgIHYgICAgICAgICAgICAgICAgICAg diAgICAgICAgICAgICAgICAgICAgICAgdiAgIHYNCjE0MiAgICAgICArLS0tLS0tLS0tLS0rICAg ICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KMTQzICAgICAgIHwg ICAgQkdQICAgIHwgICAgICAgfCAgICBCR1AgICAgfCAgICAgICAgICAgICB8ICAgIEJHUCAgICB8 DQoxNDQgICAgICAgfCAgU3BlYWtlciAgfCAgICAgICB8ICBTcGVha2VyICB8ICAgIC4gLiAuICAg IHwgIFNwZWFrZXIgIHwNCjE0NSAgICAgICArLS0tLS0tLS0tLS0rICAgICAgICstLS0tLS0tLS0t LSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KMTQ2ICAgICAgICAgICAgIF4gICAgICAgICAg ICAgICAgICAgXiAgICAgICAgICAgICAgICAgICAgICAgICBeDQoxNDcgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCjE0OCAgICAgICAg ICAgIElHUCAgICAgICAgICAgICAgICAgSUdQICAgICAgICAgICAgICAgICAgICAgICBJR1ANCg0K MTUwICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBMaW5rIFN0YXRlIGluZm8gY29sbGVjdGlv bg0KDQpbbml0XSBNYXliZSBtb3ZlIHRoaXMgRmlndXJlIHNvIGl0IGlzIGNsb3NlciB0byB3aGVy ZSBpdCBpcyByZWZlcmVuY2VkLg0KDQouLi4NCjE1OSAgIEluIG9yZGVyIHRvIGFkZHJlc3MgdGhl IG5lZWQgZm9yIGFwcGxpY2F0aW9ucyB0aGF0IHJlcXVpcmUNCjE2MCAgIHRvcG9sb2dpY2FsIHZp c2liaWxpdHkgYWNyb3NzIElHUCBhcmVhcywgb3IgZXZlbiBhY3Jvc3MgQXV0b25vbW91cw0KMTYx ICAgU3lzdGVtcyAoQVMpLCB0aGUgQkdQLUxTIGFkZHJlc3MtZmFtaWx5L3N1Yi1hZGRyZXNzLWZh bWlseSBoYXZlIGJlZW4NCjE2MiAgIGRlZmluZWQgdG8gYWxsb3cgQkdQIHRvIGNhcnJ5IExpbmst U3RhdGUgaW5mb3JtYXRpb24uICBUaGUgQkdQDQoxNjMgICBOZXR3b3JrIExheWVyIFJlYWNoYWJp bGl0eSBJbmZvcm1hdGlvbiAoTkxSSSkgZW5jb2RpbmcgZm9ybWF0IGZvcg0KMTY0ICAgQkdQLUxT IGFuZCBhIG5ldyBCR1AgUGF0aCBBdHRyaWJ1dGUgY2FsbGVkIHRoZSBCR1AtTFMgYXR0cmlidXRl IGFyZQ0KMTY1ICAgZGVmaW5lZCBpbiBbUkZDNzc1Ml0uICBUaGUgaWRlbnRpZnlpbmcga2V5IG9m IGVhY2ggTGluay1TdGF0ZSBvYmplY3QsDQoxNjYgICBuYW1lbHkgYSBub2RlLCBsaW5rLCBvciBw cmVmaXgsIGlzIGVuY29kZWQgaW4gdGhlIE5MUkkgYW5kIHRoZQ0KMTY3ICAgcHJvcGVydGllcyBv ZiB0aGUgb2JqZWN0IGFyZSBlbmNvZGVkIGluIHRoZSBCR1AtTFMgYXR0cmlidXRlLg0KMTY4ICAg RmlndXJlIDEgZGVzY3JpYmVzIGEgdHlwaWNhbCBkZXBsb3ltZW50IHNjZW5hcmlvLiAgSW4gZWFj aCBJR1AgYXJlYSwNCjE2OSAgIG9uZSBvciBtb3JlIG5vZGVzIGFyZSBjb25maWd1cmVkIHdpdGgg QkdQLUxTLiAgVGhlc2UgQkdQIHNwZWFrZXJzDQoxNzAgICBmb3JtIGFuIElCR1AgbWVzaCBieSBj b25uZWN0aW5nIHRvIG9uZSBvciBtb3JlIHJvdXRlLXJlZmxlY3RvcnMuDQoxNzEgICBUaGlzIHdh eSwgYWxsIEJHUCBzcGVha2VycyAoc3BlY2lmaWNhbGx5IHRoZSByb3V0ZS1yZWZsZWN0b3JzKSBv YnRhaW4NCjE3MiAgIExpbmstU3RhdGUgaW5mb3JtYXRpb24gZnJvbSBhbGwgSUdQIGFyZWFzIChh bmQgZnJvbSBvdGhlciBBU2VzIGZyb20NCjE3MyAgIEVCR1AgcGVlcnMpLiAgQW4gZXh0ZXJuYWwg Y29tcG9uZW50IGNvbm5lY3RzIHRvIHRoZSByb3V0ZS1yZWZsZWN0b3INCjE3NCAgIHRvIG9idGFp biB0aGlzIGluZm9ybWF0aW9uIChwZXJoYXBzIG1vZGVyYXRlZCBieSBhIHBvbGljeSByZWdhcmRp bmcNCjE3NSAgIHdoYXQgaW5mb3JtYXRpb24gaXMgb3IgaXNuJ3QgYWR2ZXJ0aXNlZCB0byB0aGUg ZXh0ZXJuYWwgY29tcG9uZW50KS4NCg0KW21pbm9yXSBUaGUgd2F5IHRoYXQgdGhlIHByb3BhZ2F0 aW9uIG9mIGluZm9ybWF0aW9uIGNhbiBiZSBjb250cm9sbGVkIGJ5IHBvbGljeSBpcyBpbXBvcnRh bnQuICBQbGVhc2UgbWFrZSBzdXJlIHRoYXQgdGhlIHRleHQgaXMgY2xlYXIgaW4gdGhlIGZhY3Qg dGhhdCB0aGUgZGlzY3Vzc2lvbiBhYm92ZSBpcyByZWZlcmVuY2luZyByZmM3NzUyIChhbmQgdGhh dCB0aGUgcmVmZXJlbmNlIHRvIGl0IGlzIG5vdCBqdXN0IGFib3V0IHRoZSBlbmNvZGluZ3MpLg0K DQoxNzcgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBleHRlbnNpb25zIHRvIEJHUC1MUyB0byBh ZHZlcnRpc2UgdGhlIFNSDQoxNzggICBpbmZvcm1hdGlvbi4gIEFuIGV4dGVybmFsIGNvbXBvbmVu dCAoZS5nLiwgYSBjb250cm9sbGVyKSB0aGVuIGNhbg0KMTc5ICAgY29sbGVjdCBTUiBpbmZvcm1h dGlvbiBmcm9tIGFjcm9zcyBhbiBTUiBkb21haW4gYW5kIGNvbnN0cnVjdCB0aGUNCjE4MCAgIGVu ZC10by1lbmQgcGF0aCAod2l0aCBpdHMgYXNzb2NpYXRlZCBTSURzKSB0aGF0IG5lZWQgdG8gYmUg YXBwbGllZCB0bw0KMTgxICAgYW4gaW5jb21pbmcgcGFja2V0IHRvIGFjaGlldmUgdGhlIGRlc2ly ZWQgZW5kLXRvLWVuZCBmb3J3YXJkaW5nLg0KMTgyICAgSGVyZSB0aGUgU1IgZG9tYWluIGlzIGRl ZmluZWQgYXMgYSBzaW5nbGUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIHRoYXQNCjE4MyAgIG1heSBi ZSBjb21wcmlzZWQgb2YgYSBzaW5nbGUgQVMgb3IgbXVsdGlwbGUgQVNlcyB1bmRlciBjb25zb2xp ZGF0ZWQNCjE4NCAgIGdsb2JhbCBTSUQgYWRtaW5pc3RyYXRpb24uDQoNCltuaXRdIHMvdW5kZXIg Y29uc29saWRhdGVkL3VuZGVyIGEgY29uc29saWRhdGVkDQoNClttYWpvcl0gUGxlYXNlIGRvbid0 IHJlZGVmaW5lICJTUiBkb21haW4iLiAgVGhlIGRlZmluaXRpb24gYWJvdmUgaXMgbm90IHRoZSBz YW1lIGFzIHdoYXQgcmZjODQwMiBzYXlzIChpbiDCpzIpLiAgRWFzeSBmaXg6IHNpbXBseSBwdXQg YSByZWZlcmVuY2UgdG8NCnJmYzg0MDIgbmV4dCB0byB0aGUgZmlyc3QgbWVudGlvbiBvZiAiU1Ig ZG9tYWluIiwgYW5kIGRlbGV0ZSB0aGF0IGxhc3Qgc2VudGVuY2UuDQoNCjE4NiAyLiAgQkdQLUxT IEV4dGVuc2lvbnMgZm9yIFNlZ21lbnQgUm91dGluZw0KDQoxODggICBUaGlzIGRvY3VtZW50IGRl ZmluZXMgU1IgZXh0ZW5zaW9ucyB0byBCR1AtTFMgYW5kIHNwZWNpZmllcyB0aGUgVExWcw0KMTg5 ICAgYW5kIHN1Yi1UTFZzIGZvciBhZHZlcnRpc2luZyBTUiBpbmZvcm1hdGlvbiB3aXRoaW4gdGhl IEJHUC1MUw0KMTkwICAgQXR0cmlidXRlLiAgU2VjdGlvbiAyLjQgYW5kIFNlY3Rpb24gMi41IGls bHVzdHJhdGVzIHRoZSBlcXVpdmFsZW50DQoxOTEgICBUTFZzIGFuZCBzdWItVExWcyBpbiBJUy1J UywgT1NQRnYyIGFuZCBPU1BGdjMgcHJvdG9jb2xzLg0KDQpbbml0XSAiaWxsdXN0cmF0ZXMiIHNv dW5kcyBsaWtlIGdpdmluZyBleGFtcGxlcyBvZiBlcXVpdmFsZW50IFRMVnMuICBCdXQgSSB0aGlu ayB0aGF0IHRoZSB0YWJsZXMgZG9uJ3Qgc2hvdyBleGFtcGxlcywgdGhleSBzaG93L3BvaW50IHRv IHRoZSBjb3JyZXNwb25kaW5nIFRMVnMuICBQZXJoYXBzIHVzZSBhIGRpZmZlcmVudCB3b3JkLi4u DQoNCg0KLi4uDQoyMDAgICBTb21lIG9mIHRoZSBUTFZzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dCBjb250YWluIGZpZWxkcyAoZS5nLiBmbGFncykNCjIwMSAgIHdob3NlIHNlbWFudGljcyBuZWVk IHRvIGJlIGludGVycHJldGVkIGFjY29yZGluZ2x5IHRvIHRoZSByZXNwZWN0aXZlDQoyMDIgICB1 bmRlcmx5aW5nIElTLUlTLCBPU1BGdjIgb3IgT1NQRnYzIHByb3RvY29sLiAgVGhlIHJlY2VpdmVy IG9mIHRoZQ0KMjAzICAgQkdQLUxTIHVwZGF0ZSBmb3IgYW55IG9mIHRoZSBOTFJJcyBNVVNUIGNo ZWNrIHRoZSBQcm90b2NvbC1JRCBvZiB0aGUNCjIwNCAgIE5MUkkgYW5kIHJlZmVyIHRvIHRoZSB1 bmRlcmx5aW5nIHByb3RvY29sIHNwZWNpZmljYXRpb24gaW4gb3JkZXIgdG8NCjIwNSAgIHBhcnNl IHN1Y2ggZmllbGRzLiAgVGhlIGluZGl2aWR1YWwgZmllbGQgZGVzY3JpcHRpb25zIGluIHRoZSBz dWItDQoyMDYgICBzZWN0aW9ucyBiZWxvdyBwb2ludCB0byB0aGUgcmVsZXZhbnQgdW5kZXJseWlu ZyBwcm90b2NvbA0KMjA3ICAgc3BlY2lmaWNhdGlvbnMgZm9yIHN1Y2ggZmllbGRzLg0KDQpbbWFq b3JdICJUaGUgcmVjZWl2ZXIgb2YgdGhlIEJHUC1MUyB1cGRhdGUgZm9yIGFueSBvZiB0aGUgTkxS SXMgTVVTVCBjaGVjayB0aGUgUHJvdG9jb2wtSUQgb2YgdGhlIE5MUkkgYW5kIHJlZmVyIHRvIHRo ZSB1bmRlcmx5aW5nIHByb3RvY29sIHNwZWNpZmljYXRpb24gaW4gb3JkZXIgdG8gcGFyc2Ugc3Vj aCBmaWVsZHMuIiAgVGhpcyB0ZXh0IGlzIGEgZ2VuZXJhbCBzdGF0ZW1lbnQgKCJmb3IgYW55IG9m IHRoZSBOTFJJcyIpIHRoYXQgc2VlbXMgdG8gd2FudCB0byBVcGRhdGUgcmZjNzc1Miwgd2hlcmUg UHJvdG9jb2wtSUQgaXMgZGVmaW5lZC4uLmJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgaXMgdGhlIGlu dGVudCwgcmlnaHQ/ICBOb3RlIHRoYXQgcmZjNzc1MiBkb2Vzbid0IGV4cGxpY2l0bHkgbWFuZGF0 ZSB0aGF0IHRoZSAicmVjZWl2ZXIuLi5yZWZlciB0byB0aGUgdW5kZXJseWluZyBwcm90b2NvbCBz cGVjaWZpY2F0aW9uIiAtLSBpdCBqdXN0IGltcGxpZXMgaXQgd2hlbiB0YWxraW5nIGFib3V0IHRo ZSBPcGFxdWUgVExWcy4NCg0KSU9XLCB0aGlzIHNlZW1zIGxpa2UgYSBzaWduaWZpY2FudCBjaGFu Z2UgYXMgcmVsYXRlZCB0byBvdGhlciBCR1AtTFMgc3BlY3MuDQoNCk5vdGUgYWxzbyB0aGF0IMKn NSAoTWFuYWdlYWJpbGl0eSBDb25zaWRlcmF0aW9ucykgaGFzIHRoZSBmb2xsb3dpbmcgdGV4dCwg d2hpY2ggSSB0aGluayBpcyBpbiBjb250cmFkaWN0aW9uIG9mIHRoZSBvbmUgYWJvdmU6DQoNCi4u Lg0KICAgICAgICAgICAgICAgICAgICAgICAuLi4gICAgICAgICAgICAgICAgVGhlIHNlbWFudGlj IG9yIGNvbnRlbnQNCiAgIGNoZWNraW5nIGZvciB0aGUgVExWcyBzcGVjaWZpZWQgaW4gdGhpcyBk b2N1bWVudCBhbmQgdGhlaXINCiAgIGFzc29jaWF0aW9uIHdpdGggdGhlIEJHUC1MUyBOTFJJIHR5 cGVzIG9yIHRoZWlyIEJHUC1MUyBBdHRyaWJ1dGUgaXMNCiAgIGxlZnQgdG8gdGhlIGNvbnN1bWVy IG9mIHRoZSBCR1AtTFMgaW5mb3JtYXRpb24gKGUuZy4gYW4gYXBwbGljYXRpb24NCiAgIG9yIGEg Y29udHJvbGxlcikgYW5kIG5vdCB0aGUgQkdQIHByb3RvY29sLg0KDQogICAuLi4gICAgICAgICAg ICAgICBUaGUgaGFuZGxpbmcgb2Ygc2VtYW50aWMgb3IgY29udGVudCBlcnJvcnMgYnkgdGhlDQog ICBjb25zdW1lciB3b3VsZCBiZSBkaWN0YXRlZCBieSB0aGUgbmF0dXJlIG9mIGl0cyBhcHBsaWNh dGlvbiB1c2FnZSBhbmQNCiAgIGhlbmNlIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudC4NCg0KMjA5IDIuMS4gIE5vZGUgQXR0cmlidXRlcyBUTFZzDQoNCjIxMSAgIFRoZSBmb2xs b3dpbmcgTm9kZSBBdHRyaWJ1dGUgVExWcyBhcmUgZGVmaW5lZDoNCg0KMjEzICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoyMTQgICAg ICAgICAgICAgIHwgRGVzY3JpcHRpb24gICAgIHwgTGVuZ3RoICAgfCAgICAgICBTZWN0aW9uIHwN CjIxNSAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tKw0KMjE2ICAgICAgICAgICAgICB8IFNJRC9MYWJlbCAgICAgICB8IHZhcmlhYmxlIHwg U2VjdGlvbiAyLjEuMSB8DQoyMTcgICAgICAgICAgICAgIHwgU1IgQ2FwYWJpbGl0aWVzIHwgdmFy aWFibGUgfCBTZWN0aW9uIDIuMS4yIHwNCjIxOCAgICAgICAgICAgICAgfCBTUiBBbGdvcml0aG0g ICAgfCB2YXJpYWJsZSB8IFNlY3Rpb24gMi4xLjMgfA0KMjE5ICAgICAgICAgICAgICB8IFNSIExv Y2FsIEJsb2NrICB8IHZhcmlhYmxlIHwgU2VjdGlvbiAyLjEuNCB8DQoyMjAgICAgICAgICAgICAg IHwgU1JNUyBQcmVmZXJlbmNlIHwgdmFyaWFibGUgfCBTZWN0aW9uIDIuMS41IHwNCjIyMSAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K DQoyMjMgICAgICAgICAgICAgICAgICAgICAgIFRhYmxlIDE6IE5vZGUgQXR0cmlidXRlIFRMVnMN Cg0KW21pbm9yXSBJdCB3b3VsZCBiZSBuaWNlIGlmIHRoZSB0YWJsZSBhbHNvIGNvbnRhaW5lZCB0 aGUgVExWIFR5cGUuICBUaGlzIGNvbW1lbnQgYXBwbGllcyB0byBvdGhlciBzaW1pbGFyIHRhYmxl cy4NCg0KW21pbm9yXSDCpzIuMS4yLzIuMS4zIHVzZSBhICItIiBpbiB0aGUgbmFtZSBvZiB0aGUg VExWLiAgUGxlYXNlIGJlIGNvbnNpc3RlbnQgYXMgYm90aCB2ZXJzaW9ucyBhcmUgdXNlZCB0aHJv dWdob3V0IHRoZSBkb2N1bWVudC4NCg0KW25pdF0gWWVzLCB0aGUgbGVuZ3RoIGlzIHZhcmlhYmxl LCBidXQgaW4gc29tZSBjYXNlcyB0aGUgcG9zc2libGUgdmFsdWVzIGFyZSBrbm93bi4gIEZvciBl eGFtcGxlLCB0aGUgbGVuZ3RoIG9mIHRoZSBTSUQvTGFiZWwgc3ViLVRMViBjYW4gb25seSBiZSAz IG9yIDQuICBDb25zaWRlciBpbmRpY2F0aW5nIHRoYXQuICBPVE9ILCBJIGRvbid0IHNlZSB3aHkg aW5kaWNhdGluZyB0aGUgTGVuZ3RoIGlzIHNpZ25pZmljYW50IGF0IHRoaXMgcG9pbnQgLS0gSU9X LCBJIHdvdWxkIGV2ZW4gc3VnZ2VzdCByZW1vdmluZyB0aGF0IGNvbHVtbi4NCg0KMjI1ICAgVGhl c2UgVExWcyBjYW4gT05MWSBiZSBhZGRlZCB0byB0aGUgQkdQLUxTIEF0dHJpYnV0ZSBhc3NvY2lh dGVkIHdpdGgNCjIyNiAgIHRoZSBOb2RlIE5MUkkgdGhhdCBvcmlnaW5hdGVzIHRoZSBjb3JyZXNw b25kaW5nIHVuZGVybHlpbmcgSUdQIFRMVi8NCjIyNyAgIHN1Yi1UTFYgZGVzY3JpYmVkIGJlbG93 Lg0KDQpbbWlub3JdICJ0aGUgTm9kZSBOTFJJIHRoYXQgb3JpZ2luYXRlcyB0aGUgY29ycmVzcG9u ZGluZyB1bmRlcmx5aW5nIElHUC4uLiINCiBUaGUgTm9kZSBOTFJJIGRvZXNuJ3Qgb3JpZ2luYXRl IGFueXRoaW5nLi4uaXQgZGVzY3JpYmVzIHRoZSBJR1Agbm9kZSB0aGF0IG9yaWdpbmF0ZXMgc29t ZXRoaW5nLi4uICBQbGVhc2UgYmUgc3BlY2lmaWMuDQoNClttYWpvcl0gVGhlIHRleHQgYWJvdmUg c291bmRzIGFzIGlmIHlvdSB3YW50IHRvIG1hbmRhdGUgc29tZXRoaW5nLi4uDQpXcml0aW5nICJP TkxZIiBpbiBjYXBzIGRvZXNuJ3QgaGF2ZSBhIE5vcm1hdGl2ZSBlZmZlY3QuICBTaG91bGQgdGhl cmUgYmUgYSAiTVVTVCIgc29tZXdoZXJlPyAgT3IgcGVyaGFwcyBzb2Z0ZW4gYSBsaXR0bGU6IHMv Y2FuIE9OTFkvc2hvdWxkIG9ubHkNCg0KVGhlIG5leHQgcXVlc3Rpb24gaXM6IHdoYXQgaWYgdGhl eSBhcmUgYWRkZWQgc29tZXdoZXJlIGVsc2U/ICBUaGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgYSB3 YXkgZm9yIHRoZSByZWNlaXZlciB0byBrbm93IGlmIHRoZSBUTFZzIGFyZSBhc3NvY2lhdGVkIHdp dGggdGhlIGNvcnJlY3QgTm9kZSBOTFJJLi4uICBJJ20gZ3Vlc3NpbmcgdGhhdCBhbGwgdGhlIHJl Y2VpdmVyIGNhbiBkbyBpcyBhc3N1bWUgdGhhdCB0aGUgVExWIGlzIHJlZmVycmluZyB0byB0aGUg cmlnaHQgbm9kZS4uLg0KDQo+RnJvbSB0aGUgdGV4dCwgSSdtIGFzc3VtaW5nIHRoYXQgdGhlIHVz ZSBpcyBpbnRlbmRlZCB0byBiZSBsaW1pdGVkIHRvIA0KPnRoZQ0KTm9kZSBOTFJJLiAgVW5mb3J0 dW5hdGVseSwgcmZjNzc1MiBkb2Vzbid0IHNwZWNpZnkgYWN0aW9ucyB0byBiZSB0YWtlbiBpZiB0 aGF0IGlzIG5vdCB0aGUgY2FzZS4NCg0KVGhpcyBjb21tZW50IGFwcGxpZXMgdG8gb3RoZXIgcGxh Y2VzIHdoZXJlIHRoZSAiT05MWSBiZSBhZGRlZCIgcGhyYXNlIGV4aXN0cy4NCg0KDQoyMjkgMi4x LjEuICBTSUQvTGFiZWwgU3ViLVRMVg0KDQoyMzEgICBUaGUgU0lEL0xhYmVsIFRMViBpcyB1c2Vk IGFzIHN1Yi1UTFYgYnkgdGhlIFNSLUNhcGFiaWxpdGllcw0KMjMyICAgKFNlY3Rpb24gMi4xLjIp IGFuZCBTUkxCIChTZWN0aW9uIDIuMS40KSBUTFZzIGFuZCBoYXMgdGhlIGZvbGxvd2luZw0KMjMz ICAgZm9ybWF0Og0KDQpbbml0XSBzL3VzZWQgYXMgc3ViLVRMVi91c2VkIGFzIGEgc3ViLVRMVg0K DQpbbWlub3JdIFRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgdGhhdCBTUkxCIGlzIHVzZWQgaW4gdGhp cyBkb2N1bWVudCwgcGxlYXNlIHVzZSB0aGUgZXh0ZW5kZWQgdmVyc2lvbiBoZXJlOiAgcy9TUkxC L1NSIExvY2FsIEJsb2NrIChTUkxCKQ0KDQouLi4NCjI0NSAgICAgIFR5cGU6IFRCRCwgc2VlIFNl Y3Rpb24gNC4NCg0KW21pbm9yXSBUaGUgY29kZSBwb2ludHMgaGF2ZSBhbHJlYWR5IGJlZW4gYXNz aWduZWQgKGVhcmx5IGFsbG9jYXRpb24pLg0KUGxlYXNlIGNoYW5nZSAiVEJEIiBmb3IgdGhlIGFj dHVhbCB2YWx1ZXMuDQoNCjI0NyAgICAgIExlbmd0aDogVmFyaWFibGUsIDMgb3IgNC4NCg0KW25p dF0gVGhlIExlbmd0aCBpcyByZWFsbHkgbm90IHZhcmlhYmxlLi4uaXQncyAzIG9yIDQuDQoNCi4u Lg0KMjU0ICAgICAgVGhlIHJlY2VpdmluZyByb3V0ZXIgTVVTVCBpZ25vcmUgdGhlIFNJRC9MYWJl bCBzdWItVExWIGlmIHRoZQ0KMjU1ICAgICAgbGVuZ3RoIGlzIG90aGVyIHRoZW4gMyBvciA0Lg0K DQpbbWFqb3JdIElmIHRoZSBzdWItVExWIGlzIGlnbm9yZWQsIHRoZSBpbmZvcm1hdGlvbiBpbiB0 aGUgU1ItQ2FwYWJpbGl0aWVzIG9yIFNSIExvY2FsIEJsb2NrIFRMVnMgd2lsbCBiZSBpbmNvbXBs ZXRlIChhdCBiZXN0KS4gIFdoYXQgaXMgdGhlIHBvdGVudGlhbCBpbXBhY3Qgb2YgdGhhdD8gIElz IHRoZSByZWNlaXZlZCBpbmZvcm1hdGlvbiBzdGlsbCB1c2VmdWw/ICBTaG91bGQgb3RoZXIgYWN0 aW9ucyBiZSB0YWtlbj8NCg0KMjU3IDIuMS4yLiAgU1ItQ2FwYWJpbGl0aWVzIFRMVg0KDQoyNTkg ICBUaGUgU1ItQ2FwYWJpbGl0aWVzIFRMViBpcyB1c2VkIGluIG9yZGVyIHRvIGFkdmVydGlzZSB0 aGUgbm9kZSdzIFNSDQoyNjAgICBDYXBhYmlsaXRpZXMgaW5jbHVkaW5nIGl0cyBTZWdtZW50IFJv dXRpbmcgR2xvYmFsIEJhc2UgKFNSR0IpDQoyNjEgICByYW5nZShzKS4gIEluIHRoZSBjYXNlIG9m IElTLUlTLCB0aGUgY2FwYWJpbGl0aWVzIGFsc28gaW5jbHVkZSB0aGUNCjI2MiAgIElQdjQgYW5k IElQdjYgc3VwcG9ydCBmb3IgU1ItTVBMUyBmb3J3YXJkaW5nIHBsYW5lLiAgVGhpcyBpbmZvcm1h dGlvbg0KMjYzICAgaXMgZGVyaXZlZCBmcm9tIHRoZSBwcm90b2NvbCBzcGVjaWZpYyBhZHZlcnRp c2VtZW50cy4NCg0KW25pdF0gcy9zdXBwb3J0IGZvciBTUi1NUExTIGZvcndhcmRpbmcgcGxhbmUv c3VwcG9ydCBmb3IgdGhlIFNSLU1QTFMgZm9yd2FyZGluZyBwbGFuZQ0KDQoyNjUgICBvICBJUy1J UywgYXMgZGVmaW5lZCBieSB0aGUgU1ItQ2FwYWJpbGl0aWVzIHN1Yi1UTFYgaW4NCjI2NiAgICAg IFtJLUQuaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zXS4NCg0KMjY4ICAgbyAg T1NQRnYyL09TUEZ2MywgYXMgZGVmaW5lZCBieSB0aGUgU0lEL0xhYmVsIFJhbmdlIFRMViBpbg0K MjY5ICAgICAgW0ktRC5pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNdIGFuZA0K MjcwICAgICAgW0ktRC5pZXRmLW9zcGYtb3NwZnYzLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25z XS4NCg0KW21pbm9yXSBUaGUgdGV4dCBhYm92ZSwgcG9pbnRpbmcgYXQgdGhlIGluZGl2aWR1YWwg SUdQIHNwZWNzIGlzIHByZXNlbnQgaW4gbWFueSBvZiB0aGUgZGVzY3JpcHRpb25zIGZvciB0aGUg VExWcywgYnV0IG5vdCBhbGwuICBTZWN0aW9ucyAyLjQvMi41IGhhdmUgdGFibGVzIHRoYXQgYWxz byBwb2ludCBhdCB0aGUgZXF1aXZhbGVudCBUTFZzLiAgSSdtIGxvb2tpbmcgZm9yDQpjb25zaXN0 ZW5jeTogZWl0aGVyIGluZGljYXRlIGluIGVhY2ggc2VjdGlvbiB3aGVyZSB0aGUgaW5mb3JtYXRp b24gaXMgZGVyaXZlZCBmcm9tLCBvciBub3QuICBHaXZlbiB0aGF0IMKnMi40LzIuNSBhbHJlYWR5 IGhhdmUgYSBzdW1tYXJ5LCBJIHBlcnNvbmFsbHkgZmluZCB0aGUgaW5mb3JtYXRpb24gKGxpa2Ug dGhlIG9uZSBhYm92ZSkgaW4gdGhlIGluZGl2aWR1YWwgc2VjdGlvbnMgcmVkdW5kYW50LiAgSW5z dGVhZCBvZiB0aGUgc3RhdGVtZW50IGFib3ZlLCBJIHByZWZlciB5b3UgdG8gYmUgc3BlY2lmaWMg YWJvdXQgdGhlIHZhbHVlcyBkZXNjcmliZWQgYmVsb3cgLS0gZm9yIGV4YW1wbGUsIHdoZW4gZGVz Y3JpYmluZyB0aGUgUmFuZ2UgU2l6ZSBmaWVsZCBiZWxvdywgeW91IGNvdWxkIHNheSBzb21ldGhp bmcgbGlrZSB0aGlzOg0KDQpPTEQ+DQogICBSYW5nZSBTaXplOiAzIG9jdGV0IHZhbHVlIGluZGlj YXRpbmcgdGhlIG51bWJlciBvZiBsYWJlbHMgaW4NCiAgIHRoZSByYW5nZS4NCg0KTkVXPg0KICAg UmFuZ2UgU2l6ZTogMyBvY3RldCB2YWx1ZSBpbmRpY2F0aW5nIHRoZSBudW1iZXIgb2YgbGFiZWxz IGluDQogICB0aGUgcmFuZ2UuICBUaGUgdmFsdWUgYW5kIGNoYXJhY3RlcmlzdGljcyBvZiB0aGlz IGZpZWxkIGFyZSBkZXJpdmVkIGZyb20gdGhlIFJhbmdlIGZpZWxkIGluIHRoZSBTUi1DYXBhYmls aXRpZXMgc3ViLVRMViBpbiBbSS1ELmlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9u c10sIG9yIGZyb20gdGhlIFJhbmdlIFNpemUgZmllbGQgaW4gdGhlIFNJRC9MYWJlbCBSYW5nZSBU TFYgaW4gW0ktRC5pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNdIGFuZCBbSS1E LmlldGYtb3NwZi1vc3BmdjMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNdLg0KDQpOb3RlIHRo YXQgZG9pbmcgaXQgdGhpcyB3YXkgc2F2ZXMgeW91IHRoZSBuZWVkIHRvIGRlZmluZSB0aGUgY2hh cmFjdGVyaXN0aWNzIG9mIGVhY2ggZmllbGQgKGJlY2F1c2UgZXZlbiBpZiB0aGUgdmFsdWVzIGFy ZSBkZXJpdmVkLCB0aGUgVExWcyBoZXJlIGFyZSBuZXcpLg0KDQpUaGlzIGNvbW1lbnQgb2J2aW91 c2x5IGFwcGxpZXMgdG8gYWxsIHNpbWlsYXIgaW5zdGFuY2VzIGluIHRoZSBkb2N1bWVudC4NCg0K MjcyICAgVGhlIFNSIENhcGFiaWxpdGllcyBUTFYgaGFzIGZvbGxvd2luZyBmb3JtYXQ6DQoNCltu aXRdIHMvaGFzIGZvbGxvd2luZyBmb3JtYXQvaGFzIHRoZSBmb2xsb3dpbmcgZm9ybWF0DQoNCg0K Li4uDQoyOTAgICAgICBMZW5ndGg6IFZhcmlhYmxlLg0KDQpbbWFqb3JdIFllcywgaXQncyB2YXJp YWJsZSwgYnV0IGl0IGhhcyB0byBiZSBhdCBsZWFzdCAxMi4gIFdoYXQgc2hvdWxkIGEgcm91dGVy IGRvIGlmIHRoZSBsZW5ndGggaXMgPCAxMj8gIEFmdGVyIHRoYXQsIHRoZXJlIGFyZSBvbmx5IHNw ZWNpZmljIHZhbGlkDQpsZW5ndGhzOiAxMiwgMTMsIDE5LCAyMSwgZXRjLiAgV2hhdCBpZiB0aGUg bGVuZ3RoIGlzIG5vdCBvbmUgb2YgdGhvc2UgdmFsdWVzPw0KDQpJIGNvdWxkbid0IGZpbmQgZ3Vp ZGFuY2UgaW4gcmZjNzc1Mi4gIFRoZSBjbG9zZXN0IHN0YXRlbWVudCBpcyBmcm9tIMKnNi4yLjIg KEZhdWx0IE1hbmFnZW1lbnQpLCB3aGVyZSBvbmUgb2YgdGhlICJjaGVja3MgZm9yIGRldGVybWlu aW5nIGlmIGEgbWVzc2FnZSBpcyBtYWxmb3JtZWQuLi5Eb2VzIGFueSBmaXhlZC1sZW5ndGggVExW IGNvcnJlc3BvbmQgdG8gdGhlIFRMViBMZW5ndGggZmllbGQgaW4gdGhpcyBkb2N1bWVudD8iICBU aGlzIFRMViBpcyBub3QgZml4ZWQtbGVuZ3RoLCBidXQgdGhlIHBvc3NpYmlsaXRpZXMgYXJlIGZp bml0ZS4NCg0KTm90ZSB0aGF0IHJmYzc3NTIgc2F5cyB0aGF0IGlmIHRoZSBsZW5ndGggaXMgbm90 IHRoZSBleHBlY3RlZCBvbmUsIHRoZW4gdGhlIHdob2xlIEJHUC1MUyBhdHRyaWJ1dGUgaXMgZGlz Y2FyZGVkLiAgRm9yIHRoaXMgc3BlY2lmaWMgY2FzZSwgaXQgbWVhbnMgdGhhdCB0aGUgY29udHJv bGxlciB3b3VsZG4ndCBoYXZlIGNvbXBsZXRlIGtub3dsZWRnZSBvZiB0aGUgbmV0d29yaywgZXZl biBpZiB0aGUgaW5mb3JtYXRpb24gZGVyaXZlZCBmcm9tIHRoZSBJR1AgaXMgY29ycmVjdC4uLg0K DQpUaGlzIGNvbW1lbnQgYXBwbGllcyB0byBvdGhlciBzaW1pbGFyIGluc3RhbmNlcy4NCg0KMjky ICAgICAgRmxhZ3M6IDEgb2N0ZXQgb2YgZmxhZ3MgYXMgZGVmaW5lZCBpbg0KMjkzICAgICAgW0kt RC5pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNdLg0KDQpbbWFqb3JdIFdoZW4g dGhlIEJHUC1MUyBpbmZvcm1hdGlvbiBjb21lcyBmcm9tIE9TUEYsIGhvdyBzaG91bGQgdGhlIGZs YWdzIGJlIGludGVycHJldGVkPyAgVGhlcmUgaXMgbm8gaW5kaWNhdGlvbiBpbiB0aGUgY29ycmVz cG9uZGluZyBPU1BGIGRyYWZ0cyBvZg0KIklQdjQgYW5kIElQdjYgc3VwcG9ydCBmb3IgU1ItTVBM UyIgLS0gc2hvdWxkIHRoZSBiaXRzIGFsd2F5cyBiZSB1bnNldD8NCg0KDQouLi4NCjMwMCAgICAg ICAgIFJhbmdlIFNpemU6IDMgb2N0ZXQgdmFsdWUgaW5kaWNhdGluZyB0aGUgbnVtYmVyIG9mIGxh YmVscyBpbg0KMzAxICAgICAgICAgdGhlIHJhbmdlLg0KDQpbbml0XSBzL2xhYmVscy9sYWJlbHMg b3IgU0lEcw0KDQpbbWFqb3JdIFdoYXQgbnVtYmVycyBhcmUgdmFsaWQgaW4gdGhlIFJhbmdlIFNp emUgZmllbGQ/ICBDYW4gaXQgYmUgMD8gIFRha2UgYSBsb29rIGFib3ZlIGF0IG15IGNvbW1lbnRz IGFib3V0IGRlcml2ZWQgdmFsdWVzLg0KDQozMDMgICAgICAgICBTSUQvTGFiZWwgc3ViLVRMViAo YXMgZGVmaW5lZCBpbiBTZWN0aW9uIDIuMS4xKSB3aGljaCBlbmNvZGVzDQozMDQgICAgICAgICB0 aGUgZmlyc3QgbGFiZWwgaW4gdGhlIHJhbmdlLg0KDQpbbml0XSBzL2ZpcnN0IGxhYmVsL2ZpcnN0 IGxhYmVsIG9yIFNJRA0KDQoNCi4uLg0KMzM5IDIuMS40LiAgU1IgTG9jYWwgQmxvY2sgVExWDQou Li4NCjM4MCAgICAgIEZsYWdzOiAxIG9jdGV0IG9mIGZsYWdzLiAgTm9uZSBhcmUgZGVmaW5lZCBh dCB0aGlzIHN0YWdlLg0KDQpbbWFqb3JdIE9ubHkgdGhlIGNvcnJlc3BvbmRpbmcgSVNJUyBzdWIt VExWIGhhcyBGbGFncyBkZWZpbmVkIC0tIGFuZCBJIHJlYWxpemUgdGhhdCB0aGUgdGV4dCBhYm92 ZSBpcyB0aGUgc2FtZSBhcyBpbiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVu c2lvbnMuICBJIHRoaW5rIHlvdSByZWFsbHkgZG9uJ3Qgd2FudCB0aGlzIGZpZWxkIHRvIGV2b2x2 ZSBpbmRlcGVuZGVudGx5LiAgSU9XLCBwbGVhc2UgdXNlIGEgZGVzY3JpcHRpb24gbGlrZSB0aGUg eW91IHVzZWQgZm9yIHRoZSBGbGFncyBpbiB0aGUgU1ItQ2FwYWJpbGl0aWVzIFRMVi4NCg0KDQou Li4NCjM5MyAyLjEuNS4gIFNSTVMgUHJlZmVyZW5jZSBUTFYNCi4uLg0KNDI3ICAgVGhlIHVzZSBv ZiB0aGUgU1JNUyBQcmVmZXJlbmNlIFRMViBpcyBkZWZpbmVkIGluDQo0MjggICBbSS1ELmlldGYt aXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc10sDQo0MjkgICBbSS1ELmlldGYtb3NwZi1z ZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc10gYW5kDQo0MzAgICBbSS1ELmlldGYtb3NwZi1vc3Bm djMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNdLg0KDQpbbWFqb3JdIFRoaXMgZG9jdW1lbnQg b25seSBkZWZpbmVzIGhvdyB0byBjYXJyeSBpbmZvcm1hdGlvbiBpbiBCR1AtTFMsIG5vdCB3aGF0 IHRvIGRvIHdpdGggaXQuICBJT1csIEkgdGhpbmsgdGhhdCB0aGUgbGFzdCBwYXJhZ3JhcGggaXMg bm90IG5lZWRlZCwgaXQgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuLi4NCg0KNDMy IDIuMi4gIExpbmsgQXR0cmlidXRlIFRMVnMNCg0KNDM0ICAgVGhlIGZvbGxvd2luZyBMaW5rIEF0 dHJpYnV0ZSBUTFZzIGFyZSBhcmUgZGVmaW5lZDoNCg0KNDM2ICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQo0Mzcg ICB8IERlc2NyaXB0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBMZW5ndGggfCAg ICAgICBTZWN0aW9uIHwNCjQzOCAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KNDM5ICAgfCBBZGphY2VuY3kgU2Vn bWVudCBJZGVudGlmaWVyIChBZGotU0lEKSB8IHZhcmlhYmxlIHwgU2VjdGlvbiAyLjIuMSB8DQo0 NDAgICB8IFRMViAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICAgICAgIHwNCjQ0MSAgIHwgTEFOIEFkamFjZW5jeSBTZWdtZW50IElkZW50aWZp ZXIgKEFkai0gfCB2YXJpYWJsZSB8IFNlY3Rpb24gMi4yLjIgfA0KNDQyICAgfCBTSUQpIFRMViAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICB8 DQo0NDMgICB8IEwyIEJ1bmRsZSBNZW1iZXIgVExWICAgICAgICAgICAgICAgICAgIHwgdmFyaWFi bGUgfCBTZWN0aW9uIDIuMi4zIHwNCjQ0NCAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KDQo0NDYgICAgICAgICAg ICAgICAgICAgICAgIFRhYmxlIDI6IExpbmsgQXR0cmlidXRlIFRMVnMNCg0KW21pbm9yXSBUaGUg bmFtZXMgdXNlZCBhYm92ZSBkb24ndCBtYXRjaCB0aGUgbmFtZXMgdXNlZCBpbiB0aGUgc2VjdGlv bnMgYmVsb3cuDQoNCi4uLg0KNDUyICAgRm9yIGEgTEFOLCBub3JtYWxseSBhIG5vZGUgb25seSBh bm5vdW5jZXMgaXRzIGFkamFjZW5jeSB0byB0aGUgSVMtSVMNCjQ1MyAgIHBzZXVkby1ub2RlIChv ciB0aGUgZXF1aXZhbGVudCBPU1BGIERlc2lnbmF0ZWQgYW5kIEJhY2t1cCBEZXNpZ25hdGVkDQo0 NTQgICBSb3V0ZXJzKVtJLUQuaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zXS4g IFRoZSBMQU4NCjQ1NSAgIEFkamFjZW5jeSBTZWdtZW50IFRMViBhbGxvd3MgYSBub2RlIHRvIGFu bm91bmNlIGFkamFjZW5jaWVzIHRvIGFsbA0KNDU2ICAgb3RoZXIgbm9kZXMgYXR0YWNoZWQgdG8g dGhlIExBTiBpbiBhIHNpbmdsZSBpbnN0YW5jZSBvZiB0aGUgQkdQLUxTDQo0NTcgICBMaW5rIE5M UkkuICBXaXRob3V0IHRoaXMgVExWLCB0aGUgY29ycmVzcG9uZGluZyBCR1AtTFMgbGluayBOTFJJ DQo0NTggICB3b3VsZCBuZWVkIHRvIGJlIG9yaWdpbmF0ZWQgZm9yIGVhY2ggYWRkaXRpb25hbCBh ZGphY2VuY3kgaW4gb3JkZXIgdG8NCjQ1OSAgIGFkdmVydGlzZSB0aGUgU1IgVExWcyBmb3IgdGhl c2UgbmVpZ2hib3IgYWRqYWNlbmNpZXMuDQoNClttaW5vcl0gVGhpcyBwYXJhZ3JhcGggbWF5YmUg Zml0cyBiZXR0ZXIgaW4gwqcyLjIuMi4NCg0KDQo0NjEgMi4yLjEuICBBZGphY2VuY3kgU0lEIFRM Vg0KLi4uDQo0ODIgICAgICBGbGFncy4gMSBvY3RldCBmaWVsZCBvZiBmb2xsb3dpbmcgZmxhZ3Mg YXMgZGVmaW5lZCBpbg0KNDgzICAgICAgW0ktRC5pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4 dGVuc2lvbnNdLA0KNDg0ICAgICAgW0ktRC5pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLWV4dGVu c2lvbnNdIGFuZA0KNDg1ICAgICAgW0ktRC5pZXRmLW9zcGYtb3NwZnYzLXNlZ21lbnQtcm91dGlu Zy1leHRlbnNpb25zXS4NCg0KTkVXPg0KICAgRmxhZ3M6IDEgb2N0ZXQgZmllbGQuICBUaGUgdmFs dWUgY29ycmVzcG9uZHMgdG8gdGhlIEZsYWdzIHNwZWNpZmllZCBmb3IgdGhlDQogICBBZGotU0lE IFN1Yi1UTFYgaW4gW0ktRC5pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNdLA0K ICAgW0ktRC5pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNdIG9yDQogICBbSS1E LmlldGYtb3NwZi1vc3BmdjMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNdLg0KDQo0ODcgICAg ICBXZWlnaHQ6IFdlaWdodCB1c2VkIGZvciBsb2FkLWJhbGFuY2luZyBwdXJwb3Nlcy4NCg0KW21p bm9yXSBTaW1pbGFyIHRvIHRoZSBhYm92ZSB0ZXh0Li4uDQoNCjQ4OSAgICAgIFJlc2VydmVkOiAy IG9jdGV0cyB0aGF0IFNIT1VMRCBiZSBzZXQgdG8gMCBhbmQgTVVTVCBiZSBpZ25vcmVkIG9uDQo0 OTAgICAgICByZWNlaXB0Lg0KDQo0OTIgICAgICBTSUQvSW5kZXgvTGFiZWw6IExhYmVsIG9yIGlu ZGV4IHZhbHVlIGRlcGVuZGluZyBvbiB0aGUgZmxhZ3MNCjQ5MyAgICAgIHNldHRpbmcgYXMgZGVm aW5lZCBpbiBbSS1ELmlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc10sDQo0OTQg ICAgICBbSS1ELmlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc10gYW5kDQo0OTUg ICAgICBbSS1ELmlldGYtb3NwZi1vc3BmdjMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNdLg0K DQpbbWlub3JdIFNpbWlsYXIgdGV4dCBoZXJlIHRvby4uLg0KDQoNCjQ5NyAyLjIuMi4gIExBTiBB ZGphY2VuY3kgU0lEIFRMVg0KLi4uDQpbbWFqb3JdIFRoZSBPU1BGIE5laWdoYm9yIElEIC8gSVMt SVMgU3lzdGVtLUlEIGZpZWxkIGlzIG5vdCBkZWZpbmVkLg0KDQoNCjU0MiAyLjIuMy4gIEwyIEJ1 bmRsZSBNZW1iZXINCg0KW25pdF0gcy9MMiBCdW5kbGUgTWVtYmVyL0wyIEJ1bmRsZSBNZW1iZXIg QXR0cmlidXRlIFRMVg0KDQo1NDQgICBUaGUgTDIgQnVuZGxlIE1lbWJlciBBdHRyaWJ1dGUgVExW IGlkZW50aWZpZXMgYW4gTDIgQnVuZGxlIE1lbWJlcg0KNTQ1ICAgbGluayB3aGljaCBpbiB0dXJu IGlzIGFzc29jaWF0ZWQgd2l0aCBhIHBhcmVudCBMMyBsaW5rLiAgVGhlIEwzIGxpbmsNCjU0NiAg IGlzIGRlc2NyaWJlZCBieSB0aGUgTGluayBOTFJJIGRlZmluZWQgaW4gW1JGQzc3NTJdIGFuZCB0 aGUgTDIgQnVuZGxlDQo1NDcgICBNZW1iZXIgQXR0cmlidXRlIFRMViBpcyBhc3NvY2lhdGVkIHdp dGggdGhlIExpbmsgTkxSSS4gIFRoZSBUTFYgTUFZDQo1NDggICBpbmNsdWRlIHN1Yi1UTFZzIHdo aWNoIGRlc2NyaWJlIGF0dHJpYnV0ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBidW5kbGUNCjU0OSAg IG1lbWJlci4gIFRoZSBpZGVudGlmaWVkIGJ1bmRsZSBtZW1iZXIgcmVwcmVzZW50cyBhIHVuaWRp cmVjdGlvbmFsDQo1NTAgICBwYXRoIGZyb20gdGhlIG9yaWdpbmF0aW5nIHJvdXRlciB0byB0aGUg bmVpZ2hib3Igc3BlY2lmaWVkIGluIHRoZQ0KNTUxICAgcGFyZW50IEwzIExpbmsuICBNdWx0aXBs ZSBMMiBCdW5kbGUgTWVtYmVyIEF0dHJpYnV0ZSBUTFZzIE1BWSBiZQ0KNTUyICAgYXNzb2NpYXRl ZCB3aXRoIGEgTGluayBOTFJJLg0KDQpbbWlub3JdICJpZGVudGlmaWVzIGFuIEwyIEJ1bmRsZSBN ZW1iZXIgbGluay4uLlRoZSBpZGVudGlmaWVkIGJ1bmRsZSBtZW1iZXIiLiAgQXJlIHdlIHRhbGtp bmcgYWJvdXQgYSBsaW5rIG9yIGp1c3QgdGhlIG1lbWJlcnM/DQoNCi4uLg0KNTc0ICAgICAgTDIg QnVuZGxlIE1lbWJlciBEZXNjcmlwdG9yOiBBIExpbmsgTG9jYWwgSWRlbnRpZmllciBhcyBkZWZp bmVkIGluDQo1NzUgICAgICBbUkZDNDIwMl0uDQoNClttYWpvcl0gRnJvbSB0aGUgdGV4dCwgaXQg bG9va3MgbGlrZSB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBzb21ldGhpbmcgdGhhdCBpcyBsZWFy bmVkIGZyb20gdGhlIElHUCwgd2hpY2ggaXMgdGhlbiBqdXN0IHRyYW5zcG9ydGVkIGJ5IEJHUC1M UyAoanVzdCBsaWtlIHRoZSByZXN0IG9mIHRoZSBUTFZzIGluIHRoaXMgZG9jdW1lbnQpLCBidXQg dGFibGUgNSBwb2ludHMgYXQgZHJhZnQtaWV0Zi1pc2lzLWwyYnVuZGxlcy4gIFdoeSBpcyBkcmFm dC1pZXRmLWlzaXMtbDJidW5kbGVzIG5vdCB1c2VkIHRvIGRlc2NyaWJlIHRoaXMgVExWPw0KDQpb bWFqb3JdIHJmYzQyMDIgaXMgbm90IElTLUlTLXNwZWNpZmljLiAgV2hhdCBhYm91dCBPU1BGPyAg SSBub3RlIHRoYXQNCnJmYzQyMDMgZGVmaW5lcyBPU1BGIGV4dGVuc2lvbnMgdGhhdCBpbmNsdWRl IHRoZSBMaW5rIExvY2FsIElkZW50aWZpZXIsIHNvIHRoaXMgY29uY2VwdCBpcyBub3QgZm9yZWln biB0byBpdC4NCg0KNTc3ICAgTGluayBhdHRyaWJ1dGVzIGZvciBMMiBCdW5kbGUgTWVtYmVyIExp bmtzIGFyZSBhZHZlcnRpc2VkIGFzIHN1Yi1UTFZzDQo1NzggICBvZiB0aGUgTDJCdW5kbGUgTWVt YmVyIEF0dHJpYnV0ZSBUTFYuICBUaGUgc3ViLVRMVnMgYXJlIGlkZW50aWNhbCB0bw0KNTc5ICAg ZXhpc3RpbmcgQkdQLUxTIFRMVnMgYXMgaWRlbnRpZmllZCBpbiB0aGUgdGFibGUgYmVsb3cuDQoN CltuaXRdIHMvTDJCdW5kbGUvTDIgQnVuZGxlDQoNCg0KLi4uDQo2MzMgMi4zLjEuICBQcmVmaXgt U0lEIFRMVg0KLi4uDQpbbWFqb3JdIGRyYWZ0LWlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0 ZW5zaW9ucyBhbHNvIGluY2x1ZGVzIHRoZSBNVC1JRCBpbiB0aGUgUHJlZml4IFNJRCBTdWItVExW LiAgSXMgdGhhdCBub3QgbmVlZGVkIGJ5IGEgY29udHJvbGxlcj8NCg0KNjkxIDIuMy4yLiAgUHJl Zml4IEF0dHJpYnV0ZSBGbGFncyBUTFYNCi4uLg0KNzExICAgICAgTGVuZ3RoOiB2YXJpYWJsZS4N Cg0KW21pbm9yXSBUaGUgbGVuZ3RoIG9mIHRoZSBmbGFncyBmaWVsZHMgaW4gcmZjNzc5NC9yZmM3 Njg0IGFyZSBib3RoIG9uZSBvY3RldCBsb25nLiAgQ2FuIHRoaXMgbGVuZ3RoIGJlIG1hZGUgZml4 ZWQ/DQoNClttYWpvcl0gSSBjb3VsZCBub3QgZmluZCBhIEZsYWdzIGZpZWxkIGZvciBPU1BGdjMg aW4gcmZjNTM0MC4NCg0KW21pbm9yXSBGcm9tIFRhYmxlIDcsIGl0IHNlZW1zIHRoYXQgdGhlIHJl ZmVyZW5jZSB0byByZmM4MzYyIHBvaW50cyB0byB0aGUgIlByZWZpeCBPcHRpb25zIEZpZWxkIiwg aXMgdGhhdCBjb3JyZWN0Pw0KDQo3MTMgICAgICBGbGFnczogYSB2YXJpYWJsZSBsZW5ndGggZmxh ZyBmaWVsZCAoYWNjb3JkaW5nIHRvIHRoZSBsZW5ndGgNCjcxNCAgICAgIGZpZWxkKS4gIEZsYWdz IGFyZSByb3V0aW5nIHByb3RvY29sIHNwZWNpZmljIGFuZCBhcmUgdG8gYmUgcGFyc2VkDQo3MTUg ICAgICBhcyBiZWxvdzoNCg0KNzE3ICAgICAgKiAgSVMtSVMgZmxhZ3MgYXJlIGRlZmluZWQgaW4g W1JGQzc3OTRdDQoNCjcxOSAgICAgICogIE9TUEZ2MiBmbGFncyBhcmUgZGVmaW5lZCBpbiBbUkZD NzY4NF0NCg0KNzIxICAgICAgKiAgT1NQRnYzIGZsYWdzIG1hcCB0byB0aGUgUHJlZml4IE9wdGlv bnMgZmllbGQgZGVmaW5lZCBpbg0KNzIyICAgICAgICAgW1JGQzc3OTRdIGFuZCBleHRlbmRlZCB2 aWEgW1JGQzgzNjJdDQoNCltuaXRdIFRoZSB0ZXh0IGF0IHRoZSB0b3Agb2YgdGhpcyBzZWN0aW9u IHJlZmVycyB0byByZmM1MzQwLi4uDQoNClttYWpvcl0gcmZjNzc5NCBvbmx5IHRhbGtzIGFib3V0 IElTLUlTLCBub3QgT1NQRnYzLg0KDQoNCjcyNCAyLjMuMy4gIFNvdXJjZSBSb3V0ZXIgSWRlbnRp ZmllciAoU291cmNlIFJvdXRlci1JRCkgVExWDQoNCjcyNiAgIFRoZSBTb3VyY2UgUm91dGVyLUlE IFRMViBjb250YWlucyB0aGUgSVB2NCBvciBJUHY2IFJvdXRlci1JRCBvZiB0aGUNCjcyNyAgIG9y aWdpbmF0b3Igb2YgdGhlIFByZWZpeC4gIEZvciBJUy1JUyBwcm90b2NvbCB0aGlzIGlzIGFzIGRl ZmluZWQgaW4NCjcyOCAgIFtSRkM3Nzk0XS4gIFRoZSBTb3VyY2UgUm91dGVyLUlEIFRMViBtYXkg YmUgdXNlZCB0byBjYXJyeSB0aGUgT1NQRg0KNzI5ICAgUm91dGVyLUlEIG9mIHRoZSBwcmVmaXgg b3JpZ2luYXRvci4NCg0KW21ham9yXSBSZWZlcmVuY2UgZm9yIE9TUEY/ICBPbmx5ICJtYXkiPz8N Cg0KW21ham9yXSByZmM3NzUyIGRlZmluZXMgdGhlIElHUCBSb3V0ZXItSUQgVExWIHRvIGNhcnJ5 IHRoZSBzYW1lIGluZm9ybWF0aW9uLiAgV2hhdCBpcyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4g dGhlc2UgdHdvIFRMVnM/ICBTaW5jZSB0aGUgSUdQIFJvdXRlci1JRCBUTFYgaXMgbWFuZGF0b3J5 LCBhcmUgdGhlcmUgY2FzZXMgd2hlcmUgdGhpcyBvbmUgbWF5IG5vdCBiZSBuZWVkZWQ/DQoNCg0K Li4uDQo3NDUgICAgICBMZW5ndGg6IDQgb3IgMTYuDQoNClttYWpvcl0gT1NQRiBhbHdheXMgdXNl cyBhIDMyLWJpdCBudW1iZXIuICBJT1csIHRoZSBsZW5ndGggaXMgZml4ZWQgZm9yIE9TUEYuDQoN Ci4uLg0KNzQ5IDIuMy40LiAgUmFuZ2UgVExWDQoNCjc1MSAgIFRoZSByYW5nZSBUTFYgaXMgdXNl ZCBpbiBvcmRlciB0byBhZHZlcnRpc2UgYSByYW5nZSBvZiBwcmVmaXgtdG8tU0lEDQo3NTIgICBt YXBwaW5ncyBhcyBwYXJ0IG9mIHRoZSBTZWdtZW50IFJvdXRpbmcgTWFwcGluZyBTZXJ2ZXIgZnVu Y3Rpb25hbGl0eQ0KNzUzICAgW0ktRC5pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWlu dGVyb3BdLCBhcyBkZWZpbmVkIGluIHRoZQ0KNzU0ICAgcmVzcGVjdGl2ZSB1bmRlcmx5aW5nIElH UCBTUiBleHRlbnNpb25zDQo3NTUgICBbSS1ELmlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0 ZW5zaW9uc10sDQo3NTYgICBbSS1ELmlldGYtb3NwZi1vc3BmdjMtc2VnbWVudC1yb3V0aW5nLWV4 dGVuc2lvbnNdIGFuZA0KNzU3ICAgW0ktRC5pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVu c2lvbnNdLiAgVGhlIFByZWZpeC1OTFJJIHRvIHdoaWNoDQo3NTggICB0aGUgUmFuZ2UgVExWIGlz IGF0dGFjaGVkIE1VU1QgYmUgYWR2ZXJ0aXNlZCBhcyBhIG5vbi1yb3V0aW5nIHByZWZpeA0KNzU5 ICAgd2hlcmUgbm8gSUdQIG1ldHJpYyBUTFYgKFRMViAxMDk1KSBpcyBhdHRhY2hlZC4NCg0KW21h am9yXSBXaGF0IGRvIHlvdSBtZWFuIGluIHRoZSBmaW5hbCBzZW50ZW5jZT8gIEl0IHNvdW5kcyBh cyBpZiB0aGUgSUdQIG1ldHJpYyBUTFYgYW5kIHRoZSBSYW5nZSBUTFYgYXJlIG11dHVhbGx5IGV4 Y2x1c2l2ZSBhbmQgc2hvdWxkIG5ldmVyIGJlIGFkdmVydGlzZWQgdG9nZXRoZXIuICBJcyB0aGF0 IGl0PyAgSWYgc28sIHdoYXQgc2hvdWxkIHRoZSByZWNlaXZlciBkbyBpZiB0aGV5IGFyZT8NCg0K DQo3NjEgICBUaGUgZm9ybWF0IG9mIHRoZSBSYW5nZSBUTFYgaXMgYXMgZm9sbG93czoNCg0KNzYz ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAg ICAgICAgIDMNCjc2NCAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCjc2NSAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo3NjYgICB8ICAgICAgICAg ICAgIFR5cGUgICAgICAgICAgICAgIHwgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgfA0K NzY3ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCjc2OCAgIHwgICAgIEZsYWdzICAgICB8IFJlc2VydmVkICAgICAgfCAg ICAgICAgICAgICBSYW5nZSBTaXplICAgICAgICB8DQo3NjkgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KNzcwICAgLy8g ICAgICAgICAgICAgICAgICAgICAgICAgIHN1Yi1UTFZzICAgICAgICAgICAgICAgICAgICAgICAg ICAgLy8NCjc3MSAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQoNCjc3MyAgIHdoZXJlOg0KDQpbbml0XSBUaGF0ICJ3aGVy ZSIgc2hvdWxkIGJlIGFmdGVyIHRoZSBGaWd1cmUgdGl0bGUuDQoNCjc3NSAgICAgICAgICAgICAg ICAgICAgICAgIEZpZ3VyZSAyOiBSYW5nZSBUTFYgZm9ybWF0DQoNCg0KLi4uDQpbbWlub3JdIEFz IHdpbGwgYWxsIHRoZSBvdGhlciBzZWN0aW9ucywgcGxlYXNlIGJlIGNvbnNpc3RlbnQgYW5kIGZv bGQgdGhlIHN1Yi1zZWN0aW9ucyBiZWxvdyBpbnRvIHRoZSBkZXNjcmlwdGlvbiBhYm92ZS4NCg0K ODA0IDIuMy40LjEuICBBZHZlcnRpc2VtZW50IFByb2NlZHVyZSBmb3IgT1NQRg0KDQo4MDYgICBU aGUgT1NQRnYyL09TUEZ2MyBFeHRlbmRlZCBQcmVmaXggUmFuZ2UgVExWIGlzIGVuY29kZWQgaW4g dGhlIFJhbmdlDQo4MDcgICBUTFYuICBUaGUgZmxhZ3Mgb2YgdGhlIFJhbmdlIFRMViBoYXZlIHRo ZSBzZW1hbnRpYyBtYXBwZWQgdG8gdGhlDQo4MDggICBkZWZpbml0aW9uIGluIFtJLUQuaWV0Zi1v c3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zXSBzZWN0aW9uIDQgb3INCjgwOSAgIFtJLUQu aWV0Zi1vc3BmLW9zcGZ2My1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc10gc2VjdGlvbiA0Lg0K DQo4MTEgICBUaGVuIHRoZSBwcmVmaXgtdG8tU0lEIG1hcHBpbmcgZnJvbSB0aGUgT1NQRiBQcmVm aXggU0lEIHN1Yi1UTFYgaXMNCjgxMiAgIGVuY29kZWQgdXNpbmcgdGhlIEJHUC1MUyBQcmVmaXgt U0lEIFRMViBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMi4zLjENCjgxMyAgIHdpdGggdGhlIGZsYWdz IHNldCBhY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb24gaW4NCjgxNCAgIFtJLUQuaWV0Zi1vc3Bm LXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zXSBzZWN0aW9uIDUgb3INCjgxNSAgIFtJLUQuaWV0 Zi1vc3BmLW9zcGZ2My1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uc10gc2VjdGlvbiA1Lg0KDQpb bWFqb3JdIFRoZSBFeHRlbmRlZCBQcmVmaXggUmFuZ2UgVExWIGNvbnRhaW5zIG90aGVyIGZpZWxk cyBub3QgcHJlc2VudA0KaGVyZTogQUYsIGZvciBpbnN0YW5jZS4gIFRoZSBsYXN0IHBhcmFncmFw aCBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IHRoZSBwcmVmaXggaW5mb3JtYXRpb24gd2lsbCBiZSBp biB0aGUgQkdQLUxTIFByZWZpeC1TSUQgVExWLCBidXQgdGhhdCBpbmZvcm1hdGlvbiBkb2Vzbid0 IGNvbWUgZnJvbSB0aGUgRXh0ZW5kZWQgUHJlZml4IFJhbmdlIFRMViAoYW5kIGl0IGRvZXNuJ3Qg aW5jbHVkZSB0aGUgQUYpLiAgV2hhdCBhbSBJIG1pc3Npbmc/DQoNClttYWpvcl0gVGhlIHRleHQg YWJvdmUgc2VlbXMgdG8gaW1wbHkgdGhhdCB0aGUgUmFuZ2UgVExWIGFuZCB0aGUgUHJlZml4LVNJ RCBUTFYgc2hvdWxkIGFsd2F5cyBiZSBpbmNsdWRlZCB0b2dldGhlci4gIElzIHRoYXQgdHJ1ZT8g IElmIHNvLCBwbGVhc2UgbWFrZSBpdCBtb3JlIGV4cGxpY2l0Lg0KDQo4MTcgMi4zLjQuMi4gIEFk dmVydGlzZW1lbnQgUHJvY2VkdXJlIGZvciBJUy1JUw0KDQo4MTkgICBUaGUgSVMtSVMgU0lEL0xh YmVsIEJpbmRpbmcgVExWLCB3aGVuIHVzZWQgdG8gc2lnbmFsIG1hcHBpbmcgc2VydmVyDQo4MjAg ICBsYWJlbCBiaW5kaW5ncywgaXMgZW5jb2RlZCBpbiB0aGUgUmFuZ2UgVExWLiAgVGhlIGZsYWdz IG9mIHRoZSBSYW5nZQ0KODIxICAgVExWIGhhdmUgdGhlIHNlbWF0aWMgbWFwcGVkIHRvIHRoZSBk ZWZpbml0aW9uIGluDQo4MjIgICBbSS1ELmlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5z aW9uc10gc2VjdGlvbiAyLjQuMS4NCg0KODI0ICAgVGhlbiB0aGUgcHJlZml4LXRvLVNJRCBtYXBw aW5ncyBmcm9tIHRoZSBJUy1JUyBQcmVmaXggU0lEIHN1Yi1UTFYgaXMNCjgyNSAgIGVuY29kZWQg dXNpbmcgdGhlIEJHUC1MUyBQcmVmaXgtU0lEIFRMViBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMi4z LjENCjgyNiAgIHdpdGggdGhlIGZsYWdzIHNldCBhY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb24g aW4NCjgyNyAgIFtJLUQuaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zXSBzZWN0 aW9uIDIuNC40LjEuDQoNClttYWpvcl0gU2FtZSBxdWVzdGlvbnMgKGFzIGFib3ZlKSByZWxhdGVk IHRvIHRoZSBvdGhlciBmaWVsZHMgaW4gdGhlIFNJRC9MYWJlbCBCaW5kaW5nIFRMViwgYW5kIHRo ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgUmFuZ2UgVExWIGFuZCB0aGUgUHJlZml4LVNJRCBU TFYuDQoNCg0KODI5IDIuNC4gIEVxdWl2YWxlbnQgSVMtSVMgU2VnbWVudCBSb3V0aW5nIFRMVnMv U3ViLVRMVnMgLi4uDQo4MzcgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsNCjgzOCAgIHwgRGVzY3JpcHRpb24gICAg ICAgICAgICAgICAgICAgICAgICAgICB8IExlbmd0aCAgIHwgSVMtSVMgVExWL3N1Yi0gfA0KODM5 ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfCBU TFYgICAgICAgICAgICB8DQo4NDAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsNCjg0MSAgIHwgU1IgQ2FwYWJpbGl0 aWVzICAgICAgICAgICAgICAgICAgICAgICB8IHZhcmlhYmxlIHwgMiBbMV0gICAgICAgICAgfA0K ODQyICAgfCBTUiBBbGdvcml0aG0gICAgICAgICAgICAgICAgICAgICAgICAgIHwgdmFyaWFibGUg fCAxOSBbMl0gICAgICAgICB8DQo4NDMgICB8IFNSIExvY2FsIEJsb2NrICAgICAgICAgICAgICAg ICAgICAgICAgfCB2YXJpYWJsZSB8IDIyIFszXSAgICAgICAgIHwNCjg0NCAgIHwgU1JNUyBQcmVm ZXJlbmNlICAgICAgICAgICAgICAgICAgICAgICB8IDEgICAgICAgIHwgMTkgWzRdICAgICAgICAg fA0KODQ1ICAgfCBBZGphY2VuY3kgU2VnbWVudCBJZGVudGlmaWVyIChBZGotICAgIHwgdmFyaWFi bGUgfCAzMSBbNV0gICAgICAgICB8DQo4NDYgICB8IFNJRCkgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCjg0NyAgIHwgTEFOIEFk amFjZW5jeSBTZWdtZW50IElkZW50aWZpZXIgICAgICB8IHZhcmlhYmxlIHwgMzIgWzZdICAgICAg ICAgfA0KODQ4ICAgfCAoTEFOLUFkai1TSUQpICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgfCAgICAgICAgICAgICAgICB8DQo4NDkgICB8IFByZWZpeCBTSUQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCB2YXJpYWJsZSB8IDMgWzddICAgICAgICAgIHwNCjg1MCAgIHwgUmFu Z2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHZhcmlhYmxlIHwgMTQ5IFs4XSAg ICAgICAgfA0KODUxICAgfCBTSUQvTGFiZWwgVExWICAgICAgICAgICAgICAgICAgICAgICAgIHwg dmFyaWFibGUgfCAxIFs5XSAgICAgICAgICB8DQo4NTIgICB8IFByZWZpeCBBdHRyaWJ1dGUgRmxh Z3MgICAgICAgICAgICAgICAgfCB2YXJpYWJsZSB8IDQgWzEwXSAgICAgICAgIHwNCjg1MyAgIHwg U291cmNlIFJvdXRlciBJRCAgICAgICAgICAgICAgICAgICAgICB8IHZhcmlhYmxlIHwgMTEvMTIg WzExXSAgICAgfA0KODU0ICAgfCBMMiBCdW5kbGUgTWVtYmVyIFRMViAgICAgICAgICAgICAgICAg IHwgdmFyaWFibGUgfCAyNSBbMTJdICAgICAgICB8DQo4NTUgICArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsNCg0KW21h am9yXSBJbnN0ZWFkIG9mIHVzaW5nIFVSSXMsIHBsZWFzZSBwdXQgYW4gZXhwbGljaXQgcG9pbnRl ciB0byB0aGUgUkZDL0lEIChhbmQgaWYgZGVzaXJlZCwgdGhlIHNlY3Rpb24pLi4uYW5kIG1ha2Ug c3VyZSB0aGF0IHRoZXJlIGFyZSBjb3JyZXNwb25kaW5nIFJlZmVyZW5jZXMuICBJZiBhIGRvY3Vt ZW50IGlzIHJlZmVyZW5jZWQgb25seSBpbiB0aGlzIHRhYmxlLCB0aGVuIHRoZSBSZWZlcmVuY2Ug Y2FuIGJlIEluZm9ybWF0aXZlLg0KDQpbbml0XSBGb3IgVGFibGVzIDUtNzogTm8gbmVlZCB0byB1 c2UgIlRMViIgaW4gdGhlIGRlc2NyaXB0aW9uLg0KDQo4NTcgICAgICAgICAgVGFibGUgNTogSVMt SVMgU2VnbWVudCBSb3V0aW5nIEV4dGVuc2lvbnMgVExWcy9TdWItVExWcw0KDQo4NTkgMi41LiAg RXF1aXZhbGVudCBPU1BGdjIvT1NQRnYzIFNlZ21lbnQgUm91dGluZyBUTFZzL1N1Yi1UTFZzIC4u Lg0KODg2ICAgICAgICAgIFRhYmxlIDY6IE9TUEYgU2VnbWVudCBSb3V0aW5nIEV4dGVuc2lvbnMg VExWcy9TdWItVExWcw0KDQpbbml0XSBzL09TUEYvT1NQRnYyDQoNClttaW5vcl0gVGhlIE9TUEYg dGFibGVzIGRvbid0IGluY2x1ZGUgdGhlIFNvdXJjZSBSb3V0ZXIgSUQgb3IgdGhlIEwyIEJ1bmRs ZSBNZW1iZXIgVExWcy4gIElzIHRoZXJlIGEgcmVhc29uIGZvciB0aGF0LCBvciBqdXN0IGFuIG92 ZXJzaWdodD8NCg0KLi4uDQo5MDggMy4gIEltcGxlbWVudGF0aW9uIFN0YXR1cw0KDQpbbml0XSBU aGlzIHNlY3Rpb24gc2F5cyBub3RoaW5nLiA6LSggICBBdCBsZWFzdCBhIHBvaW50ZXIgdG8NCmh0 dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncC1scy1z ZWdtZW50LXJvdXRpbmctZXh0LWltcGxlbWVudGF0aW9ucw0KbWlnaHQgYmUgbmljZS4gIE9SLCB5 b3UgY2FuIGp1c3QgcmVtb3ZlIGl0Lg0KDQoNCi4uLg0KOTQzIDQuICBJQU5BIENvbnNpZGVyYXRp b25zDQoNCjk0NSAgIFRoaXMgZG9jdW1lbnQgcmVxdWVzdHMgYXNzaWduaW5nIGNvZGUtcG9pbnRz IGZyb20gdGhlIHJlZ2lzdHJ5ICJCR1AtDQo5NDYgICBMUyBOb2RlIERlc2NyaXB0b3IsIExpbmsg RGVzY3JpcHRvciwgUHJlZml4IERlc2NyaXB0b3IsIGFuZCBBdHRyaWJ1dGUNCjk0NyAgIFRMVnMi IGJhc2VkIG9uIHRhYmxlIFRhYmxlIDguICBUaGUgY29sdW1uICJJUy1JUyBUTFYvU3ViLVRMViIg ZGVmaW5lZA0KOTQ4ICAgaW4gdGhlIHJlZ2lzdHJ5IGRvZXMgbm90IHJlcXVpcmUgYW55IHZhbHVl IGFuZCBzaG91bGQgYmUgbGVmdCBlbXB0eS4NCg0KW21ham9yXSBUaGUgZWFybHkgYWxsb2NhdGlv biBoYXMgYWxyZWFkeSBiZWVuIGRvbmUuLi5zbyB0aGlzIGRvY3VtZW50IGRvZXNuJ3QgcmVxdWVz dCBhc3NpZ25tZW50IGZyb20gSUFOQS4gIFBsZWFzZSB1cGRhdGUuDQoNCg0KLi4uDQo5NzcgNS4g IE1hbmFnZWFiaWxpdHkgQ29uc2lkZXJhdGlvbnMNCg0KOTc5ICAgVGhpcyBzZWN0aW9uIGlzIHN0 cnVjdHVyZWQgYXMgcmVjb21tZW5kZWQgaW4gW1JGQzU3MDZdLg0KDQo5ODEgICBUaGUgbmV3IHBy b3RvY29sIGV4dGVuc2lvbnMgaW50cm9kdWNlZCBpbiB0aGlzIGRvY3VtZW50IGF1Z21lbnQgdGhl DQo5ODIgICBleGlzdGluZyBJR1AgdG9wb2xvZ3kgaW5mb3JtYXRpb24gdGhhdCB3YXMgZGlzdHJp YnV0ZWQgdmlhIFtSRkM3NzUyXS4NCjk4MyAgIFByb2NlZHVyZXMgYW5kIHByb3RvY29sIGV4dGVu c2lvbnMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGRvIG5vdA0KOTg0ICAgYWZmZWN0IHRoZSBC R1AgcHJvdG9jb2wgb3BlcmF0aW9ucyBhbmQgbWFuYWdlbWVudCBvdGhlciB0aGFuIGFzDQo5ODUg ICBkaXNjdXNzZWQgaW4gdGhlIE1hbmFnZWFiaWxpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBv ZiBbUkZDNzc1Ml0uDQo5ODYgICBTcGVjaWZpY2FsbHksIHRoZSBtYWxmb3JtZWQgYXR0cmlidXRl IHRlc3RzIGZvciBzeW50YWN0aWMgY2hlY2tzIGluDQo5ODcgICB0aGUgRmF1bHQgTWFuYWdlbWVu dCBzZWN0aW9uIG9mIFtSRkM3NzUyXSBub3cgZW5jb21wYXNzIHRoZSBuZXcgQkdQLQ0KOTg4ICAg TFMgQXR0cmlidXRlIFRMVnMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LiAgVGhlIHNlbWFudGlj IG9yIGNvbnRlbnQNCjk4OSAgIGNoZWNraW5nIGZvciB0aGUgVExWcyBzcGVjaWZpZWQgaW4gdGhp cyBkb2N1bWVudCBhbmQgdGhlaXINCjk5MCAgIGFzc29jaWF0aW9uIHdpdGggdGhlIEJHUC1MUyBO TFJJIHR5cGVzIG9yIHRoZWlyIEJHUC1MUyBBdHRyaWJ1dGUgaXMNCjk5MSAgIGxlZnQgdG8gdGhl IGNvbnN1bWVyIG9mIHRoZSBCR1AtTFMgaW5mb3JtYXRpb24gKGUuZy4gYW4gYXBwbGljYXRpb24N Cjk5MiAgIG9yIGEgY29udHJvbGxlcikgYW5kIG5vdCB0aGUgQkdQIHByb3RvY29sLg0KDQpbbml0 XSBzL3RoYXQgd2FzIGRpc3RyaWJ1dGVkL3RoYXQgaXMgZGlzdHJpYnV0ZWQNCg0KOTk0ICAgQSBj b25zdW1lciBvZiB0aGUgQkdQLUxTIGluZm9ybWF0aW9uIGlzIHJldHJpZXZpbmcgdGhpcyBpbmZv cm1hdGlvbg0KOTk1ICAgZnJvbSBhIEJHUCBwcm90b2NvbCBjb21wb25lbnQgdGhhdCBpcyBkb2lu ZyB0aGUgc2lnbmFsaW5nIG92ZXIgYSBCR1AtDQo5OTYgICBMUyBzZXNzaW9uLCB2aWEgc29tZSBB UElzIG9yIGEgZGF0YSBtb2RlbCAocmVmZXIgU2VjdGlvbiAxIGFuZCAyIG9mDQo5OTcgICBbUkZD Nzc1Ml0pLiAgVGhlIGhhbmRsaW5nIG9mIHNlbWFudGljIG9yIGNvbnRlbnQgZXJyb3JzIGJ5IHRo ZQ0KOTk4ICAgY29uc3VtZXIgd291bGQgYmUgZGljdGF0ZWQgYnkgdGhlIG5hdHVyZSBvZiBpdHMg YXBwbGljYXRpb24gdXNhZ2UgYW5kDQo5OTkgICBoZW5jZSBpcyBiZXlvbmQgdGhlIHNjb3BlIG9m IHRoaXMgZG9jdW1lbnQuICBUaGlzIGRvY3VtZW50IG9ubHkNCjEwMDAgICBpbnRyb2R1Y2VzIG5l dyBBdHRyaWJ1dGUgVExWcyBhbmQgYW4gZXJyb3IgaW4gdGhlbSB3b3VsZCByZXN1bHQgaW4NCjEw MDEgICBvbmx5IHRoYXQgc3BlY2lmaWMgYXR0cmlidXRlIGJlaW5nIGRpc2NhcmRlZCB3aXRoIGFu IGVycm9yIGxvZy4NCg0KW25pdF0gcy9pcyByZXRyaWV2aW5nIHRoaXMvcmV0cmlldmVzIHRoaXMN Cg0KW21pbm9yXSAiLi4ucmV0cmlldmluZyB0aGlzIGluZm9ybWF0aW9uLi4ub3ZlciBhIEJHUC1M UyBzZXNzaW9uLCB2aWEgc29tZSBBUElzIG9yIGEgZGF0YSBtb2RlbCAocmVmZXIgU2VjdGlvbiAx IGFuZCAyIG9mIFtSRkM3NzUyXSkuIiAgSSB0aGluayB0aGF0IGV2ZW4gbWVudGlvbmluZyB0aGF0 IGFuIEFQSSBvciBkYXRhIG1vZGVsIGNhbiBiZSB1c2VkIGluc3RlYWQgb2YgQkdQLUxTIGlzIGEg c3RyZXRjaCAtLSB0aGF0IGlzIG5vdCBob3cgSSBpbnRlcnByZXQgdGhlIGluaXRpYWwgc2VjdGlv bnMgaW4gcmZjNzc1MiAod2hpY2ggYXJlIGp1c3QgYmFja2dyb3VuZCBzZWN0aW9ucyksIGFuZCB0 aGVyZSBhcmUgbm8gZm9ybWFsIEFQSS9kYXRhIG1vZGVsIGRlZmluaXRpb24uDQoNClttYWpvcl0g Ii4uLm5ldyBBdHRyaWJ1dGUgVExWcyBhbmQgYW4gZXJyb3IgaW4gdGhlbSB3b3VsZCByZXN1bHQg aW4gb25seSB0aGF0IHNwZWNpZmljIGF0dHJpYnV0ZSBiZWluZyBkaXNjYXJkZWQgd2l0aCBhbiBl cnJvciBsb2cuIiAgQWNjb3JkaW5nIHRvIHJmYzc3NTIsIHRoaXMgc3RhdGVtZW50IGlzIHRydWUg b25seSBmb3Igc3ludGFjdGljIGVycm9ycywgbm90IHNlbWFudGljIG9uZXMuDQoNClNlbWFudGlj IGVycm9ycyAoImxlZnQgdG8gdGhlIGNvbnN1bWVyIiwgYXMgbWVudGlvbmVkIGFib3ZlKSBtZWFu cyB0aGF0IHRoZSBCR1AtTFMgc2Vzc2lvbiBjYW4gYmUgdXNlZCB0byB0cmFuc3BvcnQgdHJhc2gg KHRyYXNoLWluLXRyYXNoLW91dCkuICBKZWZmIEhhYXMgYnJvdWdodCB0aGlzIHVwIGR1cmluZyB0 aGUgV0dMQyBbNF0uICBJIGFncmVlICh3aXRoIHRoZSBDaGFpcnMnDQpjb25jbHVzaW9uKSB0aGF0 IHRoaXMgaXNzdWUgaXMgYmlnZ2VyIHRoYW4gdGhpcyBkb2N1bWVudCAtLSBidXQgKGJlY2F1c2Ug d2UgZG9uJ3QgaGF2ZSBhIGN1cnJlbnQgc29sdXRpb24pIEkgd291bGQgbGlrZSB0byBzZWUgaXQg bWVudGlvbmVkIHNvbWV3aGVyZSBhcyBhIHBvdGVudGlhbCBpc3N1ZSAobWF5YmUgaW4gdGhlIE1h bmFnZW1lbnQgb3IgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbnMsIHlvdXIgY2hvaWNl KS4NCg0KWzRdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaWRyL1lmcDZX eXFuUnRNQU9lWnZTdks3cllDVWtIZw0KDQpbbWFqb3JdIHJmYzc3NTIgZG9lcyBtYW5kYXRlIHRo ZSB1c2Ugb2YgImF0dHJpYnV0ZSBkaXNjYXJkIiAocmZjNzYwNikuIEkgd291bGQgcmVhbGx5IGxp a2UgdG8gc2VlIGEgZGlzY3Vzc2lvbiAob3IgYXQgbGVhc3QgYSBtZW50aW9uKSBhcm91bmQgdGhl IGZhY3QgdGhhdCBkaXNjYXJkaW5nIGFuIGF0dHJpYnV0ZSBtYXkgcmVzdWx0IGluIHRoZSByZWNl aXZlciBub3QgaGF2aW5nIGNvbXBsZXRlIGluZm9ybWF0aW9uLiAgSW4gdGhlIGNhc2Ugb2YgU1Is IHRoaXMgaW1wbGllcyB0aGF0IHRoZSBjb250cm9sbGVyIG1heSBub3QgaGF2ZSBjb21wbGV0ZSBp bmZvcm1hdGlvbiB0byBjYWxjdWxhdGUgdGhlIHBhdGhzLg0KDQpJIHRoaW5rIHRoaXMgaXMgYW4g aXNzdWUgYmlnZ2VyIHRoYW4gdGhpcyBkb2N1bWVudCwgc28gSSBhbSBub3QgYXNraW5nIHlvdSB0 byBzb2x2ZSBpdC4uLkknbSBqdXN0IGFza2luZyBmb3IgdGhlIGRvY3VtZW50IHRvIGFja25vd2xl ZGdlIHRoYXQgaXQgZXhpc3RzIGFuZCB0byBtZW50aW9uIHdoYXQgdGhlIHBvdGVudGlhbCBpbXBh Y3QgbWF5IGJlLg0KDQoNCjEwMDMgICBUaGUgZXh0ZW5zaW9ucywgc3BlY2lmaWVkIGluIHRoaXMg ZG9jdW1lbnQsIGRvIG5vdCBpbnRyb2R1Y2UgYW55IG5ldw0KMTAwNCAgIGNvbmZpZ3VyYXRpb24g b3IgbW9uaXRvcmluZyBhc3BlY3RzIGluIEJHUCBvciBCR1AtTFMgb3RoZXIgdGhhbiBhcw0KMTAw NSAgIGRpc2N1c3NlZCBpbiBbUkZDNzc1Ml0uICBUaGUgbWFuYWdlYWJpbGl0eSBhc3BlY3RzIG9m IHRoZSB1bmRlcmx5aW5nDQoxMDA2ICAgU1IgZmVhdHVyZXMgYXJlIGNvdmVyZWQgYnkgW0ktRC5p ZXRmLXNwcmluZy1zci15YW5nXSwNCjEwMDcgICBbSS1ELmlldGYtaXNpcy1zci15YW5nXSBhbmQg W0ktRC5pZXRmLW9zcGYtc3IteWFuZ10uDQoNClttaW5vcl0gV2hpbGUgdGhlIFlhbmcgbW9kZWxz IGhhdmUgdG8gZG8gd2l0aCBtYW5hZ2VtZW50LCB0aGVyZSBhcmUgbm8gIm1hbmFnZWFiaWxpdHkg YXNwZWN0cyBvZiB0aGUgdW5kZXJseWluZyBTUiBmZWF0dXJlcyIgaW5jbHVkZWQgdGhlcmUuDQoN ClttYWpvcl0gRm9sbG93aW5nIHRoZSByZWNvbW1lbmRhdGlvbnMgZnJvbSByZmM1NzA2LCBhIEZh dWx0IE1hbmFnZW1lbnQgc2VjdGlvbiB3b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBpbmNsdWRlIGNv bnNpZGVyYXRpb25zIHJlbGF0ZWQgdG8gdGhlIHVzZSBvZiBCR1AtTFMgYXMgYSB0cmFuc3BvcnQg Zm9yIFNSIGluZm9ybWF0aW9uIChnaXZlbiB0aGlzIGlzIHRoZSBmaXJzdCBkcmFmdCB0byBwcm9w b3NlIGl0KSwgYW5kIHRoZSBwb3NzaWJsZSBlcnJvcnMgbWVudGlvbmVkIGhlcmUuLi4gIEFnYWlu LCBub3QgbG9va2luZyBmb3Igc29sdXRpb25zLCBqdXN0IGFja25vd2xlZGdlbWVudC4NCg0KDQox MDA5IDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQoxMDExICAgVGhlIG5ldyBwcm90b2Nv bCBleHRlbnNpb25zIGludHJvZHVjZWQgaW4gdGhpcyBkb2N1bWVudCBhdWdtZW50IHRoZQ0KMTAx MiAgIGV4aXN0aW5nIElHUCB0b3BvbG9neSBpbmZvcm1hdGlvbiB0aGF0IHdhcyBkaXN0cmlidXRl ZCB2aWEgW1JGQzc3NTJdDQo= From nobody Thu Feb 14 00:29:21 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E49A13102E for ; Thu, 14 Feb 2019 00:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVvCP7g4HkxI for ; Thu, 14 Feb 2019 00:29:16 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8987713102B for ; Thu, 14 Feb 2019 00:29:15 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 440V155y9Tz4wMx; Thu, 14 Feb 2019 09:29:13 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 440V154tDpz1xp9; Thu, 14 Feb 2019 09:29:13 +0100 (CET) Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([fe80::90fe:7dc1:fb15:a02b%21]) with mapi id 14.03.0435.000; Thu, 14 Feb 2019 09:29:13 +0100 From: To: Susan Hares CC: "idr@ietf.org" , "'Jakob Heitz (jheitz)'" Thread-Topic: [Idr] WG Last Call on Extened Message Support Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rAefZHwsB7dxHTqRpTUcwgADq23A= Date: Thu, 14 Feb 2019 08:29:13 +0000 Message-ID: <17281_1550132953_5C6526D9_17281_161_1_53C29892C857584299CBF5D05346208A489D3D92@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk> <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> In-Reply-To: <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A489D3D92OPEXCAUBM43corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 08:29:20 -0000 --_000_53C29892C857584299CBF5D05346208A489D3D92OPEXCAUBM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sue, Thanks for the reply. Please see inline [Bruno] From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, February 13, 2019 8:03 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support Bruno: I'd like to answer some of the questions you sent Randy based on comments (= public and private) the chairs and I as the shepherd received on this draft= in our last WG LCs. Several of the comments you questioned were put in to answer other question= s. This gets into a catch-22... problem - where you put changes in for on= e person/take out the changes out for another. In academic circles this is= called the reviewer #2 problem (reviewer 1 insists changes go in, reviewer= 2 insists changes go out) during publication. Therefore, I'm I am going t= o answer most of your questions where this is the case. I believe that Randy has new version with the changes I've indicated. I'm = hoping he'll just post that version. AFAILK, we do have 2 compliant implem= entations. Sue This draft's technology provides efficient processing for some application = by allow a huge BGP message size. Whether "chunking" BGP to 4096 byte mess= ages or packing large amounts of data into 65,000 byte message is more effe= ctive for a particular application is something only an implementer of a pa= rticular BGP implementation can decide. This draft simply gives freedom = for applications to not be restrict to an artificially small message size. = The market place will choose whether this technology is used or not. As Jakob pointed out, changing a highly tuned BGP implementation which "chu= nks" BGP data into 4096 byte messages may involve substantial rework of the= implementation. (snip) From: Idr On Behalf Of bruno.decraene@orange.com Sent: 29 January 2019 13:33 To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support Hi WG, >Please find below some comments. >As of today, I don't believe this specification is ready to be progressed = to IESG/RFC, especially for a document >updating RFC 4271 (core BGP spec). > The WG chairs intend to forward this draft to the IESG with the current l= evel of implementation. >https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended->implement= ations says : 5a Does not send Extended Message capability Yes Yes Yes >I may be misunderstanding the implementation report, but my reading of the= above is that none of the reported >implementations sends the capability h= ence no implementation supports draft-ietf-idr-bgp-extended-messages.. >Here this document is updating RFC 4271, so it is not a minor extension fo= r a niche use case. So I don't see the >arguments for not requiring the IDR= 's usual two interoperable implementations. >In our mail thread, we discovered that the implementation report should ha= ve indicate >full support. I'm waiting for Olivier to update based on the last point,= but my understanding is that All implementations have full support. [Bruno] ok, solved >---- >=A7 1 >" As BGP is extended to support newer AFI/SAFIs and > newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there is > a need to extend the maximum message size beyond 4096 octets. " > > https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on-1 >[I-D.ietf-sidr-bgpsec-protocol is now RFC 8205= (thanks for updating the reference). It has removed the normative/any >ref= erence to draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does = not need draft-ietf-idr-bgp->extended-messages. Can we have an update on th= is? Can the introduction of draft-ietf-idr-bgp-extended-messages >be updat= ed to introduce on the real reasons/needs? SIDR gave up waiting on IDR's work and took a reduced size of encryption. = The security people were very sad about the reduction. How is this workin= g in practice? WG sidrops can answer this question. The real problem is there is finite message space. [Bruno] So too bad the draft does not solve the real problem ;-) (as messag= e space is still limited) There are two ways to send lots of BGP routes and/or attributes - to "chunk= " these into small message sizes or place these into a large message. So= me applications may always want to "chunk" into message sizes smaller than = 4096. Some application make work more efficiently utilizing large message= size. As the potential number of NLRI and BGP attributes grows, new appli= cations may consider large message sizes to a more reasonable way to exchan= ge amounts of BGP data. The decision on how to send BGP messages over the wire is a peer-by-peer de= cision in a network. Each BGP peer is in charge of reformatting the BGP m= essage it sends to the remote BGP peer. The BGP capabilities in this draf= t represent an agreement between two BGP peers. These are facts of basic B= GP implementations [Bruno] Let's take the example of a BGP Route Reflector having a mixed of c= lients, some supporting Extend Message (EM) and some not. >From an EM client, it receives a BGP update containing one (single) NLRI wi= th an Total Path Attribute Length bigger than 4090 byte (e.g. having 1000 = large communitiess) Can you explain me how it behaves to send this NLRI to an IBGP peer not sup= porting EM? - so I do not believe adding these facts to Randy's draft is useful. In fa= ct, in the previous rounds of review this point was made. Your question (and perhaps Jakob's) is whether we have reached a time/place= where the "chunking" approach will fail on a peer-by-peer basis? This dr= aft does not make this statement. The point of this draft is to enable more efficient processing by increasin= g the message size for BGP peers that send a lot of data (e.g. BGP-LS) . = The choice to "chunk" or stream in large BGP message is an implementation c= hoice for a particular BGP application. ---- =A74 =A73 says "A peer which does not advertise this capability MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to it." [I believe randy accepted this change with the following text in version 4 = [upcoming below]]/. -------------- Fine. Text in =A74 should probably be aligned with the above .e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and received = the Extended Message Capability to and from that peer. ---- >" Applications generating information which might be encapsulated > within BGP messages MUST limit the size of their payload to take the > maximum message size into account." > >I don't see what new behavior is been defined here. If there is none, I wo= uld suggest to remove this sentence Bruno - people asked to put this text in as an operational warning. At thi= s point, I'm going to say unless there is harm it should remain. [Bruno] OK. ---- > A BGP announcement will, in the normal case, propagate throughout the > BGP speaking Internet; and there will undoubtedly be BGP speakers > which do not have the Extended Message capability. Therefore, > putting an attribute which can not be decomposed to 4096 octets or > less in an Extended Message is a likely path to routing failure. > >The issue is not specific to attributes bigger than 4096 octets, but to BG= P message whose length is bigger than >4096, irrespective of the size of ea= ch attribute. >Please elaborate on what you mean by > >"an attribute which cannot be decomposed to 4096 octets" An attribute which cannot be decomposed to 4096 is an attribute with length= 6000 inside of a BGP message which requires the entire attribute to be inc= luded. No such attribute exists today. If a small BGP peers create a "k= iller application" that uses a 6000 byte attribute, the rest of the Interne= t does not have to use it. However, the person defining that attribute mu= st carefully specify it must go with Extended BGP messages. [Bruno] I don't think that I agree with this. E.g. I don't see where RFCs 1= 997 or 8092 [(large)community] limits the size of their attribute. Hence I = don't see why you could not have, today (with Extended Message support) , a= ttributes larger than 4096 octets. Most probably same status for the BGPSec= attribute since they wanted for more space. This text was added during an earlier discussion where the error cases of a= large BGP attribute was given. The originator of the common could not pro= vide the exact description, but we agreed to put this "warning label" into= the draft. This is one of the cases where adding/removing text gets to b= e problematic. >--- >" It is RECOMMENDED that BGP protocol developers and implementers are > conservative in their application and use of Extended Messages." > >What does this mean exactly? That they don't use this extension? >That they don't use this extension unless XX_TO BE SPECIFIED_XX? This warning was text that other participants asked to be added. It is a common sense warning. Extended messages are enabled on a peer by p= eer basis as all BGP capabilities are. If you run into a Peer that does no= t support the larger sizes, the BGP messages will need to be reformatted to= the smaller size. Running immediately to the Extended messages as the de= fault could cause problems. [Bruno] I think that the sentence could be elaborated. Indicating the probl= em, how the specification partially address it, and how the specification d= oes not address it. In "Running immediately to Extended Message" I don't think they that the is= sue is with "immediately". Whenever you start the transition, your likely t= o run into problems. --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages. >Why is this limited to future specifications? A priori, using existing BGP= mechanism (AFI/SAFI, attributes, * >communities) one could exceed the size= of 4096 octets. How does the BGP speaker supposed to behave in this ?>case= ? This should be described in this specification. Note that this is not a c= ase of error handling, as every BGP > speaker is behaving as specified. I fail to see your logic. At this point, all BGP data (AFI/SAFI and attrib= utes) must fit within a 4096 message. Therefore, a BGP peer A which conne= cts on link 1 to BGP peer B with 4096 message and on link to a BGP peer C w= ith extended messages only has to worry about reformatting the data. In the future, the first group that defines attribute or an NLRI that does = not fit within a 4096 BGP message and cannot be split, will need to define = how that works in the specification. There is no need to refine the curren= t set of specifications. [Bruno] 1) cf above, I believe that there are existing BGP Attributes which may not= fit into a bytes 4096 BGP message 2)Even in the absence of such attribute, you have the issue of 2 smaller at= tributes whose cumulative size does not fit into a 4096 bytes message. The problem is introduced by this specification, hence I believe this speci= fication needs to specify how to handle this case. >---- >Depending on the above specification, a section describing the operational= consequences in a network (such as the >Internet, BGP Enabled ServiceS/VPN= networks) is probably needed. Possible consequences could be BGP NLRI >bei= ng removed in the middle of such network, or (extended) community (such as = Route Targets) been removed. >Both having significant consequences on the a= vailability provided by the network. At this point, there are no attributes or NLRI groupings that do not fit wi= thin 4096. If you define one (as SIDR did), then you will need to have it= reviewed by IDR, BESS, SPRING, and operational groups (GROW, etc). [Bruno] no, cf above. Thanks, --Bruno --- >=A74 >OLD: The Extended Message Capability only applies to all messages except f= or the >OPEN message. >Probably >NEW: The Extended Message Capability applies to all message types except f= or the >OPEN message (type 1). >---- >=A78 >"This extension to BGP does not change BGP's underlying security issues = =BB >Before evaluating this, I think this document should first specified how a= BGP >messages bigger than 4096 octets is handled when it needs to be sent to a >received not supporting this extension. Nits: >OLD : to reduce compexity >NEW : to reduce complexity Thanks, --Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org Subject: [Idr] WG Last Call on Extened Message Support This begins a 2 week WG LC on Extended Message Support for BGP (draft-ietf-= idr-bgp-extended-messages-27). You can access the draft at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ The authors should indicate whether they know of any IPR. Implementers ar= e encouraged to update the implementation data at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementat= ions The draft provides a means for expanding the BGP message to 65535 octets fo= r all messages except OPEN messages. BGP message space is running short fo= r all of the potential attributes or additions proposed by BGP-LS features. The WG chairs intend to forward this draft to the IESG with the current lev= el of implementation. As you comment on the draft, please consider if: a) the technology is matur= e, b) the additional space in a BGP message would be helpful for those depl= oying BGP-LS or SR, and c) if the specification is ready for publication. Sue Hares (WG Chair, Shepherd) ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A489D3D92OPEXCAUBM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sue,

 

Thanks for t= he reply. Please see inline [Bruno]

 <= /o:p>

= From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, February 13, 2019 8:03 PM
To: DECRAENE Bruno TGI/OLN
Cc: idr@ietf.org; 'Jakob Heitz (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message Support

 

Bruno:

 

I’d like to answer some of= the questions you sent Randy based on comments (public and private) the chairs and I as the shepherd received on this draft in our last WG LCs= .   

 

Several of the comments you ques= tioned were put in to answer other questions.   This gets into a catch-22… problem – where you put changes in for one person/= take out the changes out for another.  In academic circles this is cal= led the reviewer #2 problem (reviewer 1 insists changes go in, reviewer 2 i= nsists changes go out) during publication.  Therefore, I’m I am going to answer most of your questions where this is the ca= se. 

 

I believe that Randy has new ver= sion with the changes I’ve indicated.  I’m hoping he’= ;ll just post that version.  AFAILK, we do have 2 compliant implementations. <= o:p>

 

Sue

 

 

 

<shepherd hat on>

This draft’s technology pr= ovides efficient processing for some application by allow a huge BGP message size.  Whether “chunking” BGP to 4096 byte messag= es or packing large amounts of data into 65,000 byte message is more effect= ive for a particular application is something only an implementer of a part= icular BGP implementation  can decide.   This draft simply gives freedom for applications to not be restrict to an artificiall= y small message size.  The market place will choose whether this techn= ology is used or not. 

 

As Jakob pointed out, changing a= highly tuned BGP implementation which “chunks” BGP data into 4096 byte messages may involve substantial rework of the implementation.&n= bsp;

 

 

(snip)

From: Idr <idr-bounces@ietf.org> On Behalf Of bruno.decraene@orange= .com
Sent: 29 January 2019 13:33
To: Susan Hares <shares@ndzh.com>
Cc: idr@ietf.org
Subject: Re: [Idr] WG Last Call on Extened Message Support

 

Hi WG,

 

>Please find below some comments.

>As of today, I don’t believe this specification is ready to be progress= ed to IESG/RFC, especially for a document >updating RFC 4271 (core BGP spec).=

 

> The WG chairs intend to forward= this draft to the IESG with the current level of implementation. 

 

>https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-exten= ded->implementations says : 5a

Does not send Extended Message capability

Yes

Yes

Yes

 

>I may be misunderstanding the implementation report, but my reading of the a= bove is that none of the reported >implementations sends the capabili= ty hence no implementation supports draft-ietf-idr-bgp-extended-messages..

>Here this document is updating RFC 4271, so it is not a minor extension for a n= iche use case. So I don’t see the >arguments for not requiring the ID= R’s usual two interoperable implementations.

 

>In our mail thread, we disco= vered that the implementation report should have indicate=

>full support.   I&= #8217;m waiting for Olivier to update based on the last point, but my under= standing is that

All implementations have full su= pport.  

 

[Bruno] ok, solved

>----

>=A7 1

>“ As BGP is extended to support newer AFI/SAFIs and

> &= nbsp; newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there is

> &= nbsp; a need to extend the maximum message size beyond 4096 octets.  “= ;

>&n= bsp;

> https://tools.ietf.o= rg/html/draft-ietf-idr-bgp-extended-messages-27#section-1

 

 

>[I-D.ietf-sidr-bgpsec-protocol is now RFC 8205 (t= hanks for updating the reference). It has removed the normative/any >reference to draft-ietf-idr-bgp-ex= tended-messages. So presumably BGP Sec does not need draft-ietf-idr-bgp->extended-messages. Can we have an update on this?  <= /span>Can the introduction of draft-ietf-idr-bgp-extended-messages >be update= d to introduce on the real reasons/needs?

 

SIDR gave up waiting on IDR̵= 7;s work and took a reduced size of encryption.   The security pe= ople were very sad about the reduction.  How is this working in practice? = WG sidrops can answer this question. 

 

The real problem is there is fin= ite message space. 

[Bruno] So too bad the draft does not solve the real problem ;-) (as message space= is still limited)

 

There are two ways to send lots = of BGP routes and/or attributes – to “chunk” these into s= mall message sizes or place these into a large message.    Some = applications may always want to “chunk” into message sizes smal= ler than 4096.   Some application make work more efficiently util= izing large message size.  As the potential number of NLRI and BGP att= ributes grows, new applications may consider large message sizes to a more reasona= ble way to exchange amounts of BGP data.    

 

The decision on how to send BGP = messages over the wire is a peer-by-peer decision in a network.   Each BGP peer is in charge of reformatting the BGP message it sends = to the remote BGP peer.   The BGP capabilities in this draft repr= esent an agreement between two BGP peers.  These are facts of basic BG= P implementations

[Bruno] Let’s take the example of a BGP Route Reflector having a mixed of cl= ients, some supporting Extend Message (EM) and some not.<= /i>

From an EM client, it receives a BGP update containing one (single) NLRI with a= n Total Path Attribute Length bigger than  4090 byte (e.g. having 1000 l= arge communitiess)

Can you explain me how it behaves to send this NLRI to an IBGP peer not suppor= ting EM?

– so I do not believe addi= ng these facts to Randy’s draft is useful.  In fact, in the prev= ious rounds of review this point was made.

 

Your question (and perhaps Jakob= ’s) is whether we have reached a time/place where the “chunking= ” approach will fail on a peer-by-peer basis?   This draft does no= t make this statement. 

 

The point of this draft is to en= able more efficient processing by increasing the message size for BGP peers that send a lot of data (e.g. BGP-LS) .   The choi= ce to “chunk” or stream in large BGP message is an implementati= on choice for a particular BGP application. 

 

----

=A74

=A73 =
says “A peer which does not a=
dvertise this capability MUST NOT send BGP

   Extended Messages, and BGP Extended Messages MUST NO= T be sent to it.&#= 8221;

 

[I believe randy accepted this c= hange with the following text in version 4 [upcoming below]]/.

 

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

 

Fine. Text in =A74 should probably b= e aligned with the above .e.g.

OLD: A BGP speaker

   MAY send Extended Messages to its peer only if it ha= s received the

   Extended Message Capability from that peer.

 

NEW:

A BGP speaker

   MAY send Extended Messages to its peer only if it ha= s sent and received the

   Extended Message Capability to and from that peer.

 

 

 

----

>“   Applicat=
ions generating information which might be encapsulated

> &=
nbsp;
 within BGP messages MUST limit the size of their payload to take the<=
/o:p>


> &=
nbsp;
 maximum message size into account.”


> 


>I
 don’t see what new behavior is been defined here. If there is none, =
I would suggest to remove this sentence


 


Bruno – people asked to pu=
t this text in as an operational warning.  At this point, I’m go=
ing
 to say unless there is harm it should remain.  


[Bruno]
 OK.


 


----


> &=
nbsp;
 A BGP announcement will, in the normal case, propagate throughout the=



> &=
nbsp;
 BGP speaking Internet; and there will undoubtedly be BGP speakers


> &=
nbsp;
 which do not have the Extended Message capability.  Therefore,


> &=
nbsp;
 putting an attribute which can not be decomposed to 4096 octets or


> &=
nbsp;
 less in an Extended Message is a likely path to routing failure.


> 


>The
 issue is not specific to attributes bigger than 4096 octets, but to BGP me=
ssage whose length is bigger than
>=
4096, =
irrespective
 of the size of each attribute.


>Please
 elaborate on what you mean by 


> 


>“an
 attribute which cannot be decomposed to 4096 octets”


 


An attribute which cannot be dec=
omposed to 4096 is an attribute with length 6000 inside of a
 BGP message which requires the entire attribute to be included.  &nbs=
p;No such attribute exists today.   If a small BGP peers create a=
 “killer application” that uses a 6000 byte attribute, the rest=
 of the Internet does not have to use it.   However, the person
 defining that attribute must carefully specify it must go with Extended BG=
P messages.



[Bruno]
 I don’t think that I agree with this. E.g. I don’t see where R=
FCs 1997 or 8092 [(large)community] limits the size of their attribute. Hen=
ce I don’t see why you could not have, today (with Extended Message s=
upport) , attributes larger than 4096 octets. Most
 probably same status for the BGPSec attribut=
e since they wanted for more space.


 


This text was added during an ea=
rlier discussion where the error cases of a large BGP attribute
 was given.  The originator of the common could not provide the exact =
description, but we agreed to put this  “warning label” in=
to the draft.   This is one of the cases where adding/removing te=
xt gets to be problematic.



 


>---


>“=
  
 It is RECOMMENDED that BGP protocol developers and implementers are


> &=
nbsp;
 conservative in their application and use of Extended Messages.”


>&n=
bsp;


>What
 does this mean exactly? That they don’t use this extension? 



>That
 they don’t use this extension unless XX_TO BE SPECIFIED_XX?


 


This warning was text that other=
 participants asked to be added.



 


It is a common sense warning.&nb=
sp; Extended messages are enabled on a peer by peer basis as all
 BGP capabilities are.  If you run into a Peer that does not support t=
he larger sizes, the BGP messages will need to be reformatted to the smalle=
r size.   Running immediately to the Extended messages as the def=
ault could cause problems.



 


[Bruno]
 I think that the sentence could be elaborated. Indicating the problem, how=
 the specification partially address it, and how the specification does not=
 address it.


In
 “Running immediately to Extended Message” I don’t think =
they that the issue is with “immediately”. Whenever you start t=
he transition, your likely to run into problems.<=
/p>

---


  Future protocol specifications will need to describe how t=
o handle


   peers which can only accommodate 4096 octet messages=
.


 


>Why
 is this limited to future specifications? A priori, using existing BGP mec=
hanism (AFI/SAFI, attributes, *
>communities) one could exceed the =
size of 4096 octets. How does the BGP speaker supposed to behave in this
?>case? This should be described in=
 this specification. Note that this is not a case of error handling, as eve=
ry BGP



>
speaker is behavin=
g as specified.


 


I fail to see your logic.  =
At this point, all BGP data (AFI/SAFI and attributes) must fit within
 a 4096 message.   Therefore, a BGP peer A which connects on link=
 1 to BGP peer B with 4096 message and on link to a BGP peer C with extende=
d messages only has to worry about reformatting the data. 



 


In the future, the first group t=
hat defines attribute or an NLRI that does not fit within a
 4096 BGP message and cannot be split, will need to define how that works i=
n the specification.  There is no need to refine the current set of sp=
ecifications.  



[Bruno=
]


1)
cf above, I believe that there are existing B=
GP Attributes which may not fit into a bytes 4096 BGP message


2)Even
 in the absence of such attribute, you have the issue of 2 smaller attribut=
es whose cumulative size does not fit into a 4096 bytes message.=



The
 problem is introduced by this specification, hence I believe this specific=
ation needs to specify how to handle this case.


 


>----


>Depending
 on the above specification, a section describing the operational consequen=
ces in a network (such as the
>=
Intern=
et, BGP
 Enabled ServiceS/VPN networks) is probably needed. Possible consequences c=
ould be BGP NLRI
>=
being =
removed
 in the middle of such network, or (extended) community (such as Route Targ=
ets) been removed.
>=
Both h=
aving significant
 consequences on the availability provided by the network.


 


At this point, there are no attr=
ibutes or NLRI groupings that do not fit within 4096.   If you
 define one (as SIDR did), then you will need to have it reviewed by IDR, B=
ESS, SPRING, and operational groups (GROW, etc). 


[Bruno]
 no, cf above.


&=
nbsp;


Thanks=
,


--Brun=
o




 


---


>=A74


>OLD:
 The Extended Message Capability only applies to all messages except for th=
e 
>OPEN message. 


>Probabl=
y


>NEW:
 The Extended Message Capability applies to all message types except for th=
e 
>OPEN message (type 1). 


>----


>=A78


>“This extension to BGP does not c=
hange BGP's underlying security issues =BB


>Before evaluating this, I think this do=
cument should first specified how a BGP =



>messages bigger than 4096 octets is han=
dled when it needs to be sent to a 


>received not support=
ing this extension.


 


Nits:


>OLD&nbs=
p;:
 to reduce compexity


>NEW&nbs=
p;:
 to reduce complexity


 


Thanks,


--Bruno


 








From: Idr [mailto:id=
r-bounces@ietf.org]
On Behalf Of Susan Hares

Sent: Tuesday, January 29, 2019 12:33 PM

To: idr@ietf.org

Subject: [Idr] WG Last Call on Extened Message Support






 


 


This begins a 2 week WG LC on Extend=
ed Message Support for BGP (draft-ietf-idr-bgp-extended-messages-27). 
 You can access the draft at: 


 


https://datatracker.ietf=
.org/doc/draft-ietf-idr-bgp-extended-messages/


 


The authors should indicate whether =
they know of any IPR.   Implementers are encouraged to update
 the  implementation data at: 


 


https://trac.ie=
tf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations=
<=
/o:p>


 


The draft provides a means for expan=
ding the BGP message to 65535 octets for all messages except
 OPEN messages.  BGP message space is running short for all of the pot=
ential attributes or additions proposed by BGP-LS features. 



 


The WG chairs intend to forward this=
 draft to the IESG with the current level of implementation. 



 


As you comment on the draft, please =
consider if: a) the technology is mature, b) the additional
 space in a BGP message would be helpful for those deploying BGP-LS or SR, =
and c) if the specification is ready for publication. 



 


Sue Hares (WG Chair, Shepherd)



 


 




_=
___________________________________________________________________________=
_____________________________________________


<=
o:p> 


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as etre diffuses, exploites ou copies sans autorisation. Si vous avez recu =
ce message par erreur, veuillez le signaler


a=
 l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


T=
hank you.


_______________________________________________________=
__________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des i=
nformations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisatio=
n. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les pieces join=
tes. Les messages electroniques etant susceptibles d'alteration,=



Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confidenti=
al or privileged information that may be protected by law;


they should not be distributed, used or copied without =
authorisation.


If you have received this email in error, please notify=
 the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for mess=
ages that have been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A489D3D92OPEXCAUBM43corp_-- From nobody Thu Feb 14 01:47:19 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E5413106C for ; Thu, 14 Feb 2019 01:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZlyx4fkav5Z for ; Thu, 14 Feb 2019 01:47:13 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1C812D4E9 for ; Thu, 14 Feb 2019 01:47:13 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 440Wl331H9zCrpd; Thu, 14 Feb 2019 10:47:11 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 440Wl32HHFzDq7J; Thu, 14 Feb 2019 10:47:11 +0100 (CET) Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([fe80::c911:d24e:cc19:afa7%21]) with mapi id 14.03.0435.000; Thu, 14 Feb 2019 10:47:11 +0100 From: To: Randy Bush CC: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] WG Last Call on Extened Message Support Thread-Index: AQHUw+Qj1bTPsyO86K1JuAQ7q/LpfaXe91yg Date: Thu, 14 Feb 2019 09:47:10 +0000 Message-ID: <3465_1550137631_5C65391F_3465_424_1_53C29892C857584299CBF5D05346208A489D4177@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 09:47:15 -0000 Dear Randy, > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com]=20 > Sent: Wednesday, February 13, 2019 10:36 PM >=20 > dear reviewer #2: >=20 > excuse, this has been in an edit buffer for weeks. No problem. Thanks for the reply. =20 > > [I-D.ietf-sidr-bgpsec-protocol > > is now RFC 8205 (thanks for updating the reference). It has removed the= normative/any reference to > > draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not ne= ed draft-ietf-idr-bgp-extended-messages.=20 > > Can we have an update on this? >=20 > extended-messages authors had $dayjobs and did not have the stamina for > the level of dos in the sidr wg. they were desperate to get bgpsec our > the door and idr was holding them hostage. and it's not like bgpsec is > just around the corner. >=20 > > Can the introduction of draft-ietf-idr-bgp-extended-messages be > > updated to introduce on the real reasons/needs? >=20 > would you like it if we threw in bgp-ls? no extra charge. -28 looks good to me. =20 > > =A73 says "A peer which does not advertise this capability MUST NOT sen= d BGP > > Extended Messages, and BGP Extended Messages MUST NOT be sent to it." > >=20 > > Fine. Text in =A74 should probably be aligned with the above .e.g. > >=20 > > OLD: A BGP speaker > > MAY send Extended Messages to its peer only if it has received the > > Extended Message Capability from that peer. > >=20 > > NEW: > > A BGP speaker > > MAY send Extended Messages to its peer only if it has sent and recei= ved the > > Extended Message Capability to and from that peer. >=20 > the intent was to allow simplexity, use of extended messages in one > direction only. in retrospect, this may be too subtle/clever. it could > be as you suggest if no one wants simplexity. Both options works for me. My comment was that =A73 and =A74 did not seemed= aligned on this point. -28 looks good to me. =20 > > " Applications generating information which might be encapsulated > > within BGP messages MUST limit the size of their payload to take the > > maximum message size into account." > >=20 > > I don't see what new behavior is been defined here. If there is none, I= would suggest to remove this sentence >=20 > it was added to reaffirm what to you is obvious. unless you really > object, i see no harm in leaving it. Whether this is obvious or not, this is true/applicable at least from RFC 4= 271. IOW, this draft does not change the point that the BGP message is limi= ted in size. Ok for leaving it. > > A BGP announcement will, in the normal case, propagate throughout the > > BGP speaking Internet; and there will undoubtedly be BGP speakers > > which do not have the Extended Message capability. Therefore, > > putting an attribute which can not be decomposed to 4096 octets or > > less in an Extended Message is a likely path to routing failure. > >=20 > > The issue is not specific to attributes bigger than 4096 octets, but to= BGP message whose length is bigger than 4096, irrespective of the size of = each attribute. > > Please elaborate on what you mean by "an attribute which can not be dec= omposed to 4096 octets" >=20 > a prefix announcement with 200 researcher-invents-massive-attribute? :) > [ nanog joke ] 1) Taking the large community example, [RFC8092], this attribute could be b= igger than 4096 octets. How would you handle this? 2) The problem is not limited to attribute bigger than 4096 octets. If you = have one NLRI having an attribute of 2100 octets and an attribute of 2000 o= ctets, how do you handle this? >=20 > > --- > > " It is RECOMMENDED that BGP protocol developers and implementers are > > conservative in their application and use of Extended Messages." > >=20 > > What does this mean exactly? That they don't use this extension? That t= hey don't use this extension unless XX_TO BE SPECIFIED_XX? > >=20 > > --- > > Future protocol specifications will need to describe how to handle > > peers which can only accommodate 4096 octet messages. > >=20 > > Why is this limited to future specifications? A priori, using existing = BGP mechanism (AFI/SAFI, attributes, * communities) one could exceed the si= ze of 4096 octets. How does the BGP speaker supposed to behave in this case= ? This should be described in this specification. Note that this is not a c= ase of error handling, as every BGP speaker is behaving as specified. That is my main comment. Thanks, --Bruno > > ---- > > Depending on the above specification, a section describing the operatio= nal consequences in a network (such as the Internet, BGP Enabled ServiceS/V= PN networks) is probably needed. Possible consequences could be BGP NLRI be= ing removed in the middle of such network, or (extended) community (such as= Route Targets) been removed. Both having significant consequences on the a= vailability provided by the network. > >=20 > > --- > > =A74 > > OLD: The Extended Message Capability only applies to all messages excep= t for the OPEN message. > > Probably > > NEW: The Extended Message Capability applies to all message types excep= t for the OPEN message (type 1). > > ---- > > =A78 > >=20 > > "This extension to BGP does not change BGP's underlying security issues= =BB > >=20 > > Before evaluating this, I think this document should first specified ho= w a BGP messages bigger than 4096 octets is handled when it needs to be sen= t to a received not supporting this extension. > >=20 > > Nits: > > OLD : to reduce compexity > > NEW : to reduce complexity >=20 > i took some edits, tyvm. >=20 > randy ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Feb 14 09:20:43 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67FF1311BD for ; Thu, 14 Feb 2019 09:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RguRK-57s5Ng for ; Thu, 14 Feb 2019 09:20:31 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898BD128CE4 for ; Thu, 14 Feb 2019 09:20:30 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.248.72; From: "Susan Hares" To: Cc: , "'Jakob Heitz \(jheitz\)'" , "'John Scudder'" , "'Alvaro Retana'" References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk> <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> <17281_1550132953_5C6526D9_17281_161_1_53C29892C857584299CBF5D05346208A489D3D92@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <17281_1550132953_5C6526D9_17281_161_1_53C29892C857584299CBF5D05346208A489D3D92@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Date: Thu, 14 Feb 2019 12:20:18 -0500 Message-ID: <00c901d4c489$8f311830$ad934890$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01D4C45F.A6680880" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rAefZHwsB7dxHTgI7AvBBAac2MMOkS7ENUA== Content-Language: en-us X-Antivirus: AVG (VPS 190214-2, 02/14/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 17:20:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CA_01D4C45F.A6680880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno:=20 =20 Thank you for careful considerations on the use case. I think we have translation issues between our =93English=94 language again so I have = tried to be precise in the detailed comments. I=92ve summarized my comments as = well to help us take the next step.=20 =20 Sue=20 =20 Summary ---- Good catch on the 1000 large BGP communities blowing up the message = size! This is a case where a code path could get caught with program error. = The error handling (section 6.1 in RFC4271 per section 5 in the extended specification) IMHO handles the case where the attribute is longer than = the message. Please let me know if I=92ve missed something. =20 =20 As I understand it, you are asking this specification to be expanded to = add notes on policies on what implementation should do to correctly combine RFC4271 length sizes with extended length sizes. The implementers and operations people commented earlier that this should not be in the = protocol specification other than as a brief footnote. =20 =20 I agree there is a need for such standardization as BCPs for particular = use cases (large communities, BESS (EVPN or centralized controller), SPRING, BGP-LS information (see Daylight comments yesterday), SD-WANs (rtgwg), = and SPRING. I think the chairs of the WGs utilizing should consider if = there is need for standardization for a minimal set of policy for message = sizes for specific use cases. I will be glad to send request to these WG or = to host something in IDR if there is policy that can be used across all use cases.=20 =20 To provide a slight expansion to point people in this direction, how = about this change to paragraph in section 4:=20 =20 Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed = if it=20 sent in Extended message is a large community attribute with 1000 communities.=20 (12,000 bytes). =20 / [PS =96 in American English =93Can not=94 is normally concatenated = =93cannot=94.]=20 =20 =20 =20 =20 From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Sent: Thursday, February 14, 2019 3:29 AM To: Susan Hares Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Sue, =20 Thanks for the reply. Please see inline [Bruno] =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Wednesday, February 13, 2019 8:03 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Bruno:=20 =20 I=92d like to answer some of the questions you sent Randy based on = comments (public and private) the chairs and I as the shepherd received on this = draft in our last WG LCs. =20 =20 Several of the comments you questioned were put in to answer other questions. This gets into a catch-22=85 problem =96 where you put = changes in for one person/take out the changes out for another. In academic = circles this is called the reviewer #2 problem (reviewer 1 insists changes go = in, reviewer 2 insists changes go out) during publication. Therefore, I=92m = I am going to answer most of your questions where this is the case. =20 =20 I believe that Randy has new version with the changes I=92ve indicated. = I=92m hoping he=92ll just post that version. AFAILK, we do have 2 compliant implementations.=20 =20 Sue=20 =20 =20 =20 =20 This draft=92s technology provides efficient processing for some = application by allow a huge BGP message size. Whether =93chunking=94 BGP to 4096 = byte messages or packing large amounts of data into 65,000 byte message is = more effective for a particular application is something only an implementer = of a particular BGP implementation can decide. This draft simply gives = freedom for applications to not be restrict to an artificially small message = size. The market place will choose whether this technology is used or not.=20 =20 As Jakob pointed out, changing a highly tuned BGP implementation which =93chunks=94 BGP data into 4096 byte messages may involve substantial = rework of the implementation. =20 =20 =20 (snip)=20 From: Idr On Behalf Of bruno.decraene@orange.com Sent: 29 January 2019 13:33 To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Hi WG, =20 >Please find below some comments. >As of today, I don=92t believe this specification is ready to be = progressed to IESG/RFC, especially for a document >updating RFC 4271 (core BGP = spec). =20 > The WG chairs intend to forward this draft to the IESG with the = current level of implementation. =20 =20 >https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended- >implementations says : 5a=20 Does not send Extended Message capability=20 Yes=20 Yes=20 Yes=20 =20 >I may be misunderstanding the implementation report, but my reading of = the above is that none of the reported >implementations sends the capability hence no implementation supports draft-ietf-idr-bgp-extended-messages..=20 >Here this document is updating RFC 4271, so it is not a minor extension = for a niche use case. So I don=92t see the >arguments for not requiring the = IDR=92s usual two interoperable implementations. =20 >In our mail thread, we discovered that the implementation report should have indicate >full support. I=92m waiting for Olivier to update based on the last = point, but my understanding is that=20 All implementations have full support. =20 =20 [Bruno] ok, solved >---- >=A7 1 >=93 As BGP is extended to support newer AFI/SAFIs and > newer capabilities (e.g., [ I-D.ietf-sidr-bgpsec-protocol]), there is > a need to extend the maximum message size beyond 4096 octets. =93 >=20 > https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on- 1 =20 =20 >[ I-D.ietf-sidr-bgpsec-protocol is now RFC = 8205 (thanks for updating the reference). It has removed the normative/any >reference to draft-ietf-idr-bgp-extended-messages. So presumably BGP = Sec does not need draft-ietf-idr-bgp->extended-messages. Can we have an = update on this? Can the introduction of draft-ietf-idr-bgp-extended-messages = >be updated to introduce on the real reasons/needs? =20 SIDR gave up waiting on IDR=92s work and took a reduced size of = encryption. The security people were very sad about the reduction. How is this = working in practice? WG sidrops can answer this question. =20 =20 The real problem is there is finite message space. =20 [Bruno] So too bad the draft does not solve the real problem ;-) (as = message space is still limited) =20 [Sue]: The message is still finite (smile), but I hope 65,635 (smile) = is probably enough for 10 years. =20 =20 There are two ways to send lots of BGP routes and/or attributes =96 to = =93chunk=94 these into small message sizes or place these into a large message. = Some applications may always want to =93chunk=94 into message sizes smaller = than 4096. Some application make work more efficiently utilizing large = message size. As the potential number of NLRI and BGP attributes grows, new applications may consider large message sizes to a more reasonable way = to exchange amounts of BGP data. =20 =20 The decision on how to send BGP messages over the wire is a peer-by-peer decision in a network. Each BGP peer is in charge of reformatting the = BGP message it sends to the remote BGP peer. The BGP capabilities in this draft represent an agreement between two BGP peers. These are facts of basic BGP implementations [Bruno] Let=92s take the example of a BGP Route Reflector having a mixed = of clients, some supporting Extend Message (EM) and some not. >From an EM client, it receives a BGP update containing one (single) NLRI with an Total Path Attribute Length bigger than 4090 byte (e.g. having = 1000 large communitiess) Can you explain me how it behaves to send this NLRI to an IBGP peer not supporting EM? [Sue]: Gladly=85=20 A BGP route reflector (RR-A) is peering with each of its BGP clients. = It agrees with each of its clients (BGP-C1, BGPC2, BGPC3) whether the BGP Extended messages is accepted or not (based on capability announcement). = Let us assume that BGP-C1 does not support extended messages, and = BGP-C2 and BGP-C3 do support extended messages.=20 =20 If the policy in RR accepts a total path length of 1000 large = communities with a single NLRI, it may send the BGP attribute via extended = communities to BGP-C2 and BGP-C2. The policy in the RR must specify whether:=20 a) the =93too long=94 attribute path length must be dropped, or=20 b) the BGP attribute path can be truncated.=20 =20 This is a policy issue within the BGP peer and the network operation = staff. Each operator may choose to write this policy differently.=20 =20 Rather than specify the numerous cases in the protocol specification, = the previous discussions (private and public) asked us to trim this = information out of the protocol specification.=20 =20 If you believe this is worthy of a use case draft for the sake of BESS, LSVR, SPRING, Grow and others, I will happily WG chair sponsor a draft = that can be reviewed by all these WGs.=20 =20 =20 =96 so I do not believe adding these facts to Randy=92s draft is useful. = In fact, in the previous rounds of review this point was made.=20 =20 Your question (and perhaps Jakob=92s) is whether we have reached a = time/place where the =93chunking=94 approach will fail on a peer-by-peer basis? = This draft does not make this statement. =20 =20 The point of this draft is to enable more efficient processing by = increasing the message size for BGP peers that send a lot of data (e.g. BGP-LS) . = The choice to =93chunk=94 or stream in large BGP message is an = implementation choice for a particular BGP application. =20 =20 ---- =A74 =A73 says =93A peer which does not advertise this capability MUST NOT = send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.=94 [I believe randy accepted this change with the following text in version = 4 [upcoming below]]/.=20 =20 -------------- =20 Fine. Text in =A74 should probably be aligned with the above .e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. =20 NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and = received the Extended Message Capability to and from that peer. =20 =20 ---- >=93 Applications generating information which might be encapsulated > within BGP messages MUST limit the size of their payload to take the > maximum message size into account.=94 >=20 >I don=92t see what new behavior is been defined here. If there is none, = I would suggest to remove this sentence =20 Bruno =96 people asked to put this text in as an operational warning. = At this point, I=92m going to say unless there is harm it should remain. =20 [Bruno] OK. =20 ---- > A BGP announcement will, in the normal case, propagate throughout = the > BGP speaking Internet; and there will undoubtedly be BGP speakers > which do not have the Extended Message capability. Therefore, > putting an attribute which can not be decomposed to 4096 octets or > less in an Extended Message is a likely path to routing failure. >=20 >The issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than >4096, irrespective of the size of = each attribute. >Please elaborate on what you mean by=20 >=20 >=93an attribute which cannot be decomposed to 4096 octets=94 =20 An attribute which cannot be decomposed to 4096 is an attribute with = length 6000 inside of a BGP message which requires the entire attribute to be included. No such attribute exists today. If a small BGP peers = create a =93killer application=94 that uses a 6000 byte attribute, the rest of = the Internet does not have to use it. However, the person defining that attribute must carefully specify it must go with Extended BGP messages.=20 =20 =20 [Bruno] I don=92t think that I agree with this. E.g. I don=92t see where = RFCs 1997 or 8092 [(large)community] limits the size of their attribute. = Hence I don=92t see why you could not have, today (with Extended Message = support) , attributes larger than 4096 octets. Most probably same status for the = BGPSec attribute since they wanted for more space. [Sue]: You make a good point about the possibility of large communities = not limiting the size. It is worthy of a change to both the large = communities and a footnote in Randy=92s specification. How about the addition of a = single sentence to point people in the right direction.=20 =20 Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed = if it=20 sent in Extended message is a large community attribute with 1000 communities.=20 (12,000 bytes). =20 / =20 =20 This text was added during an earlier discussion where the error cases = of a large BGP attribute was given. The originator of the common could not provide the exact description, but we agreed to put this =93warning = label=94 into the draft. This is one of the cases where adding/removing text = gets to be problematic.=20 =20 >--- >=93 It is RECOMMENDED that BGP protocol developers and implementers = are > conservative in their application and use of Extended Messages.=94 >=20 >What does this mean exactly? That they don=92t use this extension?=20 >That they don=92t use this extension unless XX_TO BE SPECIFIED_XX? =20 This warning was text that other participants asked to be added.=20 =20 It is a common sense warning. Extended messages are enabled on a peer = by peer basis as all BGP capabilities are. If you run into a Peer that = does not support the larger sizes, the BGP messages will need to be = reformatted to the smaller size. Running immediately to the Extended messages as = the default could cause problems.=20 =20 [Bruno] I think that the sentence could be elaborated. Indicating the problem, how the specification partially address it, and how the specification does not address it. In =93Running immediately to Extended Message=94 I don=92t think they = that the issue is with =93immediately=94. Whenever you start the transition, your = likely to run into problems. =20 =20 [Sue]: IMHO specification specifies how to encode the bytes on the wire = and the appropriate error handling of the messages. If I have missed = something in this case, please let me know.=20 =20 The specification does not specify the necessary policies implementation should have in order to decide what to do in the case of mixed network. The clear indication was this type was not appropriate for the protocol specification. =20 =20 Earlier discussion indicated that these is policy and mechanism = specific. It is worthy of =93use case or application notes=94 written for specific applications (BESS, SPRING, GROW), but not in the specification. Again, = if it is significant enough concern for operators and implementers =96 it = would be worthy to have combined use case document besides this point. = I=92m happy to sponsor cross-area work on this use case.=20 =20 --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages. =20 >Why is this limited to future specifications? A priori, using existing = BGP mechanism (AFI/SAFI, attributes, * >communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = ?>case? This should be described in this specification. Note that this is not a = case of error handling, as every BGP=20 > speaker is behaving as specified. =20 I fail to see your logic. At this point, all BGP data (AFI/SAFI and attributes) must fit within a 4096 message. Therefore, a BGP peer A = which connects on link 1 to BGP peer B with 4096 message and on link to a BGP = peer C with extended messages only has to worry about reformatting the data. = =20 In the future, the first group that defines attribute or an NLRI that = does not fit within a 4096 BGP message and cannot be split, will need to = define how that works in the specification. There is no need to refine the = current set of specifications. =20 [Bruno] 1) cf above, I believe that there are existing BGP Attributes which may = not fit into a bytes 4096 BGP message 2)Even in the absence of such attribute, you have the issue of 2 smaller attributes whose cumulative size does not fit into a 4096 bytes message. =20 The problem is introduced by this specification, hence I believe this specification needs to specify how to handle this case. =20 [Sue]: IHMO the message transmission and reception error handling = issues are complete in the combination of RFC4271 and the extended message = section 5.=20 =20 What is not in this specification is the policy issues about what = happens if you combine 2 smaller attributes. For example, if you have a large community attribute of 400 communities (4800 bytes), you will likely run into problems when combining with some longer AS path lengths. [4800=E0 = 5096 bytes is a short jump]. People on the list and in-person argued this was policy and implementation specific details. =20 =20 I agree with you that it is extremely useful to the operator community = to have this type of policy details discussed to see if there is some = desire to have common policies and error communities. It is the type of thing = that GROW and IDR should be deeply involved for large communities. BESS, = LSVR, SPRING and others should consider what policy should be adapted for = their applications.=20 =20 >---- >Depending on the above specification, a section describing the = operational consequences in a network (such as the >Internet, BGP Enabled = ServiceS/VPN networks) is probably needed. Possible consequences could be BGP NLRI = >being removed in the middle of such network, or (extended) community (such as Route Targets) been removed. >Both having significant consequences on = the availability provided by the network. =20 At this point, there are no attributes or NLRI groupings that do not fit within 4096. If you define one (as SIDR did), then you will need to = have it reviewed by IDR, BESS, SPRING, and operational groups (GROW, etc).=20 [Bruno] no, cf above. [Sue]: Thank you for reminding me of the potential of large communities = to blow up BGP. I have a new worry to add to my BGP concerns list!=20 =20 Thanks, --Bruno =20 =20 --- >=A74 >OLD: The Extended Message Capability only applies to all messages = except for the >OPEN message.=20 >Probably >NEW: The Extended Message Capability applies to all message types = except for the >OPEN message (type 1).=20 >---- >=A78 >=93This extension to BGP does not change BGP's underlying security = issues =BB >Before evaluating this, I think this document should first specified = how a BGP=20 >messages bigger than 4096 octets is handled when it needs to be sent to = a=20 >received not supporting this extension. =20 Nits: >OLD : to reduce compexity >NEW : to reduce complexity =20 Thanks, --Bruno =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org Subject: [Idr] WG Last Call on Extened Message Support =20 =20 This begins a 2 week WG LC on Extended Message Support for BGP (draft-ietf-idr-bgp-extended-messages-27). You can access the draft at: = =20 = https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ =20 The authors should indicate whether they know of any IPR. Implementers = are encouraged to update the implementation data at:=20 =20 =20 https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ati ons =20 The draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages. BGP message space is running short = for all of the potential attributes or additions proposed by BGP-LS = features. =20 =20 The WG chairs intend to forward this draft to the IESG with the current level of implementation. =20 =20 As you comment on the draft, please consider if: a) the technology is mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for publication. =20 =20 Sue Hares (WG Chair, Shepherd)=20 =20 =20 _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. ------=_NextPart_000_00CA_01D4C45F.A6680880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno:

 

Thank you for careful considerations on the use case.=A0=A0 I think = we have translation issues between our “English” language = again so I have tried to be precise in the detailed comments. = =A0I’ve summarized my comments as well to help us take the next = step.

 

Sue

 

Summary

----

Good catch on the 1000 large BGP communities blowing up the message = size! =A0This is a case where a code path could get caught with program = error.=A0 The error handling (section 6.1 in RFC4271 per section 5 in = the extended specification) IMHO handles the case where the attribute is = longer than the message.=A0 =A0Please let me know if I’ve missed = something. =A0=A0

 

As I understand it, =A0you are asking this specification to be = expanded to add notes on policies on what implementation should do to = correctly combine RFC4271 length sizes with extended length sizes.=A0=A0 = The implementers and operations people commented earlier that this = should not be in the protocol specification other than as a brief = footnote.=A0

 

I agree there is a need for such standardization as BCPs for = particular use cases (large communities, BESS (EVPN or centralized = controller), SPRING, BGP-LS information (see Daylight comments = yesterday), SD-WANs (rtgwg), and SPRING.=A0 =A0I think the chairs of the = WGs utilizing should consider if there is need for standardization for a = minimal set of policy for message sizes for specific use cases.=A0=A0 I = will be glad to send request to these WG or to host something in IDR if = there is policy that can be used across all use cases. =

 

To provide a slight expansion to point people in this direction, how = about this change to paragraph in section 4:

 

Old/

=A0=A0 = A BGP announcement will, in the normal case, propagate throughout = the

=A0=A0 = BGP speaking Internet; and there will undoubtedly be BGP = speakers

=A0=A0 = which do not have the Extended Message capability.=A0 = Therefore,

=A0=A0 = putting an attribute which can not be decomposed to 4096 octets = or

=A0=A0 = less in an Extended Message is a likely path to routing = failure.

/

New/

=A0=A0 = A BGP announcement will, in the normal case, propagate throughout = the

=A0=A0 = BGP speaking Internet; and there will undoubtedly be BGP = speakers

=A0=A0 = which do not have the Extended Message capability.=A0 = Therefore,

=A0=A0 = putting an attribute which cannot be decomposed to 4096 octets = or

=A0=A0 = less in an Extended Message is a likely path to routing = failure.

=A0=A0 = One example of a valid attribute which cannot be precisely decomposed if = it

=A0=A0=A0sent in Extended message is a large community = attribute with 1000 communities.

=A0=A0=A0(12,000 bytes).=A0

/

[PS = – in American English “Can not” is normally = concatenated “cannot”.]

=A0=A0=A0

 

 

 

From:= = bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] =
Sent: Thursday, February 14, 2019 3:29 AM
To: Susan = Hares
Cc: idr@ietf.org; 'Jakob Heitz = (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message = Support

 

Sue,

 

Thanks for the reply. Please see inline = [Bruno]

 

From:= Susan = Hares [mailto:shares@ndzh.com]
Sent: Wednesday, February 13, = 2019 8:03 PM
To: DECRAENE Bruno TGI/OLN
Cc: = idr@ietf.org; 'Jakob Heitz (jheitz)'
Subject: RE: [Idr] WG = Last Call on Extened Message Support

 

Bruno:

 

I’d like to answer some of the questions you sent Randy based = on comments (public and private) the chairs and I as the shepherd = received on this draft in our last WG LCs. =   

 

Several of the comments you questioned were put in to answer other = questions.   This gets into a catch-22… problem – = where you put changes in for one person/take out the changes out for = another.  In academic circles this is called the reviewer #2 = problem (reviewer 1 insists changes go in, reviewer 2 insists changes go = out) during publication.  Therefore, I’m I am going to answer = most of your questions where this is the case.  =

 

I believe that Randy has new version with the changes I’ve = indicated.  I’m hoping he’ll just post that = version.  AFAILK, we do have 2 compliant implementations. =

 

Sue

 

 

 

<shepherd hat on>

This draft’s technology provides efficient processing for some = application by allow a huge BGP message size.  Whether = “chunking” BGP to 4096 byte messages or packing large = amounts of data into 65,000 byte message is more effective for a = particular application is something only an implementer of a particular = BGP implementation  can decide.   This draft simply gives = freedom for applications to not be restrict to an artificially small = message size.  The market place will choose whether this technology = is used or not. 

 

As Jakob pointed out, changing a highly tuned BGP implementation = which “chunks” BGP data into 4096 byte messages may involve = substantial rework of the implementation. 

 

 

(snip)

From: Idr = <idr-bounces@ietf.org> On Behalf Of = bruno.decraene@orange.com
Sent: 29 January 2019 = 13:33
To: Susan Hares <shares@ndzh.com>
Cc: = idr@ietf.org
Subject: Re: [Idr] WG Last Call on Extened = Message Support

 

Hi = WG,

 

>Please find = below some comments.

>As of today, = I don’t believe this specification is ready to be progressed to = IESG/RFC, especially for a document >updating RFC 4271 (core BGP = spec).

 

&= gt; The WG chairs intend to forward this draft to the IESG with the = current level of implementation. 

 

>https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp= -extended->implementations says : 5a =

Does not send Extended Message capability =

Yes

Yes

Yes =

 

>I may be = misunderstanding the implementation report, but my reading of the above = is that none of the reported >implementations sends the capability = hence no implementation supports draft-ietf-idr-bgp-extended-messages.. =

>Here this = document is updating RFC 4271, so it is not a minor extension for a = niche use case. So I don’t see the >arguments for not requiring the = IDR’s usual two interoperable = implementations.

 

>In our mail thread, we discovered that the implementation report = should have indicate

>full support.   I’m waiting for Olivier to update = based on the last point, but my understanding is that =

All implementations have full support.  

 

[Bruno] ok, solved

>----

>=A7 = 1

>“ As BGP is = extended to support newer AFI/SAFIs and

>   newer = capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there = is

>   a need = to extend the maximum message size beyond 4096 octets.  = “

> 

> = https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-mes= sages-27#section-1

 

 

>[I-D.ietf-sidr-bgpsec-protocol is now RFC = 8205 (thanks for updating the reference). It has removed the = normative/any >reference to = draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not = need draft-ietf-idr-bgp->extended-messages. Can we have an update on this?  Can the introduction of draft-ietf-idr-bgp-extended-messages >be = updated to introduce on the real = reasons/needs?

 

SIDR gave up waiting on IDR’s work and took a reduced size of = encryption.   The security people were very sad about the = reduction.  How is this working in practice? WG sidrops can answer = this question. 

 

The real problem is there is finite message space.  =

[Bruno] So too bad the draft does not solve the real problem ;-) (as = message space is still limited)

 

[Sue]: The message is still finite (smile), =A0but I hope 65,635 = (smile) is probably enough for 10 years.=A0 =A0

 

There are two ways to send lots of BGP routes and/or attributes = – to “chunk” these into small message sizes or place = these into a large message.    Some applications may = always want to “chunk” into message sizes smaller than = 4096.   Some application make work more efficiently utilizing = large message size.  As the potential number of NLRI and BGP = attributes grows, new applications may consider large message sizes to a = more reasonable way to exchange amounts of BGP data.   =  

 

The decision on how to send BGP messages over the wire is a = peer-by-peer decision in a network.   Each BGP peer is in = charge of reformatting the BGP message it sends to the remote BGP = peer.   The BGP capabilities in this draft represent an = agreement between two BGP peers.  These are facts of basic BGP = implementations

[Bruno] Let’s take the example of a BGP Route Reflector having = a mixed of clients, some supporting Extend Message (EM) and some = not.

From an EM client, it receives a BGP update containing one (single) = NLRI with an Total Path Attribute Length bigger than=A0 4090 byte (e.g. = having 1000 large communitiess)

Can you explain me how it behaves to send this NLRI to an IBGP peer = not supporting EM?

[Sue]:=A0 Gladly…

A BGP route reflector (RR-A) is peering with each of its BGP = clients.=A0 =A0It agrees with each of its clients (BGP-C1, BGPC2, BGPC3) = whether the BGP Extended messages is accepted or not (based on = capability announcement).

Let us assume that BGP-C1 does not support extended messages, and = =A0BGP-C2 and BGP-C3 do support extended messages. =

 

If the policy in RR accepts a total path length of 1000 large = communities with =A0a single NLRI, it may send the BGP attribute via = extended communities to BGP-C2 and = BGP-C2.

The policy in the RR must specify whether: =

a)      = the “too long” attribute path length must be dropped, or =

b)      = the BGP attribute path can be truncated. =

 

This is a policy issue within the BGP peer and the network operation = staff. =A0Each operator may choose to write this policy differently. =

 

Rather than specify the numerous cases in the protocol specification, = =A0the previous discussions (private and public) asked us to trim this = information out of the protocol specification. =

 

If you believe this is worthy of a use case draft for the sake of = BESS, LSVR, SPRING, Grow and others, I will happily WG chair sponsor a = draft that can be reviewed by all these WGs. =

 

 

– so I do not believe adding these facts to Randy’s draft = is useful.  In fact, in the previous rounds of review this point = was made.

 

Your question (and perhaps Jakob’s) is whether we have reached = a time/place where the “chunking” approach will fail on a = peer-by-peer basis?   This draft does not make this = statement. 

 

The point of this draft is to enable more efficient processing by = increasing the message size for BGP peers that send a lot of data (e.g. = BGP-LS) .   The choice to “chunk” or stream in = large BGP message is an implementation choice for a particular BGP = application. 

<= o:p> 

----

=A74

=A73 says =
“A peer which does not advertise this capability MUST NOT send =
BGP

  =  Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.”<= /o:p>

[I believe randy accepted this change with the following text in = version 4 [upcoming below]]/.

 

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

<= o:p> 

F= ine. Text in =A74 should probably be aligned with the above = .e.g.

O=
LD: A =
BGP speaker

   MAY = send Extended Messages to its peer only if it has received = the

   = Extended Message Capability from that peer.

<= o:p> 

N= EW:

A BGP = speaker

   MAY = send Extended Messages to its peer only if it has sent and received = the

   = Extended Message Capability to and from that = peer.

 

 

----

>&=
#8220;   Applications generating information which might be =
encapsulated

>   within = BGP messages MUST limit the size of their payload to take = the

>   = maximum message size into account.”

> 

>I = don’t see what new behavior is been defined here. If there is = none, I would suggest to remove this sentence

 

Bruno – people asked to put this text in as an operational = warning.  At this point, I’m going to say unless there is = harm it should remain. 

[Bruno] OK.

<= o:p> 

-= ---

>   A BGP = announcement will, in the normal case, propagate throughout = the

>   BGP = speaking Internet; and there will undoubtedly be BGP = speakers

>   which = do not have the Extended Message capability.  = Therefore,

>   = putting an attribute which can not be decomposed to 4096 octets = or

>   less = in an Extended Message is a likely path to routing = failure.

><= o:p> 

>T= he issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than >4= 096, irrespective of the size of each attribute.

>P= lease elaborate on what you mean by

> 

>&= #8220;an attribute which cannot be decomposed to 4096 octets”

 

An attribute which cannot be decomposed to 4096 is an attribute with = length 6000 inside of a BGP message which requires the entire attribute = to be included.   No such attribute exists today.  =  If a small BGP peers create a “killer application” = that uses a 6000 byte attribute, the rest of the Internet does not have = to use it.   However, the person defining that attribute must = carefully specify it must go with Extended BGP messages. =

 

 

[Bruno] I don’t think that I agree with this. E.g. I = don’t see where RFCs 1997 or 8092 [(large)community] limits the = size of their attribute. Hence I don’t see why you could not have, = today (with Extended Message support) , attributes larger than 4096 = octets. Most probably same status for the BGPSec attribute since they = wanted for more space.

[Sue]: You make a good point about the possibility of large = communities not limiting the size.=A0 It is worthy of a change to both = the large communities and a footnote in Randy’s specification. = =A0How about the addition of a single sentence to point people in the = right direction.

 

Old/

=A0=A0 = A BGP announcement will, in the normal case, propagate throughout = the

=A0=A0 = BGP speaking Internet; and there will undoubtedly be BGP = speakers

=A0=A0 = which do not have the Extended Message capability.=A0 = Therefore,

=A0=A0 = putting an attribute which can not be decomposed to 4096 octets = or

=A0=A0 = less in an Extended Message is a likely path to routing = failure.

/

New/

=A0=A0 = A BGP announcement will, in the normal case, propagate throughout = the

=A0=A0 = BGP speaking Internet; and there will undoubtedly be BGP = speakers

=A0=A0 = which do not have the Extended Message capability.=A0 = Therefore,

=A0=A0 = putting an attribute which cannot be decomposed to 4096 octets = or

=A0=A0 = less in an Extended Message is a likely path to routing = failure.

=A0=A0 = One example of a valid attribute which cannot be precisely decomposed if = it

=A0=A0=A0sent in Extended message is a large community = attribute with 1000 communities.

=A0=A0=A0(12,000 bytes).=A0

/

=A0 =

 

This text was added during an earlier discussion where the error = cases of a large BGP attribute was given.  The originator of the = common could not provide the exact description, but we agreed to put = this  “warning label” into the draft.   This = is one of the cases where adding/removing text gets to be problematic. =

 <= o:p>

>-= --

>“   = It is RECOMMENDED that BGP protocol developers and implementers = are

>   = conservative in their application and use of Extended = Messages.”

> 

>What does = this mean exactly? That they don’t use this extension?

>That they = don’t use this extension unless XX_TO BE SPECIFIED_XX?

 

This warning was text that other participants asked to be added. =

 

It is a common sense warning.  Extended messages are enabled on = a peer by peer basis as all BGP capabilities are.  If you run into = a Peer that does not support the larger sizes, the BGP messages will = need to be reformatted to the smaller size.   Running = immediately to the Extended messages as the default could cause = problems.

 

[Bruno] I think that the sentence could be elaborated. Indicating the = problem, how the specification partially address it, and how the = specification does not address it.

In “Running immediately to Extended Message” I = don’t think they that the issue is with “immediately”. = Whenever you start the transition, your likely to run into = problems.

 

 

[Sue]: IMHO specification specifies how to encode the bytes on the = wire and the appropriate error handling of the messages.=A0 =A0If I have = missed something in this case, please let me know. =

 

The specification does not specify the necessary policies = implementation should have in order to decide what to do in the case of = mixed network.=A0 =A0The clear indication was this type was not = appropriate for the protocol specification. = =A0

 

Earlier discussion indicated that these is policy and mechanism = specific.=A0 It is worthy of “use case or application notes” = written for specific applications (BESS, SPRING, GROW), but not in the = specification.=A0 Again, if it is significant enough concern for = operators and implementers – it would be worthy to have combined = use case document besides this point. =A0=A0=A0I’m happy to = sponsor cross-area work on this use case. =

 

-= --

  Future = protocol specifications will need to describe how to = handle

   peers = which can only accommodate 4096 octet messages.

<= o:p> 

>Why is this = limited to future specifications? A priori, using existing BGP mechanism = (AFI/SAFI, attributes, * >communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = ?>case? This should be described = in this specification. Note that this is not a case of error handling, = as every BGP

> speaker is = behaving as specified.

 

I fail to see your logic.  At this point, all BGP data (AFI/SAFI = and attributes) must fit within a 4096 message.   Therefore, a = BGP peer A which connects on link 1 to BGP peer B with 4096 message and = on link to a BGP peer C with extended messages only has to worry about = reformatting the data. 

 

In the future, the first group that defines attribute or an NLRI that = does not fit within a 4096 BGP message and cannot be split, will need to = define how that works in the specification.  There is no need to = refine the current set of specifications.   =

[Bruno]

1) cf above, I believe that there are existing BGP Attributes which = may not fit into a bytes 4096 BGP = message

2)Even in the absence of such attribute, you have the issue of 2 = smaller attributes whose cumulative size does not fit into a 4096 bytes = message.

 

The problem is introduced by this specification, hence I believe this = specification needs to specify how to handle this = case.

 

[Sue]: =A0IHMO the message transmission and reception error handling = issues are complete in the combination of RFC4271 and the extended = message section 5.

 

What is not in this specification is the policy issues about what = happens if you combine 2 smaller attributes.=A0 For example, if you have = a large community attribute of 400 communities (4800 bytes), you will = likely run into problems when combining with some longer AS path = lengths.=A0 [4800=E0= 5096 bytes is a short jump]. People on the list and in-person argued = this was policy and implementation specific details.=A0 =

 

I agree with you that it is extremely useful to the operator = community to have this type of policy details discussed to see if there = is some desire to have common policies and error communities. =A0=A0It = is the type of thing that GROW and IDR should be deeply involved for = large communities.=A0 =A0BESS, LSVR, SPRING and others should consider = what policy should be adapted for their applications. =

 

>-= ---

>D= epending on the above specification, a section describing the = operational consequences in a network (such as the >I= nternet, BGP Enabled ServiceS/VPN networks) is probably needed. Possible = consequences could be BGP NLRI >b= eing removed in the middle of such network, or (extended) community = (such as Route Targets) been removed. >B= oth having significant consequences on the availability provided by the = network.

 

At this point, there are no attributes or NLRI groupings that do not = fit within 4096.   If you define one (as SIDR did), then you = will need to have it reviewed by IDR, BESS, SPRING, and operational = groups (GROW, etc). 

[Bruno] no, cf above.

[Sue]: =A0Thank you for reminding me of the potential of large = communities to blow up BGP. =A0I have a new worry to add to my BGP = concerns list!

 

Thanks,

--Bruno

 

<= o:p> 

-= --

>=A7= 4

>OLD: The Extended = Message Capability only applies to all messages except for the >OPEN message. =

>Probably

>NEW: The Extended = Message Capability applies to all message types except for the >OPEN message (type 1). =

>----

>=A78

>“This =
extension to BGP does not change BGP's underlying security =
issues =BB
>Before evaluating =
this, I think this document should first specified how a BGP 
>messages bigger =
than 4096 octets is handled when it needs to be sent to a 
>received not supporting this extension.

 

N= its:

>OLD : to = reduce compexity

>NEW : to = reduce complexity

 

T= hanks,

-= -Bruno

<= o:p> 

From:= Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Tuesday, January 29, = 2019 12:33 PM
To: idr@ietf.org
Subject: [Idr] = WG Last Call on Extened Message = Support

 

<= o:p> 

T= his begins a 2 week WG LC on Extended Message Support for BGP = (draft-ietf-idr-bgp-extended-messages-27).  You can access the = draft at:

<= o:p> 

https://datat= racker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/<= o:p>

<= o:p> 

T= he authors should indicate whether they know of any IPR.   = Implementers are encouraged to update the  implementation data at: =

<= o:p> 

https://trac.= ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations= <= o:p>

<= o:p> 

T= he draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages.  BGP message space is = running short for all of the potential attributes or additions proposed = by BGP-LS features. 

<= o:p> 

T= he WG chairs intend to forward this draft to the IESG with the current = level of implementation. 

<= o:p> 

A= s you comment on the draft, please consider if: a) the technology is = mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for = publication. 

<= o:p> 

S= ue Hares (WG Chair, Shepherd)

<= o:p> 

 = 

_________________________=
_________________________________________________________________________=
_______________________
 <=
/pre>
Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 <=
/pre>
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received =
this email in error, please notify the sender and delete this message =
and its attachments.
As emails may be =
altered, Orange is not liable for messages that have been modified, =
changed or falsified.
Thank =
you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received this =
email in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, =
Orange is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles =
d'alteration,
Orange decline =
toute responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This =
message and its attachments may contain confidential or privileged =
information that may be protected by =
law;
they should not be =
distributed, used or copied without =
authorisation.
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments.
As emails may be altered, Orange is not liable for messages =
that have been modified, changed or =
falsified.
Thank =
you.
------=_NextPart_000_00CA_01D4C45F.A6680880-- From nobody Thu Feb 14 09:34:43 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8530F12867A for ; Thu, 14 Feb 2019 09:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PG6sXhy7F56R for ; Thu, 14 Feb 2019 09:34:37 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA891200ED for ; Thu, 14 Feb 2019 09:34:36 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id h28so242958qkk.7 for ; Thu, 14 Feb 2019 09:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B64VmWRVbiM4niB8Gzu2Qsuuj1dMiuTfAZaLArE7XHo=; b=bcLgfDYM9J/UO63YZa6OyM76J4WZxZC2NIUlt6mo+ZFZmChUhtvpQgChVzqWp16XRr KXUmZ0QWZtPxGRtLNkkHXfdjlm2LitqB+40o/cdtQAn/CXu8HPuy9A7C9mx5I04H4mNM zt6021/m/pOY0/KPEbtjQtTfSZv0JFAuDyS2Gxxl9Q1btIRsudanpUkq6ngVztPxYthU 2bzjiFcZFsFCS+cEciL+UOehYRF+nv+OwuvBgBN5WUhnIEsrUkS/8lTv+C/C1ChbOK3J gqo/sC5oLCD+SmlfNosO9OZRW3sTw8/8JNwvdZ5f7cJYJoQMnhhk8Z3SH7wkAqegqssq IgHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B64VmWRVbiM4niB8Gzu2Qsuuj1dMiuTfAZaLArE7XHo=; b=MG1cR4G/5/gQQcftL+k8GTDVOONbQsTaG9EYnm4Ci5bt81a/WLZWgan+1u+SgaY3ZJ 5KDipDDlH5NIiu35NfO+Gf1KJtG9If86SfPKH457CswpNUaQ/Xnn7PIR3r4D6W4gRO3O Se5ujjxLND68zf5y3O0z7O3VW7B4wu5UYit9ItMXVeQTnWGHwIz2jHl/ZgrzHdCcOqjH OS4qoKusuAhwcaCMpTS3cnOHjWb3HGwBqzmLhwgtFl40kdwAn4sxNat+9W5dWn7l9CPi EabELlBh+47P8HpMNlgWPh5KmgfrbKxkW+tb/KAIwc8hT1dW4MB/ccMZrK6ubS+NcjLP YaJg== X-Gm-Message-State: AHQUAuZS5QTH/hmxfUjvCVSxF7p8G5iUJdIZhIIkna40u8eLRaPcoFFz CsgVa91eMPZMNpLf75BguQ2ShGvph796L+4DzgAi3e6W3EM= X-Google-Smtp-Source: AHgI3Ia6U4phpRhwyKzICDYA1qMloLU6AE88pzsB6xToEO95F3xXtj4bYV0FI90T4H7UHP3BefU9DYSz91aPXdwayS4= X-Received: by 2002:a37:4a87:: with SMTP id x129mr3718867qka.142.1550165675338; Thu, 14 Feb 2019 09:34:35 -0800 (PST) MIME-Version: 1.0 References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk> <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> <17281_1550132953_5C6526D9_17281_161_1_53C29892C857584299CBF5D05346208A489D3D92@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <00c901d4c489$8f311830$ad934890$@ndzh.com> In-Reply-To: <00c901d4c489$8f311830$ad934890$@ndzh.com> From: Robert Raszuk Date: Thu, 14 Feb 2019 18:34:20 +0100 Message-ID: To: Susan Hares Cc: Bruno Decraene , "idr@ietf. org" Content-Type: multipart/alternative; boundary="0000000000006c02b10581de1238" Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 17:34:42 -0000 --0000000000006c02b10581de1238 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Sue & authors of this proposal, > Therefore, putting an attribute which cannot be decomposed to > 4096 octets or less in an Extended Message is a likely path to > routing failure. That's brilliant statement but not enough to proceed with this spec. See the fundamental change that today such issue is in vast majority of cases locally significant. That means that if I send NLRI to BGP it will have a decent chance to be received by all intended parties. With new spec we are saying that it may silently fail somewhere in the middle and we do not do anything about it. That's to me showstopper. At min if given NLRI can not be sent with XXL attributes to some peers (say on the RR which Bruno mentioned) we must specify protocol extension in this very spec on how to deal with it. Such extension may be as simple as to define a short attribute BGP_PIPE_TOO_THIN which will be inserted in the place where XXL attribute just did not fit smaller message size peers to tell them then "Hey something is broken with this NLRI" - pls check. Then it will be up to local policy to install such NLRI or drop it. Thx, R. On Thu, Feb 14, 2019 at 6:21 PM Susan Hares wrote: > Bruno: > > > > Thank you for careful considerations on the use case. I think we have > translation issues between our =E2=80=9CEnglish=E2=80=9D language again s= o I have tried to > be precise in the detailed comments. I=E2=80=99ve summarized my comments= as well > to help us take the next step. > > > > Sue > > > > Summary > > ---- > > Good catch on the 1000 large BGP communities blowing up the message size! > This is a case where a code path could get caught with program error. Th= e > error handling (section 6.1 in RFC4271 per section 5 in the extended > specification) IMHO handles the case where the attribute is longer than t= he > message. Please let me know if I=E2=80=99ve missed something. > > > > As I understand it, you are asking this specification to be expanded to > add notes on policies on what implementation should do to correctly combi= ne > RFC4271 length sizes with extended length sizes. The implementers and > operations people commented earlier that this should not be in the protoc= ol > specification other than as a brief footnote. > > > > I agree there is a need for such standardization as BCPs for particular > use cases (large communities, BESS (EVPN or centralized controller), > SPRING, BGP-LS information (see Daylight comments yesterday), SD-WANs > (rtgwg), and SPRING. I think the chairs of the WGs utilizing should > consider if there is need for standardization for a minimal set of policy > for message sizes for specific use cases. I will be glad to send reques= t > to these WG or to host something in IDR if there is policy that can be us= ed > across all use cases. > > > > To provide a slight expansion to point people in this direction, how abou= t > this change to paragraph in section 4: > > > > Old/ > > A BGP announcement will, in the normal case, propagate throughout the > > BGP speaking Internet; and there will undoubtedly be BGP speakers > > which do not have the Extended Message capability. Therefore, > > putting an attribute which can not be decomposed to 4096 octets or > > less in an Extended Message is a likely path to routing failure. > > / > > New/ > > A BGP announcement will, in the normal case, propagate throughout the > > BGP speaking Internet; and there will undoubtedly be BGP speakers > > which do not have the Extended Message capability. Therefore, > > putting an attribute which cannot be decomposed to 4096 octets or > > less in an Extended Message is a likely path to routing failure. > > One example of a valid attribute which cannot be precisely decomposed > if it > > sent in Extended message is a large community attribute with 1000 > communities. > > (12,000 bytes). > > / > > [PS =E2=80=93 in American English =E2=80=9CCan not=E2=80=9D is normally c= oncatenated =E2=80=9Ccannot=E2=80=9D.] > > > > > > > > > > *From:* bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > *Sent:* Thursday, February 14, 2019 3:29 AM > *To:* Susan Hares > *Cc:* idr@ietf.org; 'Jakob Heitz (jheitz)' > *Subject:* RE: [Idr] WG Last Call on Extened Message Support > > > > Sue, > > > > Thanks for the reply. Please see inline [Bruno] > > > > *From:* Susan Hares [mailto:shares@ndzh.com] > *Sent:* Wednesday, February 13, 2019 8:03 PM > *To:* DECRAENE Bruno TGI/OLN > *Cc:* idr@ietf.org; 'Jakob Heitz (jheitz)' > *Subject:* RE: [Idr] WG Last Call on Extened Message Support > > > > Bruno: > > > > I=E2=80=99d like to answer some of the questions you sent Randy based on = comments > (public and private) the chairs and I as the shepherd received on this > draft in our last WG LCs. > > > > Several of the comments you questioned were put in to answer other > questions. This gets into a catch-22=E2=80=A6 problem =E2=80=93 where y= ou put changes in > for one person/take out the changes out for another. In academic circles > this is called the reviewer #2 problem (reviewer 1 insists changes go in, > reviewer 2 insists changes go out) during publication. Therefore, I=E2= =80=99m I am > going to answer most of your questions where this is the case. > > > > I believe that Randy has new version with the changes I=E2=80=99ve indica= ted. I=E2=80=99m > hoping he=E2=80=99ll just post that version. AFAILK, we do have 2 compli= ant > implementations. > > > > Sue > > > > > > > > > > This draft=E2=80=99s technology provides efficient processing for some ap= plication > by allow a huge BGP message size. Whether =E2=80=9Cchunking=E2=80=9D BGP= to 4096 byte > messages or packing large amounts of data into 65,000 byte message is mor= e > effective for a particular application is something only an implementer o= f > a particular BGP implementation can decide. This draft simply gives > freedom for applications to not be restrict to an artificially small > message size. The market place will choose whether this technology is us= ed > or not. > > > > As Jakob pointed out, changing a highly tuned BGP implementation which > =E2=80=9Cchunks=E2=80=9D BGP data into 4096 byte messages may involve sub= stantial rework of > the implementation. > > > > > > *(snip) * > > *From:* Idr *On Behalf Of * > bruno.decraene@orange.com > *Sent:* 29 January 2019 13:33 > *To:* Susan Hares > *Cc:* idr@ietf.org > *Subject:* Re: [Idr] WG Last Call on Extened Message Support > > > > Hi WG, > > > > >Please find below some comments. > > >As of today, I don=E2=80=99t believe this specification is ready to be > progressed to IESG/RFC, especially for a document >updating RFC 4271 > (core BGP spec). > > > > > The WG chairs intend to forward this draft to the IESG with the current > level of implementation. > > > > > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended->implemen= tations > says : 5a > > Does not send Extended Message capability > > Yes > > Yes > > Yes > > > > >I may be misunderstanding the implementation report, but my reading of > the above is that none of the reported >implementations sends the > capability hence no implementation supports > draft-ietf-idr-bgp-extended-messages.. > > >Here this document is updating RFC 4271, so it is not a minor extension > for a niche use case. So I don=E2=80=99t see the >arguments for not requi= ring the > IDR=E2=80=99s usual two interoperable implementations. > > > > >In our mail thread, we discovered that the implementation report should > have indicate > > >full support. I=E2=80=99m waiting for Olivier to update based on the l= ast > point, but my understanding is that > > All implementations have full support. > > > > *[Bruno] ok, solved* > > >---- > > >=C2=A7 1 > > >=E2=80=9C As BGP is extended to support newer AFI/SAFIs and > > > newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol > ]), > there is > > > a need to extend the maximum message size beyond 4096 octets. =E2=80= =9C > > > > > > > https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on-1 > > > > > > >[I-D.ietf-sidr-bgpsec-protocol > is > now RFC 8205 (thanks for updating the reference). It has removed the > normative/any >reference to draft-ietf-idr-bgp-extended-messages. So > presumably BGP Sec does not need draft-ietf-idr-bgp->extended-messages. C= an > we have an update on this? Can the introduction of draft-ietf-idr-bgp-ex= tended-messages > >be updated to introduce on the real reasons/needs? > > > > SIDR gave up waiting on IDR=E2=80=99s work and took a reduced size of > encryption. The security people were very sad about the reduction. How > is this working in practice? WG sidrops can answer this question. > > > > The real problem is there is finite message space. > > *[Bruno] So too bad the draft does not solve the real problem ;-) (as > message space is still limited)* > > > > [Sue]: The message is still finite (smile), but I hope 65,635 (smile) is > probably enough for 10 years. > > > > There are two ways to send lots of BGP routes and/or attributes =E2=80=93= to > =E2=80=9Cchunk=E2=80=9D these into small message sizes or place these int= o a large > message. Some applications may always want to =E2=80=9Cchunk=E2=80=9D = into message sizes > smaller than 4096. Some application make work more efficiently utilizin= g > large message size. As the potential number of NLRI and BGP attributes > grows, new applications may consider large message sizes to a more > reasonable way to exchange amounts of BGP data. > > > > The decision on how to send BGP messages over the wire is a peer-by-peer > decision in a network. Each BGP peer is in charge of reformatting the B= GP > message it sends to the remote BGP peer. The BGP capabilities in this > draft represent an agreement between two BGP peers. These are facts of > basic BGP implementations > > *[Bruno] Let=E2=80=99s take the example of a BGP Route Reflector having a= mixed of > clients, some supporting Extend Message (EM) and some not.* > > *From an EM client, it receives a BGP update containing one (single) NLRI > with an Total Path Attribute Length bigger than 4090 byte (e.g. having > 1000 large communitiess)* > > *Can you explain me how it behaves to send this NLRI to an IBGP peer not > supporting EM?* > > *[Sue]: Gladly=E2=80=A6 * > > *A BGP route reflector (RR-A) is peering with each of its BGP clients. > It agrees with each of its clients (BGP-C1, BGPC2, BGPC3) whether the BG= P > Extended messages is accepted or not (based on capability announcement). = * > > *Let us assume that BGP-C1 does not support extended messages, and BGP-C= 2 > and BGP-C3 do support extended messages. * > > > > *If the policy in RR accepts a total path length of 1000 large communitie= s > with a single NLRI, it may send the BGP attribute via extended communiti= es > to BGP-C2 and BGP-C2.* > > *The policy in the RR must specify whether: * > > *a) **the =E2=80=9Ctoo long=E2=80=9D attribute path length must be d= ropped, or * > > *b) **the BGP attribute path can be truncated. * > > > > *This is a policy issue within the BGP peer and the network operation > staff. Each operator may choose to write this policy differently. * > > > > *Rather than specify the numerous cases in the protocol specification, > the previous discussions (private and public) asked us to trim this > information out of the protocol specification. * > > > > *If you believe this is worthy of a use case draft for the sake of BESS, > LSVR, SPRING, Grow and others, I will happily WG chair sponsor a draft th= at > can be reviewed by all these WGs. * > > > > > > =E2=80=93 so I do not believe adding these facts to Randy=E2=80=99s draft= is useful. In > fact, in the previous rounds of review this point was made. > > > > Your question (and perhaps Jakob=E2=80=99s) is whether we have reached a > time/place where the =E2=80=9Cchunking=E2=80=9D approach will fail on a p= eer-by-peer basis? > This draft does not make this statement. > > > > The point of this draft is to enable more efficient processing by > increasing the message size for BGP peers that send a lot of data (e.g. > BGP-LS) . The choice to =E2=80=9Cchunk=E2=80=9D or stream in large BGP = message is an > implementation choice for a particular BGP application. > > > > ---- > > =C2=A74 > > =C2=A73 says =E2=80=9CA peer which does not advertise this capability MUS= T NOT send BGP > > Extended Messages, and BGP Extended Messages MUST NOT be sent to it.= =E2=80=9D > > [I believe randy accepted this change with the following text in version = 4 > [upcoming below]]/. > > > > -------------- > > > > Fine. Text in =C2=A74 should probably be aligned with the above ..e.g. > > OLD: A BGP speaker > > MAY send Extended Messages to its peer only if it has received the > > Extended Message Capability from that peer. > > > > NEW: > > A BGP speaker > > MAY send Extended Messages to its peer only if it has sent and receive= d > the > > Extended Message Capability to and from that peer. > > > > > > ---- > > >=E2=80=9C Applications generating information which might be encapsula= ted > > > within BGP messages MUST limit the size of their payload to take the > > > maximum message size into account.=E2=80=9D > > > > > >I don=E2=80=99t see what new behavior is been defined here. If there is = none, I > would suggest to remove this sentence > > > > Bruno =E2=80=93 people asked to put this text in as an operational warnin= g. At > this point, I=E2=80=99m going to say unless there is harm it should remai= n. > > *[Bruno] OK.* > > > > ---- > > > A BGP announcement will, in the normal case, propagate throughout the > > > BGP speaking Internet; and there will undoubtedly be BGP speakers > > > which do not have the Extended Message capability. Therefore, > > > putting an attribute which can not be decomposed to 4096 octets or > > > less in an Extended Message is a likely path to routing failure. > > > > > >The issue is not specific to attributes bigger than 4096 octets, but to > BGP message whose length is bigger than >4096, irrespective of the size > of each attribute. > > >Please elaborate on what you mean by > > > > > >=E2=80=9Can attribute which cannot be decomposed to 4096 octets=E2=80=9D > > > > An attribute which cannot be decomposed to 4096 is an attribute with > length 6000 inside of a BGP message which requires the entire attribute t= o > be included. No such attribute exists today. If a small BGP peers > create a =E2=80=9Ckiller application=E2=80=9D that uses a 6000 byte attri= bute, the rest of > the Internet does not have to use it. However, the person defining that > attribute must carefully specify it must go with Extended BGP messages. > > > > > > *[Bruno] I don=E2=80=99t think that I agree with this. E.g. I don=E2=80= =99t see where RFCs > 1997 or 8092 [(large)community] limits the size of their attribute. Hence= I > don=E2=80=99t see why you could not have, today (with Extended Message su= pport) , > attributes larger than 4096 octets. Most probably same status for the > BGPSec attribute since they wanted for more space.* > > *[Sue]: You make a good point about the possibility of large communities > not limiting the size. It is worthy of a change to both the large > communities and a footnote in Randy=E2=80=99s specification. How about t= he > addition of a single sentence to point people in the right direction. * > > > > Old/ > > A BGP announcement will, in the normal case, propagate throughout the > > BGP speaking Internet; and there will undoubtedly be BGP speakers > > which do not have the Extended Message capability. Therefore, > > putting an attribute which can not be decomposed to 4096 octets or > > less in an Extended Message is a likely path to routing failure. > > / > > New/ > > A BGP announcement will, in the normal case, propagate throughout the > > BGP speaking Internet; and there will undoubtedly be BGP speakers > > which do not have the Extended Message capability. Therefore, > > putting an attribute which cannot be decomposed to 4096 octets or > > less in an Extended Message is a likely path to routing failure. > > One example of a valid attribute which cannot be precisely decomposed > if it > > sent in Extended message is a large community attribute with 1000 > communities. > > (12,000 bytes). > > / > > > > > > This text was added during an earlier discussion where the error cases of > a large BGP attribute was given. The originator of the common could not > provide the exact description, but we agreed to put this =E2=80=9Cwarnin= g label=E2=80=9D > into the draft. This is one of the cases where adding/removing text get= s > to be problematic. > > > > >--- > > >=E2=80=9C It is RECOMMENDED that BGP protocol developers and implement= ers are > > > conservative in their application and use of Extended Messages.=E2=80= =9D > > > > > >What does this mean exactly? That they don=E2=80=99t use this extension? > > >That they don=E2=80=99t use this extension unless XX_TO BE SPECIFIED_XX? > > > > This warning was text that other participants asked to be added. > > > > It is a common sense warning. Extended messages are enabled on a peer by > peer basis as all BGP capabilities are. If you run into a Peer that does > not support the larger sizes, the BGP messages will need to be reformatte= d > to the smaller size. Running immediately to the Extended messages as th= e > default could cause problems. > > > > *[Bruno] I think that the sentence could be elaborated. Indicating the > problem, how the specification partially address it, and how the > specification does not address it.* > > *In =E2=80=9CRunning immediately to Extended Message=E2=80=9D I don=E2=80= =99t think they that the > issue is with =E2=80=9Cimmediately=E2=80=9D. Whenever you start the trans= ition, your likely > to run into problems.* > > > > > > *[Sue]: IMHO specification specifies how to encode the bytes on the wire > and the appropriate error handling of the messages. If I have missed > something in this case, please let me know. * > > > > *The specification does not specify the necessary policies implementation > should have in order to decide what to do in the case of mixed network. > The clear indication was this type was not appropriate for the protocol > specification. * > > > > *Earlier discussion indicated that these is policy and mechanism > specific. It is worthy of =E2=80=9Cuse case or application notes=E2=80= =9D written for > specific applications (BESS, SPRING, GROW), but not in the specification. > Again, if it is significant enough concern for operators and implementers= =E2=80=93 > it would be worthy to have combined use case document besides this point. > I=E2=80=99m happy to sponsor cross-area work on this use case. * > > > > --- > > Future protocol specifications will need to describe how to handle > > peers which can only accommodate 4096 octet messages. > > > > >Why is this limited to future specifications? A priori, using existing > BGP mechanism (AFI/SAFI, attributes, * >communities) one could exceed the > size of 4096 octets. How does the BGP speaker supposed to behave in this > ?>case? This should be described in this specification. Note that this is > not a case of error handling, as every BGP > > > speaker is behaving as specified. > > > > I fail to see your logic. At this point, all BGP data (AFI/SAFI and > attributes) must fit within a 4096 message. Therefore, a BGP peer A whi= ch > connects on link 1 to BGP peer B with 4096 message and on link to a BGP > peer C with extended messages only has to worry about reformatting the > data. > > > > In the future, the first group that defines attribute or an NLRI that doe= s > not fit within a 4096 BGP message and cannot be split, will need to defin= e > how that works in the specification. There is no need to refine the > current set of specifications. > > *[Bruno]* > > *1) cf above, I believe that there are existing BGP Attributes which may > not fit into a bytes 4096 BGP message* > > *2)Even in the absence of such attribute, you have the issue of 2 smaller > attributes whose cumulative size does not fit into a 4096 bytes message.* > > > > *The problem is introduced by this specification, hence I believe this > specification needs to specify how to handle this case.* > > > > [Sue]: IHMO the message transmission and reception error handling issues > are complete in the combination of RFC4271 and the extended message secti= on > 5. > > > > What is not in this specification is the policy issues about what happens > if you combine 2 smaller attributes. For example, if you have a large > community attribute of 400 communities (4800 bytes), you will likely run > into problems when combining with some longer AS path lengths. [4800=C3= =A0 > 5096 bytes is a short jump]. People on the list and in-person argued this > was policy and implementation specific details. > > > > I agree with you that it is extremely useful to the operator community to > have this type of policy details discussed to see if there is some desire > to have common policies and error communities. It is the type of thing > that GROW and IDR should be deeply involved for large communities. BESS= , > LSVR, SPRING and others should consider what policy should be adapted for > their applications. > > > > >---- > > >Depending on the above specification, a section describing the > operational consequences in a network (such as the >Internet, BGP Enabled > ServiceS/VPN networks) is probably needed. Possible consequences could be > BGP NLRI >being removed in the middle of such network, or (extended) > community (such as Route Targets) been removed. >Both having significant > consequences on the availability provided by the network. > > > > At this point, there are no attributes or NLRI groupings that do not fit > within 4096. If you define one (as SIDR did), then you will need to hav= e > it reviewed by IDR, BESS, SPRING, and operational groups (GROW, etc). > > *[Bruno] no, cf above.* > > *[Sue]: Thank you for reminding me of the potential of large communities > to blow up BGP. I have a new worry to add to my BGP concerns list! * > > > > *Thanks,* > > *--Bruno* > > > > > > --- > > >=C2=A74 > > >OLD: The Extended Message Capability only applies to all messages except > for the >OPEN message. > > >Probably > > >NEW: The Extended Message Capability applies to all message types except > for the >OPEN message (type 1). > > >---- > > >=C2=A78 > > >=E2=80=9CThis extension to BGP does not change BGP's underlying security= issues =C2=BB > > >Before evaluating this, I think this document should first specified how= a BGP > > >messages bigger than 4096 octets is handled when it needs to be sent to = a > > >received not supporting this extension. > > > > Nits: > > >OLD : to reduce compexity > > >NEW : to reduce complexity > > > > Thanks, > > --Bruno > > > > *From:* Idr [mailto:idr-bounces@ietf.org ] *On > Behalf Of *Susan Hares > *Sent:* Tuesday, January 29, 2019 12:33 PM > *To:* idr@ietf.org > *Subject:* [Idr] WG Last Call on Extened Message Support > > > > > > This begins a 2 week WG LC on Extended Message Support for BGP > (draft-ietf-idr-bgp-extended-messages-27). You can access the draft at: > > > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ > > > > The authors should indicate whether they know of any IPR. Implementers > are encouraged to update the implementation data at: > > > > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations > > > > The draft provides a means for expanding the BGP message to 65535 octets > for all messages except OPEN messages. BGP message space is running shor= t > for all of the potential attributes or additions proposed by BGP-LS > features. > > > > The WG chairs intend to forward this draft to the IESG with the current > level of implementation. > > > > As you comment on the draft, please consider if: a) the technology is > mature, b) the additional space in a BGP message would be helpful for tho= se > deploying BGP-LS or SR, and c) if the specification is ready for > publication. > > > > Sue Hares (WG Chair, Shepherd) > > > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --0000000000006c02b10581de1238 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Sue & authors o= f this proposal,

> Therefo= re,=C2=A0putting an attribute which=C2=A0cannot be de= composed to=C2=A0

> 4096 octets or<= /span>=C2=A0less in an Extended Message is a likely path to=C2=A0

> routing failure.


That's brilliant statement= but not enough to proceed with this spec.=C2=A0


See the fundamental change that today such issue is in vast majori= ty of cases locally significant. That means that if I send NLRI to BGP it w= ill have a decent chance to be received by all intended parties.=C2=A0


With new spec we are saying that it may silently fa= il somewhere in the middle and we do not do anything about it. That's t= o me showstopper.=C2=A0


=

At min if given NLRI can not be sen= t with XXL attributes to some peers (say on the RR which Bruno mentioned) w= e must specify protocol extension=C2=A0in this very spec on how to deal wit= h it.=C2=A0


Such extension may be as simple as to def= ine a short attribute BGP_PIPE_TOO_THIN which will be inserted in the place= where XXL attribute just did not fit smaller message size peers to tell th= em then "Hey something is broken with this NLRI" - pls check. The= n it will be up to local policy to install such NLRI or drop it.=C2=A0


Thx,
R.


On Thu, = Feb 14, 2019 at 6:21 PM Susan Hares <= shares@ndzh.com> wrote:

Bruno:

=C2=A0

Thank you for careful considerations on the use case.= =C2=A0=C2=A0 I think we have translation issues between our =E2=80=9CEnglis= h=E2=80=9D language again so I have tried to be precise in the detailed com= ments.=C2=A0 I=E2=80=99ve summarized my comments as well to help us take th= e next step.

=C2=A0

Sue <= /span>

=C2=A0

Summary

----

Good catch on the 1000 large BGP communities blowing up the message size!= =C2=A0 This is a case where a code path could get caught with program error= .=C2=A0 The error handling (section 6.1 in RFC4271 per section 5 in the ext= ended specification) IMHO handles the case where the attribute is longer th= an the message.=C2=A0 =C2=A0Please let me know if I=E2=80=99ve missed somet= hing. =C2=A0=C2=A0

<= u>=C2=A0

As I understan= d it, =C2=A0you are asking this specification to be expanded to add notes o= n policies on what implementation should do to correctly combine RFC4271 le= ngth sizes with extended length sizes.=C2=A0=C2=A0 The implementers and ope= rations people commented earlier that this should not be in the protocol sp= ecification other than as a brief footnote.=C2=A0

=

=C2=A0

I agree there is a need for such standardization as BCPs = for particular use cases (large communities, BESS (EVPN or centralized cont= roller), SPRING, BGP-LS information (see Daylight comments yesterday), SD-W= ANs (rtgwg), and SPRING.=C2=A0 =C2=A0I think the chairs of the WGs utilizin= g should consider if there is need for standardization for a minimal set of= policy for message sizes for specific use cases.=C2=A0=C2=A0 I will be gla= d to send request to these WG or to host something in IDR if there is polic= y that can be used across all use cases.

=C2=A0

To provide a slight expansion to point people in this direction, = how about this change to paragraph in section 4:

<= p class=3D"MsoNormal">=C2=A0

Old/

= =C2=A0=C2=A0 A BGP announcement will, in the normal case, propagate through= out the

=C2=A0=C2=A0 BGP= speaking Internet; and there will undoubtedly be BGP speakers

=C2=A0=C2=A0 which do not have the E= xtended Message capability.=C2=A0 Therefore,

=C2=A0=C2=A0 putting an attribute which can not be dec= omposed to 4096 octets or

/

New/

=C2=A0=C2=A0 A BGP announcement will, in the normal case, pr= opagate throughout the

= =C2=A0=C2=A0 BGP speaking Internet; and there will undoubtedly be BGP speak= ers

=C2=A0=C2=A0 which d= o not have the Extended Message capability.=C2=A0 Therefore,<= /span>

=C2=A0=C2=A0 putting an attribute whic= h cannot be decomposed to 4096 octets or

=C2=A0=C2=A0 less in an Extended Message is a likely pat= h to routing failure.

= =C2=A0=C2=A0 One example of a valid attribute which cannot be precisely dec= omposed if it

=C2=A0= =C2=A0=C2=A0sent in Extended message is a large community attribute with 10= 00 communities.

=C2=A0= =C2=A0=C2=A0(12,000 bytes).=C2=A0

/

[PS =E2=80= =93 in American English =E2=80=9CCan not=E2=80=9D is normally concatenated = =E2=80=9Ccannot=E2=80=9D.]

= =C2=A0=C2=A0=C2=A0

=C2=A0

=C2= =A0

=C2=A0

From: bruno= .decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Thursd= ay, February 14, 2019 3:29 AM
To: Susan Hares
Cc: idr@ietf.org; 'Jakob H= eitz (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Mes= sage Support

= =C2=A0

Sue,=

=C2=A0<= u>

Thanks for the reply. Pleas= e see inline [Bruno]

=C2=A0

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, February 13, 2019 8:0= 3 PM
To: DECRAENE Bruno TGI/OLN
Cc: idr@ietf.org; 'Jakob Heitz (jheitz)&= #39;
Subject: RE: [Idr] WG Last Call on Extened Message Support

=C2=A0

Bruno: <= /p>

=C2= =A0

I=E2=80=99d like to answer some of the questions you sent Randy based= on comments (public and private) the chairs and I as the shepherd received= on this draft in our last WG LCs. =C2=A0=C2=A0

=C2=A0

Se= veral of the comments you questioned were put in to answer other questions.= =C2=A0=C2=A0 This gets into a catch-22=E2=80=A6 problem =E2=80=93 where you= put changes in for one person/take out the changes out for another.=C2=A0 = In academic circles this is called the reviewer #2 problem (reviewer 1 insi= sts changes go in, reviewer 2 insists changes go out) during publication.= =C2=A0 Therefore, I=E2=80=99m I am going to answer most of your questions w= here this is the case.=C2=A0

=C2=A0

I believe that Randy= has new version with the changes I=E2=80=99ve indicated.=C2=A0 I=E2=80=99m= hoping he=E2=80=99ll just post that version.=C2=A0 AFAILK, we do have 2 co= mpliant implementations.

=C2=A0

Sue

= =C2=A0

=C2=A0

=C2=A0

<shepherd hat on> =

= This draft=E2=80=99s technology provides efficient processing for some appl= ication by allow a huge BGP message size.=C2=A0 Whether =E2=80=9Cchunking= =E2=80=9D BGP to 4096 byte messages or packing large amounts of data into 6= 5,000 byte message is more effective for a particular application is someth= ing only an implementer of a particular BGP implementation =C2=A0can decide= . =C2=A0=C2=A0This draft simply gives freedom for applications to not be re= strict to an artificially small message size.=C2=A0 The market place will c= hoose whether this technology is used or not.=C2=A0

=C2=A0<= u>

As Jakob pointed out, changing a highly tuned BGP implementation which = =E2=80=9Cchunks=E2=80=9D BGP data into 4096 byte messages may involve subst= antial rework of the implementation.=C2=A0

=C2=A0

=C2=A0

(snip)

= From: Idr &l= t;idr-bounces@iet= f.org> On Behalf Of bruno.decraene@orange.com
Sent: 29 Janu= ary 2019 13:33
To: Susan Hares <shares@ndzh.com>
Cc: idr@ietf.org
Subject: Re:= [Idr] WG Last Call on Extened Message Support

=C2=A0

H= i WG,

= =C2=A0

>Please find below some comments.

>As of today, I don=E2=80=99t believe= this specification is ready to be progressed to IESG/RFC, especially for a= document >updating RFC 4271= (core BGP spec).

=C2=A0

> The WG chairs intend to forward this draft to the IESG= with the current level of implementation.=C2=A0

<= p class=3D"MsoNormal" style=3D"margin-left:35.4pt">=C2=A0

<= table class=3D"gmail-m_715297875910682865TableauNormal" border=3D"0" cellsp= acing=3D"5" cellpadding=3D"0" width=3D"636" style=3D"width:476.9pt;margin-l= eft:35.4pt">

= >https://trac.ietf.org/trac/idr/wiki= /draft-ietf-idr-bgp-extended->implementations says : 5a

Does = not send Extended Message capability

Yes

Yes

Yes

=C2=A0

>I may be misunderstanding = the implementation report, but my reading of the above is that none of the = reported >implementations se= nds the capability hence no implementation supports draft-ietf-idr-bgp-exte= nded-messages.. <= /span>

>= ;Here th= is document is updating RFC 4271, so it is not a minor extension for a nich= e use case. So I don=E2=80=99t see the >arguments for not requiring the IDR=E2=80=99s usual two interop= erable implementations.

=C2=A0

>In our mail thread, we= discovered that the implementation report should have indicate

&g= t;full support.=C2=A0=C2=A0 I=E2=80=99m waiting for Olivier to update based= on the last point, but my understanding is that

<= p class=3D"MsoNormal" style=3D"margin-left:35.4pt">All implementati= ons have full support. =C2=A0

=C2=A0

[Bruno] ok, solved

= >----

>=C2=A7 1

>=E2=80=9C As BGP is ext= ended to support newer AFI/SAFIs and

>=C2=A0=C2=A0 newer = capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there is

>=C2=A0=C2=A0 a need to extend the maximum message size beyond 4096 oc= tets.=C2=A0 =E2=80=9C

>=C2=A0

> https://tools.ietf.org/html/draft-ietf-idr-bgp-exten= ded-messages-27#section-1

=C2=A0

=C2=A0

>[I-D.ietf-sidr-bgpsec-protocol is now RFC 8205 (thanks = for updating the reference). It has removed the normative/any >reference to draft-ietf-idr-bgp-extend= ed-messages. So presumably BGP Sec does not need draft-ietf-idr-bgp->extended-messages. Can we have an update on this? =C2=A0Can the introduction of draft-ietf-idr-bgp-extended-messages >be updated to intr= oduce on the real reasons/needs?

=C2=A0

SIDR gave = up waiting on IDR=E2=80=99s work and took a reduced size of encryption.=C2= =A0=C2=A0 The security people were very sad about the reduction.=C2=A0 How = is this working in practice? WG sidrops can answer this question.=C2=A0 =

<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">=C2=A0

The real problem is there is finite message space.= =C2=A0

[Bruno= ] So too bad the draft does not solve the real problem ;-) (as message spac= e is still limited)

= =C2=A0

[Su= e]: The message is still finite (smile), =C2=A0but I hope 65,635 (smile) is= probably enough for 10 years.=C2=A0 =C2=A0

=C2=A0

There = are two ways to send lots of BGP routes and/or attributes =E2=80=93 to =E2= =80=9Cchunk=E2=80=9D these into small message sizes or place these into a l= arge message.=C2=A0=C2=A0 =C2=A0Some applications may always want to =E2=80= =9Cchunk=E2=80=9D into message sizes smaller than 4096.=C2=A0 =C2=A0Some ap= plication make work more efficiently utilizing large message size.=C2=A0 As= the potential number of NLRI and BGP attributes grows, new applications ma= y consider large message sizes to a more reasonable way to exchange amounts= of BGP data.=C2=A0=C2=A0 =C2=A0

=C2=A0

The decision on h= ow to send BGP messages over the wire is a peer-by-peer decision in a netwo= rk.=C2=A0 =C2=A0Each BGP peer is in charge of reformatting the BGP message = it sends to the remote BGP peer.=C2=A0=C2=A0 The BGP capabilities in this d= raft represent an agreement between two BGP peers.=C2=A0 These are facts of= basic BGP implementations

<= b>[Bruno] Let=E2=80=99s take the example of a BGP Route Reflecto= r having a mixed of clients, some supporting Extend Message (EM) and some n= ot.

Fr= om an EM client, it receives a BGP update containing one (single) NLRI with= an Total Path Attribute Length bigger than=C2=A0 4090 byte (e.g. having 10= 00 large communitiess)

Can you explain me how it behaves to send this NLRI to an = IBGP peer not supporting EM?

[Sue]:=C2=A0 Gladly=E2=80=A6

A BGP route reflector (RR-A)= is peering with each of its BGP clients.=C2=A0 =C2=A0It agrees with each o= f its clients (BGP-C1, BGPC2, BGPC3) whether the BGP Extended messages is a= ccepted or not (based on capability announcement).

Let us assume that BGP-C1 doe= s not support extended messages, and =C2=A0BGP-C2 and BGP-C3 do support ext= ended messages.

= =C2=A0

If the policy in RR accepts a total path length of 1000 large c= ommunities with =C2=A0a single NLRI, it may send the BGP attribute via exte= nded communities to BGP-C2 and BGP-C2.

The policy in the RR must specify whether:=

a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /i>the =E2=80=9Ctoo long= =E2=80=9D attribute path length must be dropped, or

b)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the BGP attribute path can be truncated. =

= =C2=A0

This i= s a policy issue within the BGP peer and the network operation staff.=C2=A0= Each operator may choose to write this policy differently. <= /span>

=C2=A0=

Rather than specify= the numerous cases in the protocol specification, =C2=A0the previous discu= ssions (private and public) asked us to trim this information out of the pr= otocol specification.

=C2=A0

If you believe this is worthy of a use case draft for the= sake of BESS, LSVR, SPRING, Grow and others, I will happily WG chair spons= or a draft that can be reviewed by all these WGs. =

=C2=A0

=C2=A0

=E2=80=93 so I do not believe addi= ng these facts to Randy=E2=80=99s draft is useful.=C2=A0 In fact, in the pr= evious rounds of review this point was made.

=C2=A0=

Your question (and perhaps Jakob= =E2=80=99s) is whether we have reached a time/place where the =E2=80=9Cchun= king=E2=80=9D approach will fail on a peer-by-peer basis? =C2=A0=C2=A0This = draft does not make this statement.=C2=A0

=C2=A0

The point of this draft is to enable= more efficient processing by increasing the message size for BGP peers tha= t send a lot of data (e.g. BGP-LS) .=C2=A0=C2=A0 The choice to =E2=80=9Cchu= nk=E2=80=9D or stream in large BGP message is an implementation choice for = a particular BGP application.=C2=A0

=C2=A0

----

=C2=A74

=C2=A73 s=
ays =E2=80=9CA peer which does not advertise this capability MUST NOT send B=
GP

= =C2=A0 =C2=A0Extended Messages, and BGP Extended Messages MUST NOT be sent = to it.= =E2=80=9D

[I believe= randy accepted this change with the following text in version 4 [upcoming = below]]/.

=C2=A0

<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">--------------

=C2=A0

= Fin= e. Text in =C2=A74 should probably be aligned with the above ..e.g.<= u>

OLD: A BGP speaker

=C2=A0=C2=A0 MAY send Extended Messages to its peer only if it has recei= ved the

=C2=A0=C2=A0 Extended Messag= e Capability from that peer.

=C2=A0

NEW:

A BGP speaker<= /span>

=C2=A0=C2=A0 MAY send Extended Messages to its pee= r only if it has sent and received the

=C2=A0=C2=A0 Extended Message Capability to and from that peer.

=C2=A0

= =C2=A0

----

>=E2=80=9C=C2=A0=C2=A0 Applications generating information which =
might be encapsulated

>=C2=A0=C2=A0 within BGP messages MUST limit the size of their p= ayload to take the

>=C2=A0=C2=A0 maximum message size into account.=E2=80=9D

>=C2=A0

>I= don=E2=80=99t see what new behavior is been defined here. If there is none= , I would suggest to remove this sentence

=C2=A0

Bruno =E2=80=93 people asked to put = this text in as an operational warning.=C2=A0 At this point, I=E2=80=99m go= ing to say unless there is harm it should remain.=C2=A0

[Bruno] OK.

=C2=A0

----

>= = =C2=A0=C2=A0 A BGP announcement will, in the normal case, propagate through= out the

>=C2= =A0=C2=A0 BGP speaking Internet; and there will undoubtedly be BGP speakers=

>=C2=A0=C2= =A0 which do not have the Extended Message capability.=C2=A0 Therefore,<= /u>

>=C2=A0=C2=A0 pu= tting an attribute which can not be decomposed to 4096 octets or<= /u>

>=C2=A0=C2=A0 less in a= n Extended Message is a likely path to routing failure.

>=C2=A0

>The issue is not specific to attributes = bigger than 4096 octets, but to BGP message whose length is bigger than >4096, irrespective of the size of each attribute.<= u>

>Please elaborate on w= hat you mean by

>=C2=A0

&= gt;=E2=80=9Can attribute which cannot be decomposed to 4096 octets=E2=80= =9D

=C2=A0

An attribute which cannot be decomposed to 4096 is an attrib= ute with length 6000 inside of a BGP message which requires the entire attr= ibute to be included.=C2=A0 =C2=A0No such attribute exists today.=C2=A0 =C2= =A0If a small BGP peers create a =E2=80=9Ckiller application=E2=80=9D that = uses a 6000 byte attribute, the rest of the Internet does not have to use i= t.=C2=A0=C2=A0 However, the person defining that attribute must carefully s= pecify it must go with Extended BGP messages.

=C2=A0

=C2=A0

[Bruno] I don=E2=80=99t think that I agr= ee with this. E.g. I don=E2=80=99t see where RFCs 1997 or 8092 [(large)comm= unity] limits the size of their attribute. Hence I don=E2=80=99t see why yo= u could not have, today (with Extended Message support) , attributes larger= than 4096 octets. Most probably same status for the BGPSec attribute since= they wanted for more space.

[Sue]: You make a good = point about the possibility of large communities not limiting the size.=C2= =A0 It is worthy of a change to both the large communities and a footnote i= n Randy=E2=80=99s specification.=C2=A0 How about the addition of a single s= entence to point people in the right direction.

=C2=A0

Old/

=C2=A0=C2=A0 A BGP announcement will, in the normal case, propagate th= roughout the

=C2=A0=C2= =A0 BGP speaking Internet; and there will undoubtedly be BGP speakers

=C2=A0=C2=A0 which do not hav= e the Extended Message capability.=C2=A0 Therefore,

=C2=A0=C2=A0 putting an attribute which can not= be decomposed to 4096 octets or

=C2=A0=C2=A0 less in an Extended Message is a likely path to routi= ng failure.

/<= /u>

New/

=C2=A0=C2=A0 A BGP announcement will, in the normal c= ase, propagate throughout the

=C2=A0=C2=A0 BGP speaking Internet; and there will undoubtedly be BGP= speakers

=C2=A0=C2=A0 w= hich do not have the Extended Message capability.=C2=A0 Therefore,

=C2=A0=C2=A0 putting an attribut= e which cannot be decomposed to 4096 octets or

=C2=A0=C2=A0 less in an Extended Message is a likely= path to routing failure.

=C2=A0= =C2=A0=C2=A0sent in Extended message is a large community attribute with 10= 00 communities.

=C2=A0= =C2=A0=C2=A0(12,000 bytes).=C2=A0

/

=C2=A0 <= /u>

=C2=A0<= /u>

=

This text was added during an earlier discussion where th= e error cases of a large BGP attribute was given.=C2=A0 The originator of t= he common could not provide the exact description, but we agreed to put thi= s =C2=A0=E2=80=9Cwarning label=E2=80=9D into the draft.=C2=A0=C2=A0 This is= one of the cases where adding/removing text gets to be problematic.

=C2=A0

>---

>=E2=80=9C=C2=A0=C2=A0 It= is RECOMMENDED that BGP protocol developers and implementers are=

>=C2=A0=C2=A0 conservative in their application and use of Extended = Messages.=E2=80=9D

>=C2=A0

>What does this mean exactly? = That they don=E2=80=99t use this extension?

>That they don=E2=80=99t use this extension unless XX_TO = BE SPECIFIED_XX?<= /span>

= =C2=A0

This warning was text that other participants asked to be adde= d.

=C2=A0

It is a common sense warning.=C2=A0 Extended m= essages are enabled on a peer by peer basis as all BGP capabilities are.=C2= =A0 If you run into a Peer that does not support the larger sizes, the BGP = messages will need to be reformatted to the smaller size.=C2=A0 =C2=A0Runni= ng immediately to the Extended messages as the default could cause problems= .

=C2=A0

[Bruno] I think that the sentence could be elaborated. Indicating the pr= oblem, how the specification partially address it, and how the specificatio= n does not address it.

In =E2=80=9CRunning immediately to Extended Message=E2=80= =9D I don=E2=80=99t think they that the issue is with =E2=80=9Cimmediately= =E2=80=9D. Whenever you start the transition, your likely to run into probl= ems.

<= u>=C2=A0

= =C2=A0

[Sue]: IMHO specification specifies how to encode the bytes on the wire an= d the appropriate error handling of the messages.=C2=A0 =C2=A0If I have mis= sed something in this case, please let me know.

=C2=A0<= /b>

The specification does not spec= ify the necessary policies implementation should have in order to decide wh= at to do in the case of mixed network.=C2=A0 =C2=A0The clear indication was= this type was not appropriate for the protocol specification. =C2=A0

=C2= =A0

Earlier d= iscussion indicated that these is policy and mechanism specific.=C2=A0 It i= s worthy of =E2=80=9Cuse case or application notes=E2=80=9D written for spe= cific applications (BESS, SPRING, GROW), but not in the specification.=C2= =A0 Again, if it is significant enough concern for operators and implemente= rs =E2=80=93 it would be worthy to have combined use case document besides = this point. =C2=A0=C2=A0=C2=A0I=E2=80=99m happy to sponsor cross-area work = on this use case.

<= b>=C2=A0

---

=C2=A0 Future protocol specifications will need to d= escribe how to handle

=C2=A0=C2=A0 peers which can only accommodate 4096 octet me= ssages.

=C2=A0

>Why is this limited to future specifications? A priori, usi= ng existing BGP mechanism (AFI/SAFI, attributes, * >communities) one could exceed the size of 4096 octe= ts. How does the BGP speaker supposed to behave in this ?>case? This should be described in this specif= ication. Note that this is not a case of error handling, as every BGP

> speaker is behaving as specif= ied.

=C2=A0

I fail to see your logic.=C2= =A0 At this point, all BGP data (AFI/SAFI and attributes) must fit within a= 4096 message.=C2=A0 =C2=A0Therefore, a BGP peer A which connects on link 1= to BGP peer B with 4096 message and on link to a BGP peer C with extended = messages only has to worry about reformatting the data.=C2=A0

= =C2=A0

In the future, the first group that defines attribute or an NL= RI that does not fit within a 4096 BGP message and cannot be split, will ne= ed to define how that works in the specification.=C2=A0 There is no need to= refine the current set of specifications.=C2=A0=C2=A0

[Bruno]<= /b>

1) cf above, I believe that the= re are existing BGP Attributes which may not fit into a bytes 4096 BGP mess= age

2)= Even in the absence of such attribute, you have the issue of 2 smaller attr= ibutes whose cumulative size does not fit into a 4096 bytes message.=

=C2= =A0

The probl= em is introduced by this specification, hence I believe this specification = needs to specify how to handle this case.

<= p class=3D"MsoNormal">=C2=A0

[Sue]: =C2=A0IHMO the message transmission and reception e= rror handling issues are complete in the combination of RFC4271 and the ext= ended message section 5.

=C2=A0

What is= not in this specification is the policy issues about what happens if you c= ombine 2 smaller attributes.=C2=A0 For example, if you have a large communi= ty attribute of 400 communities (4800 bytes), you will likely run into prob= lems when combining with some longer AS path lengths.=C2=A0 [4800=C3= =A0 5096 bytes is a short jump]. People on the list and in-p= erson argued this was policy and implementation specific details.=C2=A0 =

=C2=A0

I agree with you that it is extreme= ly useful to the operator community to have this type of policy details dis= cussed to see if there is some desire to have common policies and error com= munities. =C2=A0=C2=A0It is the type of thing that GROW and IDR should be d= eeply involved for large communities.=C2=A0 =C2=A0BESS, LSVR, SPRING and ot= hers should consider what policy should be adapted for their applications. =

=C2=A0

>----

>Depending on the above = specification, a section describing the operational consequences in a netwo= rk (such as the >Internet, BGP Enabled ServiceS/VPN net= works) is probably needed. Possible consequences could be BGP NLRI <= span style=3D"font-size:10pt;font-family:Arial,sans-serif;color:rgb(31,73,1= 25)">>being removed in the middle of such network, or (extended) com= munity (such as Route Targets) been removed. >Both havi= ng significant consequences on the availability provided by the network.

=C2=A0

At this point, there are no attributes = or NLRI groupings that do not fit within 4096.=C2=A0 =C2=A0If you define on= e (as SIDR did), then you will need to have it reviewed by IDR, BESS, SPRIN= G, and operational groups (GROW, etc).=C2=A0

[Bruno] no, cf above.

[Sue]: =C2=A0Thank you for r= eminding me of the potential of large communities to blow up BGP.=C2=A0 I h= ave a new worry to add to my BGP concerns list!

=C2=A0<= /b>

Thanks,

--Bruno<= /i>

= =C2=A0

=C2=A0

---

>=C2=A74

>OLD: The Extended Messag= e Capability only applies to all messages except for the >OPEN message.

>Probably

>NEW: The Extended Message Capability applies to all message ty= pes except for the >OPEN mes= sage (type 1).

>----

>=C2=A78

>=E2=80=9CThi=
s extension to BGP does not change BGP's underlying security issues=C2=
=A0=C2=BB
>Before evaluating this, I think this document should first speci=
fied how a BGP 
>messages bigge=
r than 4096 octets is handled when it needs to be sent to a 
>received not supporting this extension.=

=C2=A0<= u>

Nits:<= /u>

>OLD=C2=A0: to reduce compexity

>NEW=C2=A0: to= reduce complexity

=C2=A0

Thanks,

--Bruno

=C2=A0

From: Idr [mailto= :idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: = Tuesday, January 29, 2019 12:33 PM
To: idr@ietf.org
Subject: [Idr] WG Last C= all on Extened Message Support

=C2=A0=

= =C2=A0

Th= is begins a 2 week WG LC on Extended Message Support for BGP (draft-ietf-id= r-bgp-extended-messages-27).=C2=A0 You can access the draft at: <= /u>

=C2= =A0

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messa= ges/

=C2=A0

The authors should indicate whether they know of any IPR.= =C2=A0=C2=A0 Implementers are encouraged to update the=C2=A0 implementation= data at:

=C2=A0

https://trac.ietf.org/trac/idr/wiki/dr= aft-ietf-idr-bgp-extended-implementations

<= p class=3D"MsoNormal" style=3D"margin-left:35.4pt">=C2=A0=

The draft provides a m= eans for expanding the BGP message to 65535 octets for all messages except = OPEN messages.=C2=A0 BGP message space is running short for all of the pote= ntial attributes or additions proposed by BGP-LS features.=C2=A0 =

=C2= =A0

The W= G chairs intend to forward this draft to the IESG with the current level of= implementation.=C2=A0

=C2=A0

As you comment on the draft, please consider if:= a) the technology is mature, b) the additional space in a BGP message woul= d be helpful for those deploying BGP-LS or SR, and c) if the specification = is ready for publication.=C2=A0

=C2=A0

Sue Hares (WG Chair, Shepherd) <= u>

= =C2=A0

=C2= =A0

_________________________=
___________________________________________________________________________=
_____________________
<=
/u>=C2=A0
Ce message et ses pie=
ces jointes peuvent contenir des informations confidentielles ou privilegie=
es et ne doivent donc
pas =
etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces joint=
es. Les messages electroniques etant susceptibles d'alteration,<=
u>
Orange decline toute responsabili=
te si ce message a ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain confidential or =
privileged information that may be protected by law;
they should not be distributed, used or copied w=
ithout authorisation.
If y=
ou have received this email in error, please notify the sender and delete t=
his message and its attachments.
As emails may be altered, Orange is not liable for messages that hav=
e been modified, changed or falsified.
Thank you.
__________________________________________=
___________________________________________________________________________=
____
=C2=A0
=
Ce message et ses pieces jointes peuvent contenir des inf=
ormations confidentielles ou privilegiees et ne doivent donc<=
/span>
pas etre di=
ffuses, exploites ou copies sans autorisation. Si vous avez recu ce message=
 par erreur, veuillez le signaler
a l'expediteur et le detruire ains=
i que les pieces jointes. Les messages electroniques etant susceptibles d&#=
39;alteration,
=
Orange decline toute responsabilite si ce message a ete a=
ltere, deforme ou falsifie. Merci.
=C2=A0
This message and its attach= ments may contain confidential or privileged information that may be protec= ted by law;
they should not be distributed, used or copied without autho=
risation.
If you have received this email in error, please notify the se=
nder and delete this message and its attachments.
As emails may be alter=
ed, Orange is not liable for messages that have been modified, changed or f=
alsified.
Thank you.
__=
___________________________________________________________________________=
____________________________________________
=C2=A0
=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
<=
span lang=3D"FR">pas etre diffuses, exploites ou copies sans autorisation. =
Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi=
 que les pieces jointes. Les messages electroniques etant susceptibles d=
9;alteration,
Orange decli=
ne toute responsabilite si ce message a ete altere, deforme ou falsifie. Me=
rci.
=C2=A0<=
/span>
This message and its attachments may con=
tain confidential or privileged information that may be protected by law;
they should not be distribu=
ted, used or copied without authorisation.
<=
span lang=3D"FR">If you have received this email in error, please notify th=
e sender and delete this message and its attachments.<=
/pre>
As emails may be altered, Orange is not liable =
for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--0000000000006c02b10581de1238-- From nobody Thu Feb 14 10:46:35 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFAF128CE4 for ; Thu, 14 Feb 2019 10:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC3ZcsQznS_U for ; Thu, 14 Feb 2019 10:46:28 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58381289FA for ; Thu, 14 Feb 2019 10:46:27 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.248.72; From: "Susan Hares" To: "'Robert Raszuk'" Cc: "'Bruno Decraene'" , "'idr@ietf. org'" References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk> <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> <17281_1550132953_5C6526D9_17281_161_1_53C29892C857584299CBF5D05346208A489D3D92@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <00c901d4c489$8f311830$ad934890$@ndzh.com> In-Reply-To: Date: Thu, 14 Feb 2019 13:46:20 -0500 Message-ID: <00f401d4c495$944db9c0$bce92d40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F5_01D4C46B.AB823910" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rAefZHwsB7dxHTgI7AvBBAac2MMMBU1Q3bALWlDmypCqCt/A= Content-Language: en-us X-Antivirus: AVG (VPS 190214-2, 02/14/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:46:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F5_01D4C46B.AB823910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert:=20 =20 Thank you for your message and your concerns regarding BGP in the = Internet. See my comments below.=20 =20 Sue=20 =20 From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Thursday, February 14, 2019 12:34 PM To: Susan Hares Cc: Bruno Decraene; idr@ietf. org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Dear Sue & authors of this proposal, =20 >> Therefore, putting an attribute which cannot be decomposed to=20 >> 4096 octets or less in an Extended Message is a likely path to=20 >> routing failure. >That's brilliant statement but not enough to proceed with this spec.=20 >See the fundamental change that today such issue is in vast majority of = cases locally significant. That means that if I send NLRI to BGP it will = have a decent chance to be received by all intended parties.=20 [Sue]: The reason you receive this NLRI is due to the peer-wise = agreements of all the BGP peers in the cloud. Each peer agrees to send = routing based on its policies and capabilities. Policy and = implementation specific details are not in BGP specifications.=20 >With new spec we are saying that it may silently fail somewhere in the = middle and we do not do anything about it. That's to me showstopper.=20 [Sue]: Where do you see the point it must silently fail or an operator = will not do anything about it? =20 The error message handling specified in the draft and in RFC4271. If = see errors in the error handling as specified please send that to the = list. These errors must be on the peer-to-peer protocol exchange.=20 The peer-wise agreements specify the length of a BGP message. BGP peers = receiving a large packet and expecting to send it to a peer which has = 4096 bytes as a message size, will need to repackage it. If it cannot = be repackaged, then the BGP implementation needs to warn the operator. = If the BGP peers cannot repackage BGP messages today, there should be = error messages and =E2=80=9Cbells=E2=80=9D ringing. If the = implementation does not have the appropriate warning systems, please see = your vendor. What show stopper deployed today are you talking about? I do not = perceive any show-stopper on the peer-to-peer communication.=20 At min if given NLRI can not be sent with XXL attributes to some peers = (say on the RR which Bruno mentioned) we must specify protocol extension = in this very spec on how to deal with it.=20 [Sue]: We cannot send the 12K large community attribute now. This = protocol specification deals with what happens when you send and receive = BGP packets. The BGP peers negotiate the length of the BGP message that = can be sent/received. It has been tested and deployed (see comment = about OpenDaylight) for some years. =20 Your description indicates a =E2=80=9Cnetwork-wide=E2=80=9D requirement. = A network-wide requirement is based on the specific needs of an = application + BGP. For example, some Data center BGP applications are = very different than EVPN BGP over MPLS. =20 Such extension may be as simple as to define a short attribute = BGP_PIPE_TOO_THIN which will be inserted in the place where XXL = attribute just did not fit smaller message size peers to tell them then = "Hey something is broken with this NLRI" - pls check. Then it will be up = to local policy to install such NLRI or drop it.=20 [sue]This idea is orthogonal to the basic BGP engine. It is similar to = ideas that have been kicked around in Grow and IDR for a while. If this = use case gives new focus to these ideas, please write a specification = and suggest it to the IDR and Grow WG. IDR can look at the passage of = error messages. Grow can look at how useful it is for the general BGP. = We=E2=80=99ve talk about the error message concept for 10+ years, but = the tradeoff for the error message has not given enough benefits to = operators. Perhaps this is the =E2=80=9Ckiller-application=E2=80=9D = application.. =20 Thx, R. =20 =20 On Thu, Feb 14, 2019 at 6:21 PM Susan Hares wrote: Bruno:=20 =20 Thank you for careful considerations on the use case. I think we have = translation issues between our =E2=80=9CEnglish=E2=80=9D language again = so I have tried to be precise in the detailed comments. I=E2=80=99ve = summarized my comments as well to help us take the next step.=20 =20 Sue=20 =20 Summary ---- Good catch on the 1000 large BGP communities blowing up the message = size! This is a case where a code path could get caught with program = error. The error handling (section 6.1 in RFC4271 per section 5 in the = extended specification) IMHO handles the case where the attribute is = longer than the message. Please let me know if I=E2=80=99ve missed = something. =20 =20 As I understand it, you are asking this specification to be expanded to = add notes on policies on what implementation should do to correctly = combine RFC4271 length sizes with extended length sizes. The = implementers and operations people commented earlier that this should = not be in the protocol specification other than as a brief footnote. =20 =20 I agree there is a need for such standardization as BCPs for particular = use cases (large communities, BESS (EVPN or centralized controller), = SPRING, BGP-LS information (see Daylight comments yesterday), SD-WANs = (rtgwg), and SPRING. I think the chairs of the WGs utilizing should = consider if there is need for standardization for a minimal set of = policy for message sizes for specific use cases. I will be glad to = send request to these WG or to host something in IDR if there is policy = that can be used across all use cases.=20 =20 To provide a slight expansion to point people in this direction, how = about this change to paragraph in section 4:=20 =20 Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed = if it=20 sent in Extended message is a large community attribute with 1000 = communities.=20 (12,000 bytes). =20 / [PS =E2=80=93 in American English =E2=80=9CCan not=E2=80=9D is normally = concatenated =E2=80=9Ccannot=E2=80=9D.]=20 =20 =20 =20 =20 From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Sent: Thursday, February 14, 2019 3:29 AM To: Susan Hares Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Sue, =20 Thanks for the reply. Please see inline [Bruno] =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Wednesday, February 13, 2019 8:03 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Bruno:=20 =20 I=E2=80=99d like to answer some of the questions you sent Randy based on = comments (public and private) the chairs and I as the shepherd received = on this draft in our last WG LCs. =20 =20 Several of the comments you questioned were put in to answer other = questions. This gets into a catch-22=E2=80=A6 problem =E2=80=93 where = you put changes in for one person/take out the changes out for another. = In academic circles this is called the reviewer #2 problem (reviewer 1 = insists changes go in, reviewer 2 insists changes go out) during = publication. Therefore, I=E2=80=99m I am going to answer most of your = questions where this is the case. =20 =20 I believe that Randy has new version with the changes I=E2=80=99ve = indicated. I=E2=80=99m hoping he=E2=80=99ll just post that version. = AFAILK, we do have 2 compliant implementations.=20 =20 Sue=20 =20 =20 =20 =20 This draft=E2=80=99s technology provides efficient processing for some = application by allow a huge BGP message size. Whether = =E2=80=9Cchunking=E2=80=9D BGP to 4096 byte messages or packing large = amounts of data into 65,000 byte message is more effective for a = particular application is something only an implementer of a particular = BGP implementation can decide. This draft simply gives freedom for = applications to not be restrict to an artificially small message size. = The market place will choose whether this technology is used or not.=20 =20 As Jakob pointed out, changing a highly tuned BGP implementation which = =E2=80=9Cchunks=E2=80=9D BGP data into 4096 byte messages may involve = substantial rework of the implementation. =20 =20 =20 (snip)=20 From: Idr On Behalf Of bruno.decraene@orange.com Sent: 29 January 2019 13:33 To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Hi WG, =20 >Please find below some comments. >As of today, I don=E2=80=99t believe this specification is ready to be = progressed to IESG/RFC, especially for a document >updating RFC 4271 = (core BGP spec). =20 > The WG chairs intend to forward this draft to the IESG with the = current level of implementation. =20 =20 >https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended- = >implementations says : 5a=20 Does not send Extended Message capability=20 Yes=20 Yes=20 Yes=20 =20 >I may be misunderstanding the implementation report, but my reading of = the above is that none of the reported >implementations sends the = capability hence no implementation supports = draft-ietf-idr-bgp-extended-messages..=20 >Here this document is updating RFC 4271, so it is not a minor extension = for a niche use case. So I don=E2=80=99t see the >arguments for not = requiring the IDR=E2=80=99s usual two interoperable implementations. =20 >In our mail thread, we discovered that the implementation report should = have indicate >full support. I=E2=80=99m waiting for Olivier to update based on the = last point, but my understanding is that=20 All implementations have full support. =20 =20 [Bruno] ok, solved >---- >=C2=A7 1 >=E2=80=9C As BGP is extended to support newer AFI/SAFIs and > newer capabilities (e.g., [ = I-D.ietf-sidr-bgpsec-protocol]), there is > a need to extend the maximum message size beyond 4096 octets. = =E2=80=9C >=20 > = https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on-1 =20 =20 >[ = I-D.ietf-sidr-bgpsec-protocol is now RFC = 8205 (thanks for updating the reference). It has removed the = normative/any >reference to draft-ietf-idr-bgp-extended-messages. So = presumably BGP Sec does not need draft-ietf-idr-bgp->extended-messages. = Can we have an update on this? Can the introduction of = draft-ietf-idr-bgp-extended-messages >be updated to introduce on the = real reasons/needs? =20 SIDR gave up waiting on IDR=E2=80=99s work and took a reduced size of = encryption. The security people were very sad about the reduction. = How is this working in practice? WG sidrops can answer this question. =20 =20 The real problem is there is finite message space. =20 [Bruno] So too bad the draft does not solve the real problem ;-) (as = message space is still limited) =20 [Sue]: The message is still finite (smile), but I hope 65,635 (smile) = is probably enough for 10 years. =20 =20 There are two ways to send lots of BGP routes and/or attributes = =E2=80=93 to =E2=80=9Cchunk=E2=80=9D these into small message sizes or = place these into a large message. Some applications may always want = to =E2=80=9Cchunk=E2=80=9D into message sizes smaller than 4096. Some = application make work more efficiently utilizing large message size. As = the potential number of NLRI and BGP attributes grows, new applications = may consider large message sizes to a more reasonable way to exchange = amounts of BGP data. =20 =20 The decision on how to send BGP messages over the wire is a peer-by-peer = decision in a network. Each BGP peer is in charge of reformatting the = BGP message it sends to the remote BGP peer. The BGP capabilities in = this draft represent an agreement between two BGP peers. These are = facts of basic BGP implementations [Bruno] Let=E2=80=99s take the example of a BGP Route Reflector having a = mixed of clients, some supporting Extend Message (EM) and some not. >From an EM client, it receives a BGP update containing one (single) NLRI = with an Total Path Attribute Length bigger than 4090 byte (e.g. having = 1000 large communitiess) Can you explain me how it behaves to send this NLRI to an IBGP peer not = supporting EM? [Sue]: Gladly=E2=80=A6=20 A BGP route reflector (RR-A) is peering with each of its BGP clients. = It agrees with each of its clients (BGP-C1, BGPC2, BGPC3) whether the = BGP Extended messages is accepted or not (based on capability = announcement).=20 Let us assume that BGP-C1 does not support extended messages, and = BGP-C2 and BGP-C3 do support extended messages.=20 =20 If the policy in RR accepts a total path length of 1000 large = communities with a single NLRI, it may send the BGP attribute via = extended communities to BGP-C2 and BGP-C2. The policy in the RR must specify whether:=20 a) the =E2=80=9Ctoo long=E2=80=9D attribute path length must be = dropped, or=20 b) the BGP attribute path can be truncated.=20 =20 This is a policy issue within the BGP peer and the network operation = staff. Each operator may choose to write this policy differently.=20 =20 Rather than specify the numerous cases in the protocol specification, = the previous discussions (private and public) asked us to trim this = information out of the protocol specification.=20 =20 If you believe this is worthy of a use case draft for the sake of BESS, = LSVR, SPRING, Grow and others, I will happily WG chair sponsor a draft = that can be reviewed by all these WGs.=20 =20 =20 =E2=80=93 so I do not believe adding these facts to Randy=E2=80=99s = draft is useful. In fact, in the previous rounds of review this point = was made.=20 =20 Your question (and perhaps Jakob=E2=80=99s) is whether we have reached a = time/place where the =E2=80=9Cchunking=E2=80=9D approach will fail on a = peer-by-peer basis? This draft does not make this statement. =20 =20 The point of this draft is to enable more efficient processing by = increasing the message size for BGP peers that send a lot of data (e.g. = BGP-LS) . The choice to =E2=80=9Cchunk=E2=80=9D or stream in large BGP = message is an implementation choice for a particular BGP application. =20 =20 ---- =C2=A74 =C2=A73 says =E2=80=9CA peer which does not advertise this capability = MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.=E2=80=9D [I believe randy accepted this change with the following text in version = 4 [upcoming below]]/.=20 =20 -------------- =20 Fine. Text in =C2=A74 should probably be aligned with the above ..e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. =20 NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and = received the Extended Message Capability to and from that peer. =20 =20 ---- >=E2=80=9C Applications generating information which might be = encapsulated > within BGP messages MUST limit the size of their payload to take the > maximum message size into account.=E2=80=9D >=20 >I don=E2=80=99t see what new behavior is been defined here. If there is = none, I would suggest to remove this sentence =20 Bruno =E2=80=93 people asked to put this text in as an operational = warning. At this point, I=E2=80=99m going to say unless there is harm = it should remain. =20 [Bruno] OK. =20 ---- > A BGP announcement will, in the normal case, propagate throughout = the > BGP speaking Internet; and there will undoubtedly be BGP speakers > which do not have the Extended Message capability. Therefore, > putting an attribute which can not be decomposed to 4096 octets or > less in an Extended Message is a likely path to routing failure. >=20 >The issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than >4096, irrespective of the size = of each attribute. >Please elaborate on what you mean by=20 >=20 >=E2=80=9Can attribute which cannot be decomposed to 4096 = octets=E2=80=9D =20 An attribute which cannot be decomposed to 4096 is an attribute with = length 6000 inside of a BGP message which requires the entire attribute = to be included. No such attribute exists today. If a small BGP peers = create a =E2=80=9Ckiller application=E2=80=9D that uses a 6000 byte = attribute, the rest of the Internet does not have to use it. However, = the person defining that attribute must carefully specify it must go = with Extended BGP messages.=20 =20 =20 [Bruno] I don=E2=80=99t think that I agree with this. E.g. I = don=E2=80=99t see where RFCs 1997 or 8092 [(large)community] limits the = size of their attribute. Hence I don=E2=80=99t see why you could not = have, today (with Extended Message support) , attributes larger than = 4096 octets. Most probably same status for the BGPSec attribute since = they wanted for more space. [Sue]: You make a good point about the possibility of large communities = not limiting the size. It is worthy of a change to both the large = communities and a footnote in Randy=E2=80=99s specification. How about = the addition of a single sentence to point people in the right = direction.=20 =20 Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed = if it=20 sent in Extended message is a large community attribute with 1000 = communities.=20 (12,000 bytes). =20 / =20 =20 This text was added during an earlier discussion where the error cases = of a large BGP attribute was given. The originator of the common could = not provide the exact description, but we agreed to put this = =E2=80=9Cwarning label=E2=80=9D into the draft. This is one of the = cases where adding/removing text gets to be problematic.=20 =20 >--- >=E2=80=9C It is RECOMMENDED that BGP protocol developers and = implementers are > conservative in their application and use of Extended = Messages.=E2=80=9D >=20 >What does this mean exactly? That they don=E2=80=99t use this = extension?=20 >That they don=E2=80=99t use this extension unless XX_TO BE = SPECIFIED_XX? =20 This warning was text that other participants asked to be added.=20 =20 It is a common sense warning. Extended messages are enabled on a peer = by peer basis as all BGP capabilities are. If you run into a Peer that = does not support the larger sizes, the BGP messages will need to be = reformatted to the smaller size. Running immediately to the Extended = messages as the default could cause problems.=20 =20 [Bruno] I think that the sentence could be elaborated. Indicating the = problem, how the specification partially address it, and how the = specification does not address it. In =E2=80=9CRunning immediately to Extended Message=E2=80=9D I = don=E2=80=99t think they that the issue is with = =E2=80=9Cimmediately=E2=80=9D. Whenever you start the transition, your = likely to run into problems. =20 =20 [Sue]: IMHO specification specifies how to encode the bytes on the wire = and the appropriate error handling of the messages. If I have missed = something in this case, please let me know.=20 =20 The specification does not specify the necessary policies implementation = should have in order to decide what to do in the case of mixed network. = The clear indication was this type was not appropriate for the protocol = specification. =20 =20 Earlier discussion indicated that these is policy and mechanism = specific. It is worthy of =E2=80=9Cuse case or application = notes=E2=80=9D written for specific applications (BESS, SPRING, GROW), = but not in the specification. Again, if it is significant enough = concern for operators and implementers =E2=80=93 it would be worthy to = have combined use case document besides this point. I=E2=80=99m happy = to sponsor cross-area work on this use case.=20 =20 --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages. =20 >Why is this limited to future specifications? A priori, using existing = BGP mechanism (AFI/SAFI, attributes, * >communities) one could exceed = the size of 4096 octets. How does the BGP speaker supposed to behave in = this ?>case? This should be described in this specification. Note that = this is not a case of error handling, as every BGP=20 > speaker is behaving as specified. =20 I fail to see your logic. At this point, all BGP data (AFI/SAFI and = attributes) must fit within a 4096 message. Therefore, a BGP peer A = which connects on link 1 to BGP peer B with 4096 message and on link to = a BGP peer C with extended messages only has to worry about reformatting = the data. =20 =20 In the future, the first group that defines attribute or an NLRI that = does not fit within a 4096 BGP message and cannot be split, will need to = define how that works in the specification. There is no need to refine = the current set of specifications. =20 [Bruno] 1) cf above, I believe that there are existing BGP Attributes which may = not fit into a bytes 4096 BGP message 2)Even in the absence of such attribute, you have the issue of 2 smaller = attributes whose cumulative size does not fit into a 4096 bytes message. =20 The problem is introduced by this specification, hence I believe this = specification needs to specify how to handle this case. =20 [Sue]: IHMO the message transmission and reception error handling = issues are complete in the combination of RFC4271 and the extended = message section 5.=20 =20 What is not in this specification is the policy issues about what = happens if you combine 2 smaller attributes. For example, if you have a = large community attribute of 400 communities (4800 bytes), you will = likely run into problems when combining with some longer AS path = lengths. [4800=C3=A0 5096 bytes is a short jump]. People on the list = and in-person argued this was policy and implementation specific = details. =20 =20 I agree with you that it is extremely useful to the operator community = to have this type of policy details discussed to see if there is some = desire to have common policies and error communities. It is the type = of thing that GROW and IDR should be deeply involved for large = communities. BESS, LSVR, SPRING and others should consider what policy = should be adapted for their applications.=20 =20 >---- >Depending on the above specification, a section describing the = operational consequences in a network (such as the >Internet, BGP = Enabled ServiceS/VPN networks) is probably needed. Possible consequences = could be BGP NLRI >being removed in the middle of such network, or = (extended) community (such as Route Targets) been removed. >Both having = significant consequences on the availability provided by the network. =20 At this point, there are no attributes or NLRI groupings that do not fit = within 4096. If you define one (as SIDR did), then you will need to = have it reviewed by IDR, BESS, SPRING, and operational groups (GROW, = etc).=20 [Bruno] no, cf above. [Sue]: Thank you for reminding me of the potential of large communities = to blow up BGP. I have a new worry to add to my BGP concerns list!=20 =20 Thanks, --Bruno =20 =20 --- >=C2=A74 >OLD: The Extended Message Capability only applies to all messages = except for the >OPEN message.=20 >Probably >NEW: The Extended Message Capability applies to all message types = except for the >OPEN message (type 1).=20 >---- >=C2=A78 >=E2=80=9CThis extension to BGP does not change BGP's underlying = security issues =C2=BB >Before evaluating this, I think this document should first specified = how a BGP=20 >messages bigger than 4096 octets is handled when it needs to be sent to = a=20 >received not supporting this extension. =20 Nits: >OLD : to reduce compexity >NEW : to reduce complexity =20 Thanks, --Bruno =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org Subject: [Idr] WG Last Call on Extened Message Support =20 =20 This begins a 2 week WG LC on Extended Message Support for BGP = (draft-ietf-idr-bgp-extended-messages-27). You can access the draft at: = =20 = = https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ =20 The authors should indicate whether they know of any IPR. Implementers = are encouraged to update the implementation data at:=20 =20 = = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations =20 The draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages. BGP message space is running = short for all of the potential attributes or additions proposed by = BGP-LS features. =20 =20 The WG chairs intend to forward this draft to the IESG with the current = level of implementation. =20 =20 As you comment on the draft, please consider if: a) the technology is = mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for = publication. =20 =20 Sue Hares (WG Chair, Shepherd)=20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_00F5_01D4C46B.AB823910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Robert:

 

Thank you for your message and your concerns regarding BGP in the = Internet. =C2=A0=C2=A0See my comments below.

 

Sue

 

From:= = Robert Raszuk [mailto:robert@raszuk.net]
Sent: Thursday, = February 14, 2019 12:34 PM
To: Susan Hares
Cc: Bruno = Decraene; idr@ietf. org
Subject: Re: [Idr] WG Last Call on = Extened Message Support

 

Dear Sue & authors of this = proposal,

 

>> = Therefore, putting an attribute which cannot be decomposed = to 

>> = 4096 octets or less in an Extended Message is a likely path = to 

>> = routing failure.

>That's = brilliant statement but not enough to proceed with this = spec. 

>See the = fundamental change that today such issue is in vast majority of cases = locally significant. That means that if I send NLRI to BGP it = will have a decent chance to be received by all intended = parties. 

[Sue]: The reason you receive this NLRI is due to the peer-wise = agreements of all the BGP peers in the cloud.=C2=A0 Each peer agrees to = send routing based on its policies and capabilities. =C2=A0=C2=A0Policy = and implementation specific details are not in BGP specifications. =

>With = new spec we are saying that it may silently fail = somewhere in the middle and we do not do anything = about it. That's to me showstopper. 

[Sue]: Where do you see the point it must = silently fail or an operator will not do anything about it?=C2=A0 =

The error message handling specified in the draft and in = RFC4271.=C2=A0 If see errors in the error handling as specified please = send that to the list. =C2=A0=C2=A0These errors must be on the = peer-to-peer protocol exchange.

The peer-wise agreements specify the length of a BGP message. = =C2=A0BGP peers receiving a large packet and expecting to send it to a = peer which has 4096 bytes as a message size, will need to repackage = it.=C2=A0 If it cannot be repackaged, then the BGP implementation needs = to warn the operator.=C2=A0=C2=A0 If the BGP peers cannot repackage BGP = messages today, there should be error messages and = =E2=80=9Cbells=E2=80=9D ringing.=C2=A0 If the implementation does not = have the appropriate warning systems, please see your = vendor.

What show stopper deployed today are you talking about? =C2=A0I do = not perceive any show-stopper on the peer-to-peer communication. =

At min = if given NLRI can not be sent with XXL attributes to some peers (say on = the RR which Bruno mentioned) we must specify protocol extension in = this very spec on how to deal with it. 

[Sue]: =C2=A0We cannot send the 12K large = community attribute now.=C2=A0 This protocol specification deals with = what happens when you send and receive BGP packets. =C2=A0The BGP peers = negotiate the length of the BGP message that can be sent/received.=C2=A0 = It has been tested and deployed (see comment about OpenDaylight) for = some years.=C2=A0

Your description indicates a = =E2=80=9Cnetwork-wide=E2=80=9D requirement.=C2=A0 A network-wide = requirement is based on the specific needs of an application + = BGP.=C2=A0 For example, some Data center BGP applications are very = different than EVPN BGP over MPLS. =C2=A0

Such = extension may be as simple as to define a short attribute = BGP_PIPE_TOO_THIN which will be inserted in the place where XXL = attribute just did not fit smaller message size peers to tell them then = "Hey something is broken with this NLRI" - pls check. Then it = will be up to local policy to install such NLRI or drop = it. 

[sue]This idea is orthogonal to the basic BGP engine.=C2=A0 It is = similar to ideas that have been kicked around in Grow and IDR for a = while.=C2=A0 If this use case gives new focus to these ideas, please = write a specification and suggest it to the IDR and Grow WG.=C2=A0=C2=A0 = IDR can look at the passage of error messages.=C2=A0 Grow can look at = how useful it is for the general BGP. =C2=A0We=E2=80=99ve talk about the = error message concept for 10+ years, but the tradeoff for the error = message has not given enough benefits to operators.=C2=A0 = =C2=A0=C2=A0Perhaps this is the =E2=80=9Ckiller-application=E2=80=9D = application.. =C2=A0

Thx,
R.

 

 

On = Thu, Feb 14, 2019 at 6:21 PM Susan Hares <shares@ndzh.com> = wrote:

Bruno:

 

Thank you for careful considerations on the use case.   I = think we have translation issues between our =E2=80=9CEnglish=E2=80=9D = language again so I have tried to be precise in the detailed = comments.  I=E2=80=99ve summarized my comments as well to help us = take the next step.

 

Sue

 

Summary

----

Good catch on the 1000 large BGP communities blowing up the message = size!  This is a case where a code path could get caught with = program error.  The error handling (section 6.1 in RFC4271 per = section 5 in the extended specification) IMHO handles the case where the = attribute is longer than the message.   Please let me know if = I=E2=80=99ve missed something.   

 

As I understand it,  you are asking this specification to be = expanded to add notes on policies on what implementation should do to = correctly combine RFC4271 length sizes with extended length = sizes.   The implementers and operations people commented = earlier that this should not be in the protocol specification other than = as a brief footnote. 

 

I agree there is a need for such standardization as BCPs for = particular use cases (large communities, BESS (EVPN or centralized = controller), SPRING, BGP-LS information (see Daylight comments = yesterday), SD-WANs (rtgwg), and SPRING.   I think the chairs = of the WGs utilizing should consider if there is need for = standardization for a minimal set of policy for message sizes for = specific use cases.   I will be glad to send request to these = WG or to host something in IDR if there is policy that can be used = across all use cases.

 

To provide a slight expansion to point people in this direction, how = about this change to paragraph in section 4:

 

Old/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which can not be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

/

New/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which cannot be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

   One example of a valid attribute which = cannot be precisely decomposed if it

   sent in Extended message is a large = community attribute with 1000 communities.

   (12,000 bytes).  =

/

[PS = =E2=80=93 in American English =E2=80=9CCan not=E2=80=9D is normally = concatenated =E2=80=9Ccannot=E2=80=9D.]

   

 

 

 

From:= = bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: = Thursday, February 14, 2019 3:29 AM
To: Susan = Hares
Cc: idr@ietf.org; 'Jakob Heitz = (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message = Support

 <= /o:p>

Sue,

 

Thanks for the reply. Please see inline = [Bruno]

 

From:= Susan = Hares [mailto:shares@ndzh.com]
Sent: Wednesday, = February 13, 2019 8:03 PM
To: DECRAENE Bruno = TGI/OLN
Cc: idr@ietf.org; 'Jakob Heitz = (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message = Support

 

Bruno:

 

I=E2=80=99d like to answer some of the questions you sent Randy based = on comments (public and private) the chairs and I as the shepherd = received on this draft in our last WG LCs. =   

 

Several of the comments you questioned were put in to answer other = questions.   This gets into a catch-22=E2=80=A6 problem = =E2=80=93 where you put changes in for one person/take out the changes = out for another.  In academic circles this is called the reviewer = #2 problem (reviewer 1 insists changes go in, reviewer 2 insists changes = go out) during publication.  Therefore, I=E2=80=99m I am going to = answer most of your questions where this is the case.  =

 

I believe that Randy has new version with the changes I=E2=80=99ve = indicated.  I=E2=80=99m hoping he=E2=80=99ll just post that = version.  AFAILK, we do have 2 compliant implementations. =

 

Sue

 

 

 

<shepherd hat on>

This draft=E2=80=99s technology provides efficient processing for = some application by allow a huge BGP message size.  Whether = =E2=80=9Cchunking=E2=80=9D BGP to 4096 byte messages or packing large = amounts of data into 65,000 byte message is more effective for a = particular application is something only an implementer of a particular = BGP implementation  can decide.   This draft simply gives = freedom for applications to not be restrict to an artificially small = message size.  The market place will choose whether this technology = is used or not. 

 

As Jakob pointed out, changing a highly tuned BGP implementation = which =E2=80=9Cchunks=E2=80=9D BGP data into 4096 byte messages may = involve substantial rework of the implementation.  =

 

 

(snip)

From: Idr = <idr-bounces@ietf.org> On Behalf Of bruno.decraene@orange.com
Sent: 29 = January 2019 13:33
To: Susan Hares <shares@ndzh.com>
Cc: idr@ietf.org
Subject: Re: [Idr] WG Last = Call on Extened Message Support

 

Hi = WG,

 =

>Please find = below some comments.

>As of today, = I don=E2=80=99t believe this specification is ready to be progressed to = IESG/RFC, especially for a document >updating RFC 4271 (core BGP = spec).

 

&= gt; The WG chairs intend to forward this draft to the IESG with the = current level of implementation. 

 

>https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-= extended->implementations says : 5a =

Does not = send Extended Message capability

Yes =

Yes =

Yes =

 

>I may be = misunderstanding the implementation report, but my reading of the above = is that none of the reported >implementations sends the capability = hence no implementation supports draft-ietf-idr-bgp-extended-messages.. =

>Here this = document is updating RFC 4271, so it is not a minor extension for a = niche use case. So I don=E2=80=99t see the >arguments for not requiring the = IDR=E2=80=99s usual two interoperable = implementations.

 

>In our mail thread, we discovered that the implementation report = should have indicate

>full support.   I=E2=80=99m waiting for Olivier to = update based on the last point, but my understanding is that =

All implementations have full support.  

 

[Bruno] ok, solved

>----

>=C2=A7 = 1

>=E2=80=9C As BGP is = extended to support newer AFI/SAFIs and

>   newer = capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there = is

>   a need = to extend the maximum message size beyond 4096 octets.  = =E2=80=9C

> 

> https://tools.ietf.org/html/draft-ietf-idr-bgp-extended= -messages-27#section-1

 

 

>[I-D.ietf-sidr-bgpsec-protocol is now RFC = 8205 (thanks for updating the reference). It has removed the = normative/any >reference to = draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not = need draft-ietf-idr-bgp->extended-messages. Can we have an update on this?  Can the introduction of draft-ietf-idr-bgp-extended-messages >be = updated to introduce on the real = reasons/needs?

 

SIDR gave up waiting on IDR=E2=80=99s work and took a reduced size of = encryption.   The security people were very sad about the = reduction.  How is this working in practice? WG sidrops can answer = this question. 

 

The real problem is there is finite message space.  =

[Bruno] So too bad the draft does not solve the real problem ;-) (as = message space is still limited)

 

[Sue]: The message is still finite (smile),  but I hope 65,635 = (smile) is probably enough for 10 years.  =  

 

There are two ways to send lots of BGP routes and/or attributes = =E2=80=93 to =E2=80=9Cchunk=E2=80=9D these into small message sizes or = place these into a large message.    Some applications = may always want to =E2=80=9Cchunk=E2=80=9D into message sizes smaller = than 4096.   Some application make work more efficiently = utilizing large message size.  As the potential number of NLRI and = BGP attributes grows, new applications may consider large message sizes = to a more reasonable way to exchange amounts of BGP data.   =  

 

The decision on how to send BGP messages over the wire is a = peer-by-peer decision in a network.   Each BGP peer is in = charge of reformatting the BGP message it sends to the remote BGP = peer.   The BGP capabilities in this draft represent an = agreement between two BGP peers.  These are facts of basic BGP = implementations

[Bruno] Let=E2=80=99s take the example of a BGP Route Reflector = having a mixed of clients, some supporting Extend Message (EM) and some = not.

From an EM client, it receives a BGP update containing one (single) = NLRI with an Total Path Attribute Length bigger than  4090 byte = (e.g. having 1000 large communitiess)

Can you explain me how it behaves to send this NLRI to an IBGP peer = not supporting EM?

[Sue]:  Gladly=E2=80=A6

A BGP route reflector (RR-A) is peering with each of its BGP = clients.   It agrees with each of its clients (BGP-C1, BGPC2, = BGPC3) whether the BGP Extended messages is accepted or not (based on = capability announcement).

Let us assume that BGP-C1 does not support extended messages, and =  BGP-C2 and BGP-C3 do support extended messages. =

 

If the policy in RR accepts a total path length of 1000 large = communities with  a single NLRI, it may send the BGP attribute via = extended communities to BGP-C2 and = BGP-C2.

The policy in the RR must specify whether: =

a)      = the =E2=80=9Ctoo long=E2=80=9D attribute path length must be dropped, = or

b)      = the BGP attribute path can be truncated. =

 

This is a policy issue within the BGP peer and the network operation = staff.  Each operator may choose to write this policy differently. =

 

Rather than specify the numerous cases in the protocol specification, =  the previous discussions (private and public) asked us to trim = this information out of the protocol specification. =

 

If you believe this is worthy of a use case draft for the sake of = BESS, LSVR, SPRING, Grow and others, I will happily WG chair sponsor a = draft that can be reviewed by all these WGs. =

 

 

=E2=80=93 so I do not believe adding these facts to Randy=E2=80=99s = draft is useful.  In fact, in the previous rounds of review this = point was made.

 

Your question (and perhaps Jakob=E2=80=99s) is whether we have = reached a time/place where the =E2=80=9Cchunking=E2=80=9D approach will = fail on a peer-by-peer basis?   This draft does not make this = statement. 

 

The point of this draft is to enable more efficient processing by = increasing the message size for BGP peers that send a lot of data (e.g. = BGP-LS) .   The choice to =E2=80=9Cchunk=E2=80=9D or stream in = large BGP message is an implementation choice for a particular BGP = application. 

&= nbsp;

----

=C2=A74

=C2=A73 says =
=E2=80=9CA peer which does not advertise this capability MUST NOT =
send BGP

  =  Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.=E2=80=9D

[I believe randy accepted this change with the following text in = version 4 [upcoming below]]/.

 

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

&= nbsp;

F= ine. Text in =C2=A74 should probably be aligned with the above = ..e.g.

OLD: A BGP =
speaker

   MAY = send Extended Messages to its peer only if it has received = the

   = Extended Message Capability from that peer.

&= nbsp;

N= EW:

A BGP = speaker

   MAY = send Extended Messages to its peer only if it has sent and received = the

   = Extended Message Capability to and from that = peer.

 

 

----

>=E2=80=9C&n=
bsp;  Applications generating information which might be =
encapsulated

>   within = BGP messages MUST limit the size of their payload to take = the

>   = maximum message size into account.=E2=80=9D

> 

>I = don=E2=80=99t see what new behavior is been defined here. If there is = none, I would suggest to remove this sentence

 

Bruno =E2=80=93 people asked to put this text in as an operational = warning.  At this point, I=E2=80=99m going to say unless there is = harm it should remain. 

[Bruno] OK.

&= nbsp;

-= ---

>   A BGP = announcement will, in the normal case, propagate throughout = the

>   BGP = speaking Internet; and there will undoubtedly be BGP = speakers

>   which = do not have the Extended Message capability.  = Therefore,

>   = putting an attribute which can not be decomposed to 4096 octets = or

>   less = in an Extended Message is a likely path to routing = failure.

>&= nbsp;

>T= he issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than >4= 096, irrespective of the size of each attribute.

>P= lease elaborate on what you mean by

> 

>=E2= =80=9Can attribute which cannot be decomposed to 4096 = octets=E2=80=9D

 

An attribute which cannot be decomposed to 4096 is an attribute with = length 6000 inside of a BGP message which requires the entire attribute = to be included.   No such attribute exists today.  =  If a small BGP peers create a =E2=80=9Ckiller application=E2=80=9D = that uses a 6000 byte attribute, the rest of the Internet does not have = to use it.   However, the person defining that attribute must = carefully specify it must go with Extended BGP messages. =

 

 

[Bruno] I don=E2=80=99t think that I agree with this. E.g. I = don=E2=80=99t see where RFCs 1997 or 8092 [(large)community] limits the = size of their attribute. Hence I don=E2=80=99t see why you could not = have, today (with Extended Message support) , attributes larger than = 4096 octets. Most probably same status for the BGPSec attribute since = they wanted for more space.

[Sue]: You make a good point about the possibility of large = communities not limiting the size.  It is worthy of a change to = both the large communities and a footnote in Randy=E2=80=99s = specification.  How about the addition of a single sentence to = point people in the right direction.

 

Old/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which can not be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

/

New/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which cannot be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

   One example of a valid attribute which = cannot be precisely decomposed if it

   sent in Extended message is a large = community attribute with 1000 communities.

   (12,000 bytes).  =

/

  =

 

This text was added during an earlier discussion where the error = cases of a large BGP attribute was given.  The originator of the = common could not provide the exact description, but we agreed to put = this  =E2=80=9Cwarning label=E2=80=9D into the draft.   = This is one of the cases where adding/removing text gets to be = problematic.

 

>-= --

>=E2=80=9C   It is RECOMMENDED that BGP protocol = developers and implementers are

>   = conservative in their application and use of Extended = Messages.=E2=80=9D

> 

>What does = this mean exactly? That they don=E2=80=99t use this extension? =

>That they = don=E2=80=99t use this extension unless XX_TO BE = SPECIFIED_XX?

 

This warning was text that other participants asked to be added. =

 

It is a common sense warning.  Extended messages are enabled on = a peer by peer basis as all BGP capabilities are.  If you run into = a Peer that does not support the larger sizes, the BGP messages will = need to be reformatted to the smaller size.   Running = immediately to the Extended messages as the default could cause = problems.

 

[Bruno] I think that the sentence could be elaborated. Indicating the = problem, how the specification partially address it, and how the = specification does not address it.

In =E2=80=9CRunning immediately to Extended Message=E2=80=9D I = don=E2=80=99t think they that the issue is with = =E2=80=9Cimmediately=E2=80=9D. Whenever you start the transition, your = likely to run into problems.

 

 

[Sue]: IMHO specification specifies how to encode the bytes on the = wire and the appropriate error handling of the messages.   If = I have missed something in this case, please let me know. =

 

The specification does not specify the necessary policies = implementation should have in order to decide what to do in the case of = mixed network.   The clear indication was this type was not = appropriate for the protocol specification. =  

 

Earlier discussion indicated that these is policy and mechanism = specific.  It is worthy of =E2=80=9Cuse case or application = notes=E2=80=9D written for specific applications (BESS, SPRING, GROW), = but not in the specification.  Again, if it is significant enough = concern for operators and implementers =E2=80=93 it would be worthy to = have combined use case document besides this point. =    I=E2=80=99m happy to sponsor cross-area work on this = use case.

 

-= --

  = Future protocol specifications will need to describe how to = handle

   peers which can only accommodate 4096 octet = messages.

&= nbsp;

>Why is this = limited to future specifications? A priori, using existing BGP mechanism = (AFI/SAFI, attributes, * >communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = ?>case? This should be described = in this specification. Note that this is not a case of error handling, = as every BGP

> speaker is = behaving as specified.

 

I fail to see your logic.  At this point, all BGP data (AFI/SAFI = and attributes) must fit within a 4096 message.   Therefore, a = BGP peer A which connects on link 1 to BGP peer B with 4096 message and = on link to a BGP peer C with extended messages only has to worry about = reformatting the data. 

 

In the future, the first group that defines attribute or an NLRI that = does not fit within a 4096 BGP message and cannot be split, will need to = define how that works in the specification.  There is no need to = refine the current set of specifications.   =

[Bruno]

1) cf above, I believe that there are existing BGP Attributes which = may not fit into a bytes 4096 BGP = message

2)Even in the absence of such attribute, you have the issue of 2 = smaller attributes whose cumulative size does not fit into a 4096 bytes = message.

 

The problem is introduced by this specification, hence I believe this = specification needs to specify how to handle this = case.

 

[Sue]:  IHMO the message transmission and reception error = handling issues are complete in the combination of RFC4271 and the = extended message section 5.

 

What is not in this specification is the policy issues about what = happens if you combine 2 smaller attributes.  For example, if you = have a large community attribute of 400 communities (4800 bytes), you = will likely run into problems when combining with some longer AS path = lengths.  [4800=C3=A0 5096 bytes is a short jump]. People on the list and in-person argued = this was policy and implementation specific details.  =

 

I agree with you that it is extremely useful to the operator = community to have this type of policy details discussed to see if there = is some desire to have common policies and error communities. =   It is the type of thing that GROW and IDR should be deeply = involved for large communities.   BESS, LSVR, SPRING and = others should consider what policy should be adapted for their = applications.

 

>-= ---

>D= epending on the above specification, a section describing the = operational consequences in a network (such as the >I= nternet, BGP Enabled ServiceS/VPN networks) is probably needed. Possible = consequences could be BGP NLRI >b= eing removed in the middle of such network, or (extended) community = (such as Route Targets) been removed. >B= oth having significant consequences on the availability provided by the = network.

 

At this point, there are no attributes or NLRI groupings that do not = fit within 4096.   If you define one (as SIDR did), then you = will need to have it reviewed by IDR, BESS, SPRING, and operational = groups (GROW, etc). 

[Bruno] no, cf above.

[Sue]:  Thank you for reminding me of the potential of large = communities to blow up BGP.  I have a new worry to add to my BGP = concerns list!

 

Thanks,

--Bruno

 

&= nbsp;

-= --

>=C2= =A74

>OLD: The Extended = Message Capability only applies to all messages except for the >OPEN message. =

>Probably

>NEW: The Extended = Message Capability applies to all message types except for the >OPEN message (type 1). =

>----

>=C2=A78

>=E2=80=9CThis extension to BGP does =
not change BGP's underlying security =
issues =C2=BB
>Before evaluating this, I think this =
document should first specified how a BGP 
>messages bigger than 4096 octets is =
handled when it needs to be sent to a 
>received not supporting this extension.

 

N= its:

>OLD : to = reduce compexity

>NEW : to = reduce complexity

 

T= hanks,

-= -Bruno

&= nbsp;

From:= Idr [mailto:idr-bounces@ietf.org] On Behalf Of = Susan Hares
Sent: Tuesday, January 29, 2019 12:33 = PM
To: idr@ietf.org
Subject: [Idr] WG Last Call = on Extened Message Support

 

&= nbsp;

T= his begins a 2 week WG LC on Extended Message Support for BGP = (draft-ietf-idr-bgp-extended-messages-27).  You can access the = draft at:

&= nbsp;

https://datat= racker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/=

&= nbsp;

T= he authors should indicate whether they know of any IPR.   = Implementers are encouraged to update the  implementation data at: =

&= nbsp;

https://trac.= ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations=

&= nbsp;

T= he draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages.  BGP message space is = running short for all of the potential attributes or additions proposed = by BGP-LS features. 

&= nbsp;

T= he WG chairs intend to forward this draft to the IESG with the current = level of implementation. 

&= nbsp;

A= s you comment on the draft, please consider if: a) the technology is = mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for = publication. 

&= nbsp;

S= ue Hares (WG Chair, Shepherd)

&= nbsp;

 

__________________________________________=
_________________________________________________________________________=
______
 
Ce message et ses pieces jointes peuvent =
contenir des informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, exploites ou =
copies sans autorisation. Si vous avez recu ce message par erreur, =
veuillez le signaler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its attachments may =
contain confidential or privileged information that may be protected by =
law;
they should not be distributed, =
used or copied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange is not =
liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received this =
email in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, =
Orange is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles =
d'alteration,
Orange decline =
toute responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This =
message and its attachments may contain confidential or privileged =
information that may be protected by =
law;
they should not be =
distributed, used or copied without =
authorisation.
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments.
As emails may be altered, Orange is not liable for messages =
that have been modified, changed or =
falsified.
Thank =
you.

_______________________________________________
Idr = mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

------=_NextPart_000_00F5_01D4C46B.AB823910-- From nobody Thu Feb 14 12:05:31 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DDD131189 for ; Thu, 14 Feb 2019 12:05:29 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): X-Spam-Report: ...affic Action Interference\342\200\235: [...] \n\tCon[...] X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP4qBaT2L0tR for ; Thu, 14 Feb 2019 12:05:27 -0800 (PST) Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9FD12867A for ; Thu, 14 Feb 2019 12:05:26 -0800 (PST) Received: from 80-110-113-237.cgn.dynamic.surfer.at ([80.110.113.237] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1guNDL-0002or-38; Thu, 14 Feb 2019 21:02:32 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Christoph Loibl In-Reply-To: <20190125223507.GA10088@pfrc.org> Date: Thu, 14 Feb 2019 21:05:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <564B1465-427F-4D27-9153-ADC50EDA4F9E@tix.at> References: <6FC8208F-DB08-4DE4-BFEB-518A806B11DB@tix.at> <20190125223507.GA10088@pfrc.org> To: idr wg X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Idr] Flowspec draft-ietf-idr-rfc5575bis last (known) issue that needs to be resolved X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:05:29 -0000 Hi Jeffrey, IDR After reviewing the feedback that I received on my last mail regarding = the draft rfc5575bis (on the list as well as from the authors and Jie). = I propose the following changes to the draft regarding "Section 7.6. = Rules on Traffic Action Interference=E2=80=9D: *) Replace Section 7.6. Rules on Traffic Action Interference with the = following: 7.6. Considerations on Traffic Action Interference Since traffic actions are represented as BGP extended community values, traffic actions may interfere with each other (ie. there may be more = then one conflicting traffic-rate action associated with a single=20 flow-filter). Traffic action interference has no impact on BGP = propagation of flow filters (all communities should be propagated according to BGP = policies).=20 If a flow filter associated with interfering flow actions is selected = for packet forwarding, it is a implementation decision which of the = interfering=20 traffic action is selected. Implementors of this specification SHOULD=20 document the behaviour of their implementation in such cases. Operators are encouraged to make use of the BGP policy framework=20 supported by their implementation in order to achieve a predictable = behaviour=20 for their application (ie. match - replace - delete communities on=20 administrative boundaries). I will upload the changes soon if I receive no objections. However, I am = happy to receive feedback on this. Christoph=20 --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 25.01.2019, at 23:35, Jeffrey Haas wrote: >=20 >> *) Suggested solution B - only document the behaviour: >>=20 >> We can add to the operational consideration section that there may be >> interfering traffic actions. FS filters with interfering actions = shall >> still be propagated but the actual selection of the appropriate = actions is >> up to the implementation. If a network/fs-domain wide predictable >> behaviour is needed for an application this can still be achieved by = using >> custom BGP communities and BGP policies (plus rewriting those to the >> appropriated actions). >>=20 >> This is very =E2=80=9Clightweight=E2=80=9D and I think that solution = B may easily find >> consensus. However the benefit over RFC5575 is only very little. >>=20 >> Any preferences how we should proceed? >=20 > I'd suggest B. >=20 > The text I would suggest would roughly say: > Traffic actions are encoded as BGP extended communities. Traffic = actions, > in many cases, are expected to only be encoded once. For example, = only a > single valid traffic-rate-bytes extended community can be processed at = a > time. Operators should take precautions to not introduce conflicting > actions as a result of policy configuration. >=20 > ... >=20 > There may be some worth in adding a similar comment to implementors = about > having good policy mechanisms to make this job easy for operators. From nobody Fri Feb 15 02:25:21 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E795C130E7B for ; Fri, 15 Feb 2019 02:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFAmd-X-5nk8 for ; Fri, 15 Feb 2019 02:25:14 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C03112D7F8 for ; Fri, 15 Feb 2019 02:25:13 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4418XR20cmzCrjn; Fri, 15 Feb 2019 11:25:11 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 4418XR0gNQzDq80; Fri, 15 Feb 2019 11:25:11 +0100 (CET) Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM22.corporate.adroot.infra.ftgroup ([fe80::954c:232a:f07d:25af%21]) with mapi id 14.03.0435.000; Fri, 15 Feb 2019 11:25:10 +0100 From: To: Susan Hares CC: "idr@ietf.org" , "'Jakob Heitz (jheitz)'" , 'John Scudder' , 'Alvaro Retana' , Robert Raszuk Thread-Topic: [Idr] WG Last Call on Extened Message Support Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rAefZHwsB7dxHTgI7AvBBAac2MMOkS7ENUIAAGfEw Date: Fri, 15 Feb 2019 10:25:10 +0000 Message-ID: <31634_1550226311_5C669387_31634_352_1_53C29892C857584299CBF5D05346208A489D6640@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk> <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> <17281_1550132953_5C6526D9_17281_161_1_53C29892C857584299CBF5D05346208A489D3D92@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <00c901d4c489$8f311830$ad934890$@ndzh.com> In-Reply-To: <00c901d4c489$8f311830$ad934890$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A489D6640OPEXCAUBM43corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 10:25:20 -0000 --_000_53C29892C857584299CBF5D05346208A489D6640OPEXCAUBM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Susan, We now agree that the problem can happen with existing BGP attributes. Good= . So the argument to postpone the error handling discussion for future spec= ification defining large attributes does not hold anymore. Coming back to the draft, Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. 1) As a minor comment, the error is not limited to an (one single) att= ribute (type) which size is bigger than 4096 octets. The error happens when= the Total Path Attribute Length (for all attributes) is bigger than 4096 o= ctets. 2) As a major comment, I am asking for the specification to specify ho= w it handles that failure, which is not the result of a possible bug, but c= reated by design by the solution. It will happen. Your proposition to "raise an alarm" is required but not sufficient as we s= till need to specify what we do with this "big" route. One option could be = "treat as withdraw", another option suggested by Robert is to propagate the= NLRI with subset of attributes plus an indication of the failure ("a short= attribute BGP_PIPE_TOO_THIN"). There may be others options. To trigger the discussion on the resolution, I would propose the following = text "One BGP Route too large to be propagated to a BGP receiver not suppor= ting BGP Extended Message MUST be handled, over this BGP session, using the= Treat-as-withdraw approach as defined in [RFC7606]. The BGP speaker MAY, b= eforehand, remove some BGP attributes which are eligible to the Attribute d= iscard approach [RFC7606]." 3) Once error handling is specified, the draft will be able to discuss a. the operational considerations for this issue (e.g. The one from R= FC7606 could be referenced as-is, or used as inspiration) b. the security considerations (as a remote attacker would be able to = craft a large BGP route that will be withdrawn (assuming "treat-as-withdraw= ") somewhere in some AS, possibly creating routing inconsistencies within t= he AS) c. the proposed mitigations (e.g., an operator should enable support = for Extended messages on all IBGP sessions first, before enabling it on an = EBGP session; If not possible, an operator could define a policy to filter = BGP attributes from EBGP sessions, typically based on their type and size;.= ...) more inline [Bruno2] From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, February 14, 2019 6:20 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf.org; 'Jakob Heitz (jheitz)'; 'John Scudder'; 'Alvaro Retana' Subject: RE: [Idr] WG Last Call on Extened Message Support Bruno: Thank you for careful considerations on the use case. I think we have tra= nslation issues between our "English" language again so I have tried to be = precise in the detailed comments. I've summarized my comments as well to h= elp us take the next step. Sue Summary ---- Good catch on the 1000 large BGP communities blowing up the message size! = This is a case where a code path could get caught with program error. The = error handling (section 6.1 in RFC4271 per section 5 in the extended specif= ication) IMHO handles the case where the attribute is longer than the messa= ge. Please let me know if I've missed something. [Bruno2] I don't think that section 6.1 of RFC4271 covers this. The problem= is not a Message Header error handling as a proper BGP implementation woul= d not sent the message. (not to mention with inconsistent size) As I understand it, you are asking this specification to be expanded to ad= d notes on policies on what implementation should do to correctly combine R= FC4271 length sizes with extended length sizes. The implementers and oper= ations people commented earlier that this should not be in the protocol spe= cification other than as a brief footnote. [Bruno2]An error handling must exist even in the absence of SP policies. Th= e argument related to previous discussions does not hold IMHO as I've raise= d a new point (this happens with existing BGP attributes, not in a hypothet= ical new attribute) I agree there is a need for such standardization as BCPs for particular use= cases (large communities, BESS (EVPN or centralized controller), SPRING, B= GP-LS information (see Daylight comments yesterday), SD-WANs (rtgwg), and S= PRING. I think the chairs of the WGs utilizing should consider if there i= s need for standardization for a minimal set of policy for message sizes fo= r specific use cases. I will be glad to send request to these WG or to ho= st something in IDR if there is policy that can be used across all use case= s. [Bruno2] I don't think that Error handling is to be considered as optional = or for future consideration. To provide a slight expansion to point people in this direction, how about = this change to paragraph in section 4: Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed if= it sent in Extended message is a large community attribute with 1000 commun= ities. (12,000 bytes). / [PS - in American English "Can not" is normally concatenated "cannot".] [Bruno2] Thanks for the proposition, but this does not address my concern. From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Thursday, February 14, 2019 3:29 AM To: Susan Hares Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support Sue, Thanks for the reply. Please see inline [Bruno] From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, February 13, 2019 8:03 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support Bruno: I'd like to answer some of the questions you sent Randy based on comments (= public and private) the chairs and I as the shepherd received on this draft= in our last WG LCs. Several of the comments you questioned were put in to answer other question= s. This gets into a catch-22... problem - where you put changes in for on= e person/take out the changes out for another. In academic circles this is= called the reviewer #2 problem (reviewer 1 insists changes go in, reviewer= 2 insists changes go out) during publication. Therefore, I'm I am going t= o answer most of your questions where this is the case. I believe that Randy has new version with the changes I've indicated. I'm = hoping he'll just post that version. AFAILK, we do have 2 compliant implem= entations. Sue This draft's technology provides efficient processing for some application = by allow a huge BGP message size. Whether "chunking" BGP to 4096 byte mess= ages or packing large amounts of data into 65,000 byte message is more effe= ctive for a particular application is something only an implementer of a pa= rticular BGP implementation can decide. This draft simply gives freedom = for applications to not be restrict to an artificially small message size. = The market place will choose whether this technology is used or not. As Jakob pointed out, changing a highly tuned BGP implementation which "chu= nks" BGP data into 4096 byte messages may involve substantial rework of the= implementation. (snip) From: Idr On Behalf Of bruno.decraene@orange.com Sent: 29 January 2019 13:33 To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support Hi WG, >Please find below some comments. >As of today, I don't believe this specification is ready to be progressed = to IESG/RFC, especially for a document >updating RFC 4271 (core BGP spec). > The WG chairs intend to forward this draft to the IESG with the current l= evel of implementation. >https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended->implement= ations says : 5a Does not send Extended Message capability Yes Yes Yes >I may be misunderstanding the implementation report, but my reading of the= above is that none of the reported >implementations sends the capability h= ence no implementation supports draft-ietf-idr-bgp-extended-messages.. >Here this document is updating RFC 4271, so it is not a minor extension fo= r a niche use case. So I don't see the >arguments for not requiring the IDR= 's usual two interoperable implementations. >In our mail thread, we discovered that the implementation report should ha= ve indicate >full support. I'm waiting for Olivier to update based on the last point,= but my understanding is that All implementations have full support. [Bruno] ok, solved >---- >=A7 1 >" As BGP is extended to support newer AFI/SAFIs and > newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there is > a need to extend the maximum message size beyond 4096 octets. " > > https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on-1 >[I-D.ietf-sidr-bgpsec-protocol is now RFC 8205= (thanks for updating the reference). It has removed the normative/any >ref= erence to draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does = not need draft-ietf-idr-bgp->extended-messages. Can we have an update on th= is? Can the introduction of draft-ietf-idr-bgp-extended-messages >be updat= ed to introduce on the real reasons/needs? SIDR gave up waiting on IDR's work and took a reduced size of encryption. = The security people were very sad about the reduction. How is this workin= g in practice? WG sidrops can answer this question. The real problem is there is finite message space. [Bruno] So too bad the draft does not solve the real problem ;-) (as messag= e space is still limited) [Sue]: The message is still finite (smile), but I hope 65,635 (smile) is p= robably enough for 10 years. There are two ways to send lots of BGP routes and/or attributes - to "chunk= " these into small message sizes or place these into a large message. So= me applications may always want to "chunk" into message sizes smaller than = 4096. Some application make work more efficiently utilizing large message= size. As the potential number of NLRI and BGP attributes grows, new appli= cations may consider large message sizes to a more reasonable way to exchan= ge amounts of BGP data. The decision on how to send BGP messages over the wire is a peer-by-peer de= cision in a network. Each BGP peer is in charge of reformatting the BGP m= essage it sends to the remote BGP peer. The BGP capabilities in this draf= t represent an agreement between two BGP peers. These are facts of basic B= GP implementations [Bruno] Let's take the example of a BGP Route Reflector having a mixed of c= lients, some supporting Extend Message (EM) and some not. >From an EM client, it receives a BGP update containing one (single) NLRI wi= th an Total Path Attribute Length bigger than 4090 byte (e.g. having 1000 = large communitiess) Can you explain me how it behaves to send this NLRI to an IBGP peer not sup= porting EM? [Sue]: Gladly... A BGP route reflector (RR-A) is peering with each of its BGP clients. It = agrees with each of its clients (BGP-C1, BGPC2, BGPC3) whether the BGP Exte= nded messages is accepted or not (based on capability announcement). Let us assume that BGP-C1 does not support extended messages, and BGP-C2 a= nd BGP-C3 do support extended messages. If the policy in RR accepts a total path length of 1000 large communities w= ith a single NLRI, it may send the BGP attribute via extended communities = to BGP-C2 and BGP-C2. The policy in the RR must specify whether: a) the "too long" attribute path length must be dropped, or b) the BGP attribute path can be truncated. This is a policy issue within the BGP peer and the network operation staff.= Each operator may choose to write this policy differently. [Bruno2] So we agree that a new behavior is REQUIRED. The draft does not me= ntion this. The ability to change the behavior by policy does not remove th= e need for specifying the error handling. Rather than specify the numerous cases in the protocol specification, the = previous discussions (private and public) asked us to trim this information= out of the protocol specification. [Bruno2] Can't be have a general rule which is good enough to handle the is= sue? Previous discussions seemed based on the fact the error condition woul= d happen for future attribute. This is not the case. If you believe this is worthy of a use case draft for the sake of BESS, LSV= R, SPRING, Grow and others, I will happily WG chair sponsor a draft that ca= n be reviewed by all these WGs. [Bruno2] I believe that this is worthy in this specification. - so I do not believe adding these facts to Randy's draft is useful. In fa= ct, in the previous rounds of review this point was made. Your question (and perhaps Jakob's) is whether we have reached a time/place= where the "chunking" approach will fail on a peer-by-peer basis? This dr= aft does not make this statement. The point of this draft is to enable more efficient processing by increasin= g the message size for BGP peers that send a lot of data (e.g. BGP-LS) . = The choice to "chunk" or stream in large BGP message is an implementation c= hoice for a particular BGP application. ---- =A74 =A73 says "A peer which does not advertise this capability MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to it." [I believe randy accepted this change with the following text in version 4 = [upcoming below]]/. -------------- Fine. Text in =A74 should probably be aligned with the above .e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and received = the Extended Message Capability to and from that peer. ---- >" Applications generating information which might be encapsulated > within BGP messages MUST limit the size of their payload to take the > maximum message size into account." > >I don't see what new behavior is been defined here. If there is none, I wo= uld suggest to remove this sentence Bruno - people asked to put this text in as an operational warning. At thi= s point, I'm going to say unless there is harm it should remain. [Bruno] OK. ---- > A BGP announcement will, in the normal case, propagate throughout the > BGP speaking Internet; and there will undoubtedly be BGP speakers > which do not have the Extended Message capability. Therefore, > putting an attribute which can not be decomposed to 4096 octets or > less in an Extended Message is a likely path to routing failure. > >The issue is not specific to attributes bigger than 4096 octets, but to BG= P message whose length is bigger than >4096, irrespective of the size of ea= ch attribute. >Please elaborate on what you mean by > >"an attribute which cannot be decomposed to 4096 octets" An attribute which cannot be decomposed to 4096 is an attribute with length= 6000 inside of a BGP message which requires the entire attribute to be inc= luded. No such attribute exists today. If a small BGP peers create a "k= iller application" that uses a 6000 byte attribute, the rest of the Interne= t does not have to use it. However, the person defining that attribute mu= st carefully specify it must go with Extended BGP messages. [Bruno] I don't think that I agree with this. E.g. I don't see where RFCs 1= 997 or 8092 [(large)community] limits the size of their attribute. Hence I = don't see why you could not have, today (with Extended Message support) , a= ttributes larger than 4096 octets. Most probably same status for the BGPSec= attribute since they wanted for more space. [Sue]: You make a good point about the possibility of large communities not= limiting the size. It is worthy of a change to both the large communities= and a footnote in Randy's specification. How about the addition of a sing= le sentence to point people in the right direction. Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed if= it sent in Extended message is a large community attribute with 1000 commun= ities. (12,000 bytes). / This text was added during an earlier discussion where the error cases of a= large BGP attribute was given. The originator of the common could not pro= vide the exact description, but we agreed to put this "warning label" into= the draft. This is one of the cases where adding/removing text gets to b= e problematic. >--- >" It is RECOMMENDED that BGP protocol developers and implementers are > conservative in their application and use of Extended Messages." > >What does this mean exactly? That they don't use this extension? >That they don't use this extension unless XX_TO BE SPECIFIED_XX? This warning was text that other participants asked to be added. It is a common sense warning. Extended messages are enabled on a peer by p= eer basis as all BGP capabilities are. If you run into a Peer that does no= t support the larger sizes, the BGP messages will need to be reformatted to= the smaller size. Running immediately to the Extended messages as the de= fault could cause problems. [Bruno] I think that the sentence could be elaborated. Indicating the probl= em, how the specification partially address it, and how the specification d= oes not address it. In "Running immediately to Extended Message" I don't think they that the is= sue is with "immediately". Whenever you start the transition, your likely t= o run into problems. [Sue]: IMHO specification specifies how to encode the bytes on the wire and= the appropriate error handling of the messages. If I have missed somethi= ng in this case, please let me know. [Bruno2] IMHO specifications need to handle error conditions that they crea= te by design. The specification does not specify the necessary policies implementation sh= ould have in order to decide what to do in the case of mixed network. The= clear indication was this type was not appropriate for the protocol specif= ication. Earlier discussion indicated that these is policy and mechanism specific. = It is worthy of "use case or application notes" written for specific applic= ations (BESS, SPRING, GROW), but not in the specification. Again, if it is= significant enough concern for operators and implementers - it would be wo= rthy to have combined use case document besides this point. I'm happy to= sponsor cross-area work on this use case. --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages. >Why is this limited to future specifications? A priori, using existing BGP= mechanism (AFI/SAFI, attributes, * >communities) one could exceed the size= of 4096 octets. How does the BGP speaker supposed to behave in this ?>case= ? This should be described in this specification. Note that this is not a c= ase of error handling, as every BGP > speaker is behaving as specified. I fail to see your logic. At this point, all BGP data (AFI/SAFI and attrib= utes) must fit within a 4096 message. Therefore, a BGP peer A which conne= cts on link 1 to BGP peer B with 4096 message and on link to a BGP peer C w= ith extended messages only has to worry about reformatting the data. In the future, the first group that defines attribute or an NLRI that does = not fit within a 4096 BGP message and cannot be split, will need to define = how that works in the specification. There is no need to refine the curren= t set of specifications. [Bruno] 1) cf above, I believe that there are existing BGP Attributes which may not= fit into a bytes 4096 BGP message 2)Even in the absence of such attribute, you have the issue of 2 smaller at= tributes whose cumulative size does not fit into a 4096 bytes message. The problem is introduced by this specification, hence I believe this speci= fication needs to specify how to handle this case. [Sue]: IHMO the message transmission and reception error handling issues a= re complete in the combination of RFC4271 and the extended message section = 5. What is not in this specification is the policy issues about what happens i= f you combine 2 smaller attributes. For example, if you have a large commu= nity attribute of 400 communities (4800 bytes), you will likely run into pr= oblems when combining with some longer AS path lengths. [4800--> 5096 byte= s is a short jump]. People on the list and in-person argued this was policy= and implementation specific details. [Bruno2] It's not implementation specific. This is an issue created by the = specification. Let's discuss it in public. I agree with you that it is extremely useful to the operator community to h= ave this type of policy details discussed to see if there is some desire to= have common policies and error communities. It is the type of thing that= GROW and IDR should be deeply involved for large communities. BESS, LSVR= , SPRING and others should consider what policy should be adapted for their= applications. >---- >Depending on the above specification, a section describing the operational= consequences in a network (such as the >Internet, BGP Enabled ServiceS/VPN= networks) is probably needed. Possible consequences could be BGP NLRI >bei= ng removed in the middle of such network, or (extended) community (such as = Route Targets) been removed. >Both having significant consequences on the a= vailability provided by the network. At this point, there are no attributes or NLRI groupings that do not fit wi= thin 4096. If you define one (as SIDR did), then you will need to have it= reviewed by IDR, BESS, SPRING, and operational groups (GROW, etc). [Bruno] no, cf above. [Sue]: Thank you for reminding me of the potential of large communities to= blow up BGP. I have a new worry to add to my BGP concerns list! [Bruno2] IMHO, the problem is more with Extended Message than with large co= mmunity. And we can work to consider and address this problem. --Bruno Thanks, --Bruno --- >=A74 >OLD: The Extended Message Capability only applies to all messages except f= or the >OPEN message. >Probably >NEW: The Extended Message Capability applies to all message types except f= or the >OPEN message (type 1). >---- >=A78 >"This extension to BGP does not change BGP's underlying security issues = =BB >Before evaluating this, I think this document should first specified how a= BGP >messages bigger than 4096 octets is handled when it needs to be sent to a >received not supporting this extension. Nits: >OLD : to reduce compexity >NEW : to reduce complexity Thanks, --Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org Subject: [Idr] WG Last Call on Extened Message Support This begins a 2 week WG LC on Extended Message Support for BGP (draft-ietf-= idr-bgp-extended-messages-27). You can access the draft at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ The authors should indicate whether they know of any IPR. Implementers ar= e encouraged to update the implementation data at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementat= ions The draft provides a means for expanding the BGP message to 65535 octets fo= r all messages except OPEN messages. BGP message space is running short fo= r all of the potential attributes or additions proposed by BGP-LS features. The WG chairs intend to forward this draft to the IESG with the current lev= el of implementation. As you comment on the draft, please consider if: a) the technology is matur= e, b) the additional space in a BGP message would be helpful for those depl= oying BGP-LS or SR, and c) if the specification is ready for publication. Sue Hares (WG Chair, Shepherd) ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A489D6640OPEXCAUBM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Susan,

 

We now agree= that the problem can happen with existing BGP attributes. Good. So the argument to postpone the error handling discussion for future specific= ation defining large attributes does not hold anymore.

 <= /o:p>

Coming back = to the draft,

 <= /o:p>

Old/

   A BGP announcement will, in the normal c= ase, propagate throughout the

   BGP speaking Internet; and there will un= doubtedly be BGP speakers

   which do not have the Extended Message c= apability.  Therefore,

   putting an attribute which can not be decomposed to 4096 octets or<= /o:p>

   less in an Extended Message is a likely = path to routing failure.

 <= /o:p>

1)      As a= minor comment, the error is not limited to an (one single) attribute (type) which size is bigger than 4096 octets. The error happens when the T= otal Path Attribute Length (for all attributes) is bigger than 4096 octets.=

2)      As a= major comment, I am asking for the specification to specify how it handles that failure, which is not the result of a possible bug, but creat= ed by design by the solution. It will happen.

Your = proposition to “raise an alarm” is required but not sufficient = as we still need to specify what we do with this “big” route. One op= tion could be “treat as withdraw”, another option suggested by = Robert is to propagate the NLRI with subset of attributes plus an indicatio= n of the failure (“”). There may be others options.

To tr= igger the discussion on the resolution, I would propose the following text “One BGP Route too large to be propagated to a BGP receiver not= supporting BGP Extended Message MUST be handled, over this BGP session, us= ing the Treat-as-withdraw approach as defined in [RFC7606]. The BGP speaker= MAY, beforehand, remove some BGP attributes which are eligible to the Attribute discard approach [RFC7606].”

3)      Once= error handling is specified, the draft will be able to discuss

a.       the = operational considerations for this issue (e.g. The one from RFC7606 could be referenced as-is, or used as inspiration)

b.      the = security considerations (as a remote attacker would be able to craft a large BGP route that will be withdrawn (assuming “treat-as-withdra= w”) somewhere in some AS, possibly creating routing inconsistencies w= ithin the AS)

c.       the = proposed mitigations (e.g., an operator should enable support for Extended messages on all IBGP sessions first, before enabling it on an EBG= P session; If not possible, an operator could define a policy to filter BGP= attributes from EBGP sessions, typically based on their type and size;R= 30;.)

 <= /o:p>

more inline = [Bruno2]

 <= /o:p>

 <= /o:p>

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Thursday, February 14, 2019 6:20 PM
To: DECRAENE Bruno TGI/OLN
Cc: idr@ietf.org; 'Jakob Heitz (jheitz)'; 'John Scudder'; 'Alva= ro Retana'
Subject: RE: [Idr] WG Last Call on Extened Message Support

 

Bruno:

 

Thank you for careful considerat= ions on the use case.   I think we have translation issues between our “English” language again so I have tried to be precise in = the detailed comments.  I’ve summarized my comments as well to h= elp us take the next step.

 

Sue

 

Summary

----

Good catch on the 1000 large BGP= communities blowing up the message size!  This is a case where a code path could get caught with program error.  The error handling = (section 6.1 in RFC4271 per section 5 in the extended specification) IMHO h= andles the case where the attribute is longer than the message.   = ;Please let me know if I’ve missed something.   =

 

[Bruno2] I d= on’t think that section 6.1 of RFC4271 covers this. The problem is not a Message Header error handling as a proper BGP implementation would not s= ent the message. (not to mention with inconsistent size)<= /p>

 <= /o:p>

As I understand it,  you ar= e asking this specification to be expanded to add notes on policies on what implementation should do to correctly combine RFC4271 length sizes= with extended length sizes.   The implementers and operations pe= ople commented earlier that this should not be in the protocol specificatio= n other than as a brief footnote. 

 

[Bruno2]An e= rror handling must exist even in the absence of SP policies. The argument related to previous discussions does not hold IMHO as I’ve raised a = new point (this happens with existing BGP attributes, not in a hypothetical= new attribute)

 <= /o:p>

I agree there is a need for such= standardization as BCPs for particular use cases (large communities, BESS (EVPN or centralized controller), SPRING, BGP-LS information (see Day= light comments yesterday), SD-WANs (rtgwg), and SPRING.   I think= the chairs of the WGs utilizing should consider if there is need for stand= ardization for a minimal set of policy for message sizes for specific use cases.   I will be glad to send r= equest to these WG or to host something in IDR if there is policy that can = be used across all use cases.

 

[Bruno2] I d= on’t think that Error handling is to be considered as optional or for future consideration.

 <= /o:p>

To provide a slight expansion to= point people in this direction, how about this change to paragraph in section 4:

 

Old/

   A BGP announcement will, in the normal c= ase, propagate throughout the

   BGP speaking Internet; and there will un= doubtedly be BGP speakers

   which do not have the Extended Message c= apability.  Therefore,

   putting an attribute which can not be de= composed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

/

New/

   A BGP announcement will, in the normal c= ase, propagate throughout the

   BGP speaking Internet; and there will un= doubtedly be BGP speakers

   which do not have the Extended Message c= apability.  Therefore,

   putting an attribute which cannot be dec= omposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

   One example of a valid attribute which c= annot be precisely decomposed if it

   sent in Extended message is a large= community attribute with 1000 communities.

   (12,000 bytes). 

/

[PS – in American English “Can not”= is normally concatenated “cannot”.]

   

[Bruno2] Tha= nks for the proposition, but this does not address my concern.

 

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Thursday, February 14, 2019 3:29 AM
To: Susan Hares
Cc: idr@ietf.org; 'Jakob Heitz (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message Support

 

Sue,

 

Thanks for the reply. Please see= inline [Bruno]

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, February 13, 2019 8:03 PM
To: DECRAENE Bruno TGI/OLN
Cc: idr@ietf.org; 'Jakob Heitz (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message Support

 

Bruno:

 

I’d like to answer some of= the questions you sent Randy based on comments (public and private) the chairs and I as the shepherd received on this draft in our last WG LCs= .   

 

Several of the comments you ques= tioned were put in to answer other questions.   This gets into a catch-22… problem – where you put changes in for one person/= take out the changes out for another.  In academic circles this is cal= led the reviewer #2 problem (reviewer 1 insists changes go in, reviewer 2 i= nsists changes go out) during publication.  Therefore, I’m I am going to answer most of your questions where this is the ca= se. 

 

I believe that Randy has new ver= sion with the changes I’ve indicated.  I’m hoping he’= ;ll just post that version.  AFAILK, we do have 2 compliant implementations. <= o:p>

 

Sue

 

 

 

<shepherd hat on>

This draft’s technology pr= ovides efficient processing for some application by allow a huge BGP message size.  Whether “chunking” BGP to 4096 byte messag= es or packing large amounts of data into 65,000 byte message is more effect= ive for a particular application is something only an implementer of a part= icular BGP implementation  can decide.   This draft simply gives freedom for applications to not be restrict to an artificiall= y small message size.  The market place will choose whether this techn= ology is used or not. 

 

As Jakob pointed out, changing a= highly tuned BGP implementation which “chunks” BGP data into 4096 byte messages may involve substantial rework of the implementation.&n= bsp;

 

 

(snip)

From: Idr <idr-bounces@ietf.org> On Behalf Of bruno.decraene@orange= .com
Sent: 29 January 2019 13:33
To: Susan Hares <shares@ndzh.com>
Cc: idr@ietf.org
Subject: Re: [Idr] WG Last Call on Extened Message Support

 

Hi WG,

 

>Please find below some comments.

>As of today, I don’t believe this specification is ready to be progress= ed to IESG/RFC, especially for a document >updating RFC 4271 (core BGP spec).=

 

> The WG chairs intend to forward= this draft to the IESG with the current level of implementation. 

 

>https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-exten= ded->implementations says : 5a

Does not send Extended Message capability

Yes

Yes

Yes

 

>I may be misunderstanding the implementation report, but my reading of the a= bove is that none of the reported >implementations sends the capabili= ty hence no implementation supports draft-ietf-idr-bgp-extended-messages..

>Here this document is updating RFC 4271, so it is not a minor extension for a n= iche use case. So I don’t see the >arguments for not requiring the ID= R’s usual two interoperable implementations.

 

>In our mail thread, we disco= vered that the implementation report should have indicate=

>full support.   I&= #8217;m waiting for Olivier to update based on the last point, but my under= standing is that

All implementations have full su= pport.  

 

[Bruno] ok, solved<= /i>

>----

>=A7 1

>“ As BGP is extended to support newer AFI/SAFIs and

> &= nbsp; newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there is

> &= nbsp; a need to extend the maximum message size beyond 4096 octets.  “= ;

>&n= bsp;

> https://tools.ietf.o= rg/html/draft-ietf-idr-bgp-extended-messages-27#section-1

 

 

>[I-D.ietf-sidr-bgpsec-protocol is now RFC 8205 (t= hanks for updating the reference). It has removed the normative/any >reference to draft-ietf-idr-bgp-ex= tended-messages. So presumably BGP Sec does not need draft-ietf-idr-bgp->extended-messages. Can we have an update on this?  <= /span>Can the introduction of draft-ietf-idr-bgp-extended-messages >be update= d to introduce on the real reasons/needs?

 

SIDR gave up waiting on IDR̵= 7;s work and took a reduced size of encryption.   The security pe= ople were very sad about the reduction.  How is this working in practice? = WG sidrops can answer this question. 

 

The real problem is there is fin= ite message space. 

[Bruno] So too bad the dra= ft does not solve the real problem ;-) (as message space is still limited)

 

[Sue]: The message is still fini= te (smile),  but I hope 65,635 (smile) is probably enough for 10 years.   

 

There are two ways to send lots = of BGP routes and/or attributes – to “chunk” these into s= mall message sizes or place these into a large message.    Some = applications may always want to “chunk” into message sizes smal= ler than 4096.   Some application make work more efficiently util= izing large message size.  As the potential number of NLRI and BGP att= ributes grows, new applications may consider large message sizes to a more reasona= ble way to exchange amounts of BGP data.    

 

The decision on how to send BGP = messages over the wire is a peer-by-peer decision in a network.   Each BGP peer is in charge of reformatting the BGP message it sends = to the remote BGP peer.   The BGP capabilities in this draft repr= esent an agreement between two BGP peers.  These are facts of basic BG= P implementations

[Bruno] Let’s take t= he example of a BGP Route Reflector having a mixed of clients, some supporting Extend Message (EM) and some not.

From an EM client, it rece= ives a BGP update containing one (single) NLRI with an Total Path Attribute Length bigger than  4090 byte (e.g. having 1000 large = communitiess)

Can you explain me how it = behaves to send this NLRI to an IBGP peer not supporting EM?

[Sue]:  Gladly…

A BGP route reflector (RR-= A) is peering with each of its BGP clients.   It agrees with each of its clients (BGP-C1, BGPC2, BGPC3) whether the BGP Extended messag= es is accepted or not (based on capability announcement).

Let us assume that BGP-C1 = does not support extended messages, and  BGP-C2 and BGP-C3 do support extended messages.

 

If the policy in RR accept= s a total path length of 1000 large communities with  a single NLRI, it may send the BGP attribute via extended communities to BGP-C2 and= BGP-C2.

The policy in the RR must = specify whether:

a)  = ;    the “too long” attribute pa= th length must be dropped, or

b)  = ;    the BGP attribute path can be truncated.

 

This is a policy issue wit= hin the BGP peer and the network operation staff.  Each operator may choose to write this policy differently.

[Bruno= 2] So we agree that a new behavior is REQUIRED. The draft does not mention this. The ability to change the behavior by policy does not remove the nee= d for specifying the error handling.

 

Rather than specify the nu= merous cases in the protocol specification,  the previous discussions (private and public) asked us to trim this information out of the protocol= specification.

[Bruno= 2] Can’t be have a general rule which is good enough to handle the is= sue? Previous discussions seemed based on the fact the error condition would ha= ppen for future attribute. This is not the case.<= /p>

 

If you believe this is wor= thy of a use case draft for the sake of BESS, LSVR, SPRING, Grow and others, I will happily WG chair sponsor a draft that can be revie= wed by all these WGs.

[Bruno= 2] I believe that this is worthy in this specification.

 

 

– so I do not believe addi= ng these facts to Randy’s draft is useful.  In fact, in the prev= ious rounds of review this point was made.

 

Your question (and perhaps Jakob= ’s) is whether we have reached a time/place where the “chunking= ” approach will fail on a peer-by-peer basis?   This draft does no= t make this statement. 

 

The point of this draft is to en= able more efficient processing by increasing the message size for BGP peers that send a lot of data (e.g. BGP-LS) .   The choi= ce to “chunk” or stream in large BGP message is an implementati= on choice for a particular BGP application. 

 

----

=A74

=A73 =
says “A peer which does not a=
dvertise this capability MUST NOT send BGP

   Extended Messages, and BGP Extended Messages MUST NO= T be sent to it.&#= 8221;

[I believe randy accepted this c= hange with the following text in version 4 [upcoming below]]/.

 

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

 

Fine. Text in =A74 should probably b= e aligned with the above .e.g.

OLD: A BGP speaker

   MAY send Extended Messages to its peer only if it ha= s received the

   Extended Message Capability from that peer.

 

NEW:

A BGP speaker

   MAY send Extended Messages to its peer only if it ha= s sent and received the

   Extended Message Capability to and from that peer.

 

 

----

>“   Applicat=
ions generating information which might be encapsulated

> &=
nbsp;
 within BGP messages MUST limit the size of their payload to take the<=
/o:p>


> &=
nbsp;
 maximum message size into account.”


> 


>I
 don’t see what new behavior is been defined here. If there is none, =
I would suggest to remove this sentence


 


Bruno – people asked to pu=
t this text in as an operational warning.  At this point, I’m go=
ing
 to say unless there is harm it should remain.  


[Bruno] OK.=



 


----


> &=
nbsp;
 A BGP announcement will, in the normal case, propagate throughout the=



> &=
nbsp;
 BGP speaking Internet; and there will undoubtedly be BGP speakers


> &=
nbsp;
 which do not have the Extended Message capability.  Therefore,


> &=
nbsp;
 putting an attribute which can not be decomposed to 4096 octets or


> &=
nbsp;
 less in an Extended Message is a likely path to routing failure.


> 


>The
 issue is not specific to attributes bigger than 4096 octets, but to BGP me=
ssage whose length is bigger than
>=
4096, =
irrespective
 of the size of each attribute.


>Please
 elaborate on what you mean by 


> 


>“an
 attribute which cannot be decomposed to 4096 octets”


 


An attribute which cannot be dec=
omposed to 4096 is an attribute with length 6000 inside of a
 BGP message which requires the entire attribute to be included.  &nbs=
p;No such attribute exists today.   If a small BGP peers create a=
 “killer application” that uses a 6000 byte attribute, the rest=
 of the Internet does not have to use it.   However, the person
 defining that attribute must carefully specify it must go with Extended BG=
P messages.



 


 


[Bruno] I don’t thin=
k that I agree with this. E.g. I don’t see where RFCs 1997 or 8092
 [(large)community] limits the size of their attribute. Hence I don’t=
 see why you could not have, today (with Extended Message support) , attrib=
utes larger than 4096 octets. Most probably same status for the BGPSec attr=
ibute since they wanted for more space.


[Sue]: You make a good poi=
nt about the possibility of large communities not limiting the
 size.  It is worthy of a change to both the large communities and a f=
ootnote in Randy’s specification.  How about the addition of a s=
ingle sentence to point people in the right direction.



 


Old/


   A BGP announcement will, in the normal c=
ase, propagate throughout the


   BGP speaking Internet; and there will un=
doubtedly be BGP speakers


   which do not have the Extended Message c=
apability.  Therefore,


   putting an attribute which can not be de=
composed to 4096 octets or


   less in an Extended Message is a likely =
path to routing failure.


/


New/


   A BGP announcement will, in the normal c=
ase, propagate throughout the


   BGP speaking Internet; and there will un=
doubtedly be BGP speakers


   which do not have the Extended Message c=
apability.  Therefore,


   putting an attribute which cannot be dec=
omposed to 4096 octets or


   less in an Extended Message is a likely =
path to routing failure.


   One example of a valid attribute which c=
annot be precisely decomposed if it



   sent in Extended message is a large=
 community attribute with 1000 communities.



   (12,000 bytes). 



/


 



 


 


This text was added during an ea=
rlier discussion where the error cases of a large BGP attribute
 was given.  The originator of the common could not provide the exact =
description, but we agreed to put this  “warning label” in=
to the draft.   This is one of the cases where adding/removing te=
xt gets to be problematic.



 


>---


>“=
  
 It is RECOMMENDED that BGP protocol developers and implementers are


> &=
nbsp;
 conservative in their application and use of Extended Messages.”


>&n=
bsp;


>What
 does this mean exactly? That they don’t use this extension? 



>That
 they don’t use this extension unless XX_TO BE SPECIFIED_XX?


 


This warning was text that other=
 participants asked to be added.



 


It is a common sense warning.&nb=
sp; Extended messages are enabled on a peer by peer basis as all
 BGP capabilities are.  If you run into a Peer that does not support t=
he larger sizes, the BGP messages will need to be reformatted to the smalle=
r size.   Running immediately to the Extended messages as the def=
ault could cause problems.



 


[Bruno] I think that the s=
entence could be elaborated. Indicating the problem, how the
 specification partially address it, and how the specification does not add=
ress it.


In “Running immediat=
ely to Extended Message” I don’t think they that the issue is w=
ith
 “immediately”. Whenever you start the transition, your likely =
to run into problems.


 


 


[Sue]: IMHO specification =
specifies how to encode the bytes on the wire and the appropriate
 error handling of the messages.   If I have missed something in =
this case, please let me know.



[Bruno=
2] IMHO specifications need to handle error conditions that they create
 by design.


 


The specification does not=
 specify the necessary policies implementation should have in
 order to decide what to do in the case of mixed network.   The c=
lear indication was this type was not appropriate for the protocol specific=
ation.  


 


Earlier discussion indicat=
ed that these is policy and mechanism specific.  It is worthy
 of “use case or application notes” written for specific applic=
ations (BESS, SPRING, GROW), but not in the specification.  Again, if =
it is significant enough concern for operators and implementers – it =
would be worthy to have combined use case document besides
 this point.    I’m happy to sponsor cross-area work o=
n this use case. 


 


---


  Future protocol specifications will need to describe how t=
o handle


   peers which can only accommodate 4096 octet messages=
.


 


>Why
 is this limited to future specifications? A priori, using existing BGP mec=
hanism (AFI/SAFI, attributes, *
>communities) one could exceed the =
size of 4096 octets. How does the BGP speaker supposed to behave in this
?>case? This should be described in=
 this specification. Note that this is not a case of error handling, as eve=
ry BGP



>
speaker is behavin=
g as specified.


 


I fail to see your logic.  =
At this point, all BGP data (AFI/SAFI and attributes) must fit within
 a 4096 message.   Therefore, a BGP peer A which connects on link=
 1 to BGP peer B with 4096 message and on link to a BGP peer C with extende=
d messages only has to worry about reformatting the data. 



 


In the future, the first group t=
hat defines attribute or an NLRI that does not fit within a
 4096 BGP message and cannot be split, will need to define how that works i=
n the specification.  There is no need to refine the current set of sp=
ecifications.  



[Bruno]<=
/i>


1) cf above, I believe tha=
t there are existing BGP Attributes which may not fit into a
 bytes 4096 BGP message


2)Even in the absence of s=
uch attribute, you have the issue of 2 smaller attributes whose
 cumulative size does not fit into a 4096 bytes message.<=
/i>


 


The problem is introduced =
by this specification, hence I believe this specification needs
 to specify how to handle this case.


 


[Sue]:  IHMO the message tr=
ansmission and reception error handling issues are complete in the
 combination of RFC4271 and the extended message section 5. 


 


What is not in this specificatio=
n is the policy issues about what happens if you combine 2 smaller
 attributes.  For example, if you have a large community attribute of =
400 communities (4800 bytes), you will likely run into problems when combin=
ing with some longer AS path lengths.  [4800=E0
 5096 bytes is a short jump]. People on the list and in-person argued this =
was policy and implementation specific details.


[Bruno=
2]
 It’s not implementation specific. This is an issue created by the sp=
ecification. Let’s discuss it in public. 



 


I agree with you that it is extr=
emely useful to the operator community to have this type of
 policy details discussed to see if there is some desire to have common pol=
icies and error communities.   It is the type of thing that GROW =
and IDR should be deeply involved for large communities.   BESS, =
LSVR, SPRING and others should consider what policy
 should be adapted for their applications. 


 


>----


>Depending
 on the above specification, a section describing the operational consequen=
ces in a network (such as the
>=
Intern=
et, BGP
 Enabled ServiceS/VPN networks) is probably needed. Possible consequences c=
ould be BGP NLRI
>=
being =
removed
 in the middle of such network, or (extended) community (such as Route Targ=
ets) been removed.
>=
Both h=
aving significant
 consequences on the availability provided by the network.


 


At this point, there are no attr=
ibutes or NLRI groupings that do not fit within 4096.   If you
 define one (as SIDR did), then you will need to have it reviewed by IDR, B=
ESS, SPRING, and operational groups (GROW, etc). 


[Bruno] no, cf above.=



[Sue]:  Thank you for=
 reminding me of the potential of large communities to blow up BGP.
  I have a new worry to add to my BGP concerns list! 


[Bruno=
2] IMHO, the problem is more with Extended Message than with large communit=
y.
 And we can work to consider and address this problem.


--Brun=
o


 


Thanks,<=
/i>


--Bruno<=
/i>


 


 


---


>=A74


>OLD:
 The Extended Message Capability only applies to all messages except for th=
e 
>OPEN message. 


>Probabl=
y


>NEW:
 The Extended Message Capability applies to all message types except for th=
e 
>OPEN message (type 1). 


>----


>=A78


>“This extension to BGP does not c=
hange BGP's underlying security issues =BB


>Before evaluating this, I think this do=
cument should first specified how a BGP =



>messages bigger than 4096 octets is han=
dled when it needs to be sent to a 


>received not support=
ing this extension.


 


Nits:


>OLD&nbs=
p;:
 to reduce compexity


>NEW&nbs=
p;:
 to reduce complexity


 


Thanks,


--Bruno


 








From: Idr [mailto:id=
r-bounces@ietf.org]
On Behalf Of Susan Hares

Sent: Tuesday, January 29, 2019 12:33 PM

To: idr@ietf.org

Subject: [Idr] WG Last Call on Extened Message Support






 


 


This begins a 2 week WG LC on Extend=
ed Message Support for BGP (draft-ietf-idr-bgp-extended-messages-27). 
 You can access the draft at: 


 


https://datatracker.ietf=
.org/doc/draft-ietf-idr-bgp-extended-messages/


 


The authors should indicate whether =
they know of any IPR.   Implementers are encouraged to update
 the  implementation data at: 


 


https://trac.ie=
tf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations=
<=
/o:p>


 


The draft provides a means for expan=
ding the BGP message to 65535 octets for all messages except
 OPEN messages.  BGP message space is running short for all of the pot=
ential attributes or additions proposed by BGP-LS features. 



 


The WG chairs intend to forward this=
 draft to the IESG with the current level of implementation. 



 


As you comment on the draft, please =
consider if: a) the technology is mature, b) the additional
 space in a BGP message would be helpful for those deploying BGP-LS or SR, =
and c) if the specification is ready for publication. 



 


Sue Hares (WG Chair, Shepherd)



 


 




_=
___________________________________________________________________________=
_____________________________________________


<=
o:p> 


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as etre diffuses, exploites ou copies sans autorisation. Si vous avez recu =
ce message par erreur, veuillez le signaler


a=
 l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


T=
hank you.


_______________________________________________________=
__________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des i=
nformations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisatio=
n. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les pieces join=
tes. Les messages electroniques etant susceptibles d'alteration,=



Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confidenti=
al or privileged information that may be protected by law;


they should not be distributed, used or copied without =
authorisation.


If you have received this email in error, please notify=
 the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for mess=
ages that have been modified, changed or falsified.


Thank you.


_______________________________________________________=
__________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des i=
nformations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisatio=
n. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les pieces join=
tes. Les messages electroniques etant susceptibles d'alteration,=



Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confidenti=
al or privileged information that may be protected by law;


they should not be distributed, used or copied without =
authorisation.


If you have received this email in error, please notify=
 the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for mess=
ages that have been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A489D6640OPEXCAUBM43corp_-- From nobody Fri Feb 15 03:46:44 2019 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B44C130FDB; Fri, 15 Feb 2019 03:46:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <155023119813.4690.17595867858481669065@ietfa.amsl.com> Date: Fri, 15 Feb 2019 03:46:38 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-open-policy-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 11:46:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Route Leak Prevention using Roles in Update and Open messages Authors : Alexander Azimov Eugene Bogomazov Randy Bush Keyur Patel Kotikalapudi Sriram Filename : draft-ietf-idr-bgp-open-policy-05.txt Pages : 10 Date : 2019-02-15 Abstract: Route Leaks are the propagation of BGP prefixes which violate assumptions of BGP topology relationships; e.g. passing a route learned from one peer to another peer or to a transit provider, passing a route learned from one transit provider to another transit provider or to a peer. Today, approaches to leak prevention rely on marking routes according to operator configuration options, with no check that the configuration corresponds to that of the BGP neighbor, or enforcement that the two BGP speakers agree on the relationship. This document enhances BGP Open to establish agreement of the (peer, customer, provider, RS, RS-client, internal) relationship of two neighboring BGP speakers to enforce appropriate configuration on both sides. Propagated routes are then marked with an iOTC attribute according to agreed relationship allowing prevention of route leaks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-05 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-open-policy-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 15 05:05:22 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A5D130E74 for ; Fri, 15 Feb 2019 05:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9RVX0kArmkT for ; Fri, 15 Feb 2019 05:05:18 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052CA1275F3 for ; Fri, 15 Feb 2019 05:05:18 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id i20so16419093otl.0 for ; Fri, 15 Feb 2019 05:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=P6EvpNTPiH034eQsgUjkjXDs3yPhN0dFhol5jhMYwxk=; b=TXddcMTbSMVC7I1knN878+TFGfSEXppPiMb00XCTbYviYBj2RZ+kePZfKIKsqLQeuq 15O6BHCfwMfxstM0eA7PaARd9TdQ5VGHhzK8ioE2k4hhlodMv20jYw/RASc+T0DfrfNy hQUfuvPKktqj7mNCNszPU8xiyZaBcdoYUxnAphJOo8nFJZXAryrtdvQamL3LbST5yBsy n1n90lcqf4pWroe2x8t9NHm+fRboC0fpo/6keKuqgpqm8bs5/mOEOq/urXxmH0hduOjI iplVFft9s6LcIvyZkVIjV8o/QYwvT8oVNHyqP26qWPERKhvpHxTZi2uIBId6JMbEUCzn T7MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=P6EvpNTPiH034eQsgUjkjXDs3yPhN0dFhol5jhMYwxk=; b=qaj0yhLQ//VescBT2mnE+vnnJb8VMTAJoEMyeOFelGZpZhMc5s2K1x1MbpuY/ljppi +2zIStZxFcwiCI54GL4lwo1hDc4MwBZEbtv9+2+eN1C74GoqI/h//gIfaJXNG2V9YFks iRvRxJUqfpaBi4KSbQ/CXoW7bGMOlMOz7FqX5Yh63s2kSA0hg9Swf4SlQZ/H8vESsLxL DYJ2SLWnPn2kA3J/zuo6fBxStw7m8lkUPfSAortHEQqePJ64BS1SoYnT2Yetn1mw2vAE Opz/jZqb16XCCnx7125JFqxneoO4GbQCLFX+ZReSO+lO/nyxMRUvan4ShlB8yxaZvsXK oidA== X-Gm-Message-State: AHQUAuZx9tQ2OjnrxJmtHXf+HHjytfbgjkvvXGqkH+Kqq8AYEvUt9gLd sXsktGH8X2f7ItNahKfGtpYQDmgmvq2tdSlHmq1+w5OT X-Google-Smtp-Source: AHgI3IZxrRfiQET6vIPNENdWk6MoSrc1Gg/TZ/BtsVdnhNLRnWP8uIgsFmOhuD4CMbREaoorcAK0+ioGNlSG/THrjUM= X-Received: by 2002:a9d:480f:: with SMTP id c15mr5766141otf.265.1550235916688; Fri, 15 Feb 2019 05:05:16 -0800 (PST) MIME-Version: 1.0 References: <155023119813.4690.17595867858481669065@ietfa.amsl.com> In-Reply-To: <155023119813.4690.17595867858481669065@ietfa.amsl.com> From: Alexander Azimov Date: Fri, 15 Feb 2019 16:05:05 +0300 Message-ID: To: idr wg Content-Type: multipart/alternative; boundary="00000000000021e28a0581ee6db6" Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-open-policy-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 13:05:20 -0000 --00000000000021e28a0581ee6db6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear WG! This version includes changes in text structure and clarifications. But the most important part is the new roles: RS and RS-client. Previously the intended role for members of IXes that are present at RS was customer-provider. While it's enough from the mathematical point of view, it proved to be ambiguous for engineers and raised continuous questions. So, these new roles were added to address this problem. There are already two implementations on top of FRR and BIRD. The authors believe that the draft is ready for the WGLC. =D0=BF=D1=82, 15 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 14:47, : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Inter-Domain Routing WG of the IETF. > > Title : Route Leak Prevention using Roles in Update and > Open messages > Authors : Alexander Azimov > Eugene Bogomazov > Randy Bush > Keyur Patel > Kotikalapudi Sriram > Filename : draft-ietf-idr-bgp-open-policy-05.txt > Pages : 10 > Date : 2019-02-15 > > Abstract: > Route Leaks are the propagation of BGP prefixes which violate > assumptions of BGP topology relationships; e.g. passing a route > learned from one peer to another peer or to a transit provider, > passing a route learned from one transit provider to another transit > provider or to a peer. Today, approaches to leak prevention rely on > marking routes according to operator configuration options, with no > check that the configuration corresponds to that of the BGP neighbor, > or enforcement that the two BGP speakers agree on the relationship. > This document enhances BGP Open to establish agreement of the (peer, > customer, provider, RS, RS-client, internal) relationship of two > neighboring BGP speakers to enforce appropriate configuration on both > sides. Propagated routes are then marked with an iOTC attribute > according to agreed relationship allowing prevention of route leaks. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-05 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-open-policy-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --=20 Best regards, Alexander Azimov --00000000000021e28a0581ee6db6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear WG!

This version includes changes in text struct= ure and clarifications.

But the most important part is the new roles= : RS and RS-client. Previously the intended role for members of IXes that a= re present at RS was customer-provider. While it's enough from the math= ematical point of view, it proved to be ambiguous for engineers and raised = continuous questions. So, these new roles were added to address this proble= m.

There are already two implementations on top of FRR and BIRD. The= authors believe that the draft is ready for the WGLC.

=D0=BF=D1=82,= 15 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 14:47, <internet-drafts@ietf.org>:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Route Leak Prevention using Roles in Update and Open messages
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Alex= ander Azimov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Eugene Bogomazov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Randy Bush
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Keyur Patel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kotikalapudi Sriram
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-idr-bgp-open-policy-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-02-15

Abstract:
=C2=A0 =C2=A0Route Leaks are the propagation of BGP prefixes which violate<= br> =C2=A0 =C2=A0assumptions of BGP topology relationships; e.g. passing a rout= e
=C2=A0 =C2=A0learned from one peer to another peer or to a transit provider= ,
=C2=A0 =C2=A0passing a route learned from one transit provider to another t= ransit
=C2=A0 =C2=A0provider or to a peer.=C2=A0 Today, approaches to leak prevent= ion rely on
=C2=A0 =C2=A0marking routes according to operator configuration options, wi= th no
=C2=A0 =C2=A0check that the configuration corresponds to that of the BGP ne= ighbor,
=C2=A0 =C2=A0or enforcement that the two BGP speakers agree on the relation= ship.
=C2=A0 =C2=A0This document enhances BGP Open to establish agreement of the = (peer,
=C2=A0 =C2=A0customer, provider, RS, RS-client, internal) relationship of t= wo
=C2=A0 =C2=A0neighboring BGP speakers to enforce appropriate configuration = on both
=C2=A0 =C2=A0sides.=C2=A0 Propagated routes are then marked with an iOTC at= tribute
=C2=A0 =C2=A0according to agreed relationship allowing prevention of route = leaks.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-idr-bgp-open-policy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-= idr-bgp-open-policy-05
https://datatracker.ietf.org/= doc/html/draft-ietf-idr-bgp-open-policy-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-idr-bgp-open-policy-05


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

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

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


--
Best regards,
Alexander Azimov
--00000000000021e28a0581ee6db6-- From nobody Fri Feb 15 13:04:35 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4BF131065 for ; Fri, 15 Feb 2019 13:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNcBaoCeeCYz for ; Fri, 15 Feb 2019 13:04:32 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0493D130FE4 for ; Fri, 15 Feb 2019 13:04:31 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7C1A31E2F1; Fri, 15 Feb 2019 16:03:25 -0500 (EST) Date: Fri, 15 Feb 2019 16:03:25 -0500 From: Jeffrey Haas To: Christoph Loibl Cc: idr wg Message-ID: <20190215210325.GA28950@pfrc.org> References: <6FC8208F-DB08-4DE4-BFEB-518A806B11DB@tix.at> <20190125223507.GA10088@pfrc.org> <564B1465-427F-4D27-9153-ADC50EDA4F9E@tix.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <564B1465-427F-4D27-9153-ADC50EDA4F9E@tix.at> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] Flowspec draft-ietf-idr-rfc5575bis last (known) issue that needs to be resolved X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 21:04:34 -0000 Christoph, On Thu, Feb 14, 2019 at 09:05:21PM +0100, Christoph Loibl wrote: > After reviewing the feedback that I received on my last mail regarding the draft rfc5575bis (on the list as well as from the authors and Jie). I propose the following changes to the draft regarding "Section 7.6. Rules on Traffic Action Interference”: > > *) Replace Section 7.6. Rules on Traffic Action Interference with the following: > > > > 7.6. Considerations on Traffic Action Interference > > Since traffic actions are represented as BGP extended community values, > traffic actions may interfere with each other (ie. there may be more then than > one conflicting traffic-rate action associated with a single > flow-filter). Traffic action interference has no impact on BGP propagation > of flow filters (all communities should be propagated according to BGP policies). > > If a flow filter associated with interfering flow actions is selected for > packet forwarding, it is a implementation decision which of the interfering > traffic action is selected. Implementors of this specification SHOULD > document the behaviour of their implementation in such cases. > > Operators are encouraged to make use of the BGP policy framework > supported by their implementation in order to achieve a predictable behaviour > for their application (ie. match - replace - delete communities on > administrative boundaries). > > > > I will upload the changes soon if I receive no objections. However, I am happy to receive feedback on this. I'm happy with this text. Thanks! -- Jeff From nobody Fri Feb 15 17:02:07 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8DF12F295 for ; Fri, 15 Feb 2019 17:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=EuFPoQgQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fm4vhOdk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9jg9j1d3ibX for ; Fri, 15 Feb 2019 17:02:00 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999A8127287 for ; Fri, 15 Feb 2019 17:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=169158; q=dns/txt; s=iport; t=1550278919; x=1551488519; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4IC0DWjUTkOopul7brvcEHQC6B/4iRFUpRPsDJJH0yI=; b=EuFPoQgQsFAIETOF1m6OPnYuuEubTj21z+8vYF5KTTyrCykoPurVc9XE WfQv+qu8pDsZIRSTXL/oDZjUobBQmotB+5puw7qetUNICGBnK3RGbcOaE ALA5sins+1bijQWObccwGmPoZjtfHP38sf3aIYOwbvAnXKUQc3rk5hpzR 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AVu5uoxUGzwMTkP0Yf9uYjOoYCYzV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANSJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank4HMlDSE1N9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADQX2dc/51dJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ0jJAUmA2d0BAsnhAaDRwOEUIsdgld?= =?us-ascii?q?8lxsUgRADUAQLAQEYAQwHhEACF4NTIjQJDQEDAQECAQECbRwMhUoBAQEDAQE?= =?us-ascii?q?BGAEIBAYTAQEsCwEECwIBCBEEAQEWCwEGAwICAiULFAkIAgQBDQUIDIMNgQ5?= =?us-ascii?q?MAw0IAQ6hDwKKFHF8M4J4AQEFgURBgwcYggsDBYsngR0XgUA/gRABRoIXBy6?= =?us-ascii?q?DHgEBAgEBgRgNBQELAQUCAQYaFQ8HCQmCSjGCJoltCg4BAwcnhXGHF4shXAk?= =?us-ascii?q?ChzqDb4dEgW+Be4NZizeKQYEPhDiJDoMiAgQCBAUCDQEBBYFGOGVxcBU7gmy?= =?us-ascii?q?CHAkDBRKBAAEOgjyFFIU/cgGBJ4xCASWCJwEB?= X-IronPort-AV: E=Sophos;i="5.58,374,1544486400"; d="scan'208,217";a="301288023" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2019 01:01:56 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x1G11u0T015326 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Feb 2019 01:01:56 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 15 Feb 2019 19:01:55 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 15 Feb 2019 19:01:54 -0600 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 15 Feb 2019 19:01:54 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4IC0DWjUTkOopul7brvcEHQC6B/4iRFUpRPsDJJH0yI=; b=fm4vhOdk1fyePxE3auvwVtYf6/efF/qxpT39XVlIgIezdvlE8njZ1av5W9yN4ccPPdObbb9Za/9dGqRk99dtT6R7iXVvCB4o6GTZjI+AxXrHTfKIbqVJTJGxwg3I/vzx8Kfeyl8HAQ5/Pro76H0Do7YbZ3iSeuQ2Ba5YtfnhqTI= Received: from BN6PR11MB2050.namprd11.prod.outlook.com (10.173.26.20) by BN6PR11MB1491.namprd11.prod.outlook.com (10.172.20.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Sat, 16 Feb 2019 01:01:52 +0000 Received: from BN6PR11MB2050.namprd11.prod.outlook.com ([fe80::55bb:9b28:e053:42d7]) by BN6PR11MB2050.namprd11.prod.outlook.com ([fe80::55bb:9b28:e053:42d7%12]) with mapi id 15.20.1622.018; Sat, 16 Feb 2019 01:01:52 +0000 From: "Jakob Heitz (jheitz)" To: Robert Raszuk , Susan Hares CC: Bruno Decraene , "idr@ietf. org" Thread-Topic: [Idr] WG Last Call on Extened Message Support Thread-Index: AdS3xjQ/tSoF1syoSCC0lUpnr5BmnQACO/8QAA8HQwAAAFTwAALwiFKAABwpx4AAEoxBAAAAfXgAAEG4Q8A= Date: Sat, 16 Feb 2019 01:01:51 +0000 Message-ID: References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk> <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> <17281_1550132953_5C6526D9_17281_161_1_53C29892C857584299CBF5D05346208A489D3D92@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <00c901d4c489$8f311830$ad934890$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com; x-originating-ip: [2001:420:c0d0:1002::42] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4cec8048-6d35-4933-6660-08d693aa5658 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BN6PR11MB1491; x-ms-traffictypediagnostic: BN6PR11MB1491: x-ms-exchange-purlcount: 6 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjExTUIxNDkxOzIzOjJHKzN0RjE5U1A0dTIySFZlS25iUm5uODNl?= =?utf-8?B?Ny9xb2RraFhHSEF1WU9Rd1ViSW5nWHVPa2VIR0FkWEpIK2Z1UTBQR01GQ1Yv?= =?utf-8?B?S3hxWVNDY3Y3eDB6RmMvd2dGMXBBMjBDVXY4V1poVUNqQ1ZZSGE0bVJST3U5?= =?utf-8?B?UFZob3JVTFN1Y01UYnBjQW52WnpOUmd0Vi9iWFUxdDlDVHd4eEZaOWdxaTZS?= =?utf-8?B?Z2VoZjNkN2lOVHcvTERoeDJ1MGpkM3VmSHNZVTcwazBrd1NPYVB6ZGtUdVR5?= =?utf-8?B?VjcxdE5aTXgyVXdTclQ1N3F1bENXbGdQa0R4d1JLL3VDY0pteE9ONWFyMCsx?= =?utf-8?B?aEc5YUtCY0xoMkZPQnVHeTBybmlzdHdJTytGSVdpU1VKd3FCaEVFRnFsRE16?= =?utf-8?B?SG1GbUFBNkZwcldqYXdERW9ESVlkQlZNaEtqUzMxc2NzaFM4K3lSWlBwMlo3?= =?utf-8?B?d0M4UWpmNEdNMkJ1c3Vld0liWXV4UUNqYU81Z0tJb2hZRWtpUVovd21lWnQ4?= =?utf-8?B?eDVjb0ZQY0pETjR5cERBdSt3WmZVcGw2Wlo5UTdpZnJqZHc0VkxtSlpoZS9I?= =?utf-8?B?a3FORkpjdURMWFd2RXRiL3hVeGJ2VWtFVE9SYzVlSDUyYWtqS2ZVbTdaN0hF?= =?utf-8?B?RHJjTFZmblh6N2pESFBpdldFSHM1Vk0wK2sxYkw3aStRUi93cUlZV2xObG1N?= =?utf-8?B?S2lQcmR3TmQ4b0tkMklNQ1AvMkJ1UFVKVkZNSE9NSVhabmVKaGlwNk0vcVlk?= =?utf-8?B?MXdSS1pQMHd1cGFtcEVSZ2NPcnJjaWtsbTZ1aEhWMlk0MnpYMSszcVFtbjht?= =?utf-8?B?OThQOVRaNStrdTBaSnZmQ1pKT2thdlFEM3cyN3oyMzZSeWtRK2IzTE95emhl?= =?utf-8?B?ZDdhVEpWUWN4UXRjZXMwK0hzTkRsZFBIV0ZPYkJFWWszOGVUeWhUN3ZIU01T?= =?utf-8?B?Z0lqWkJNL21XK29RZk92dUZZN3YvZ1VZM0FnVmxwTWNDR3Y1SFBKdDBnWkFT?= =?utf-8?B?cFFCMWlWMllHT2ZnZEZaOGVzTTFXU3QrSTNaTnhXbjBWRmF0SHFadzh6SkJq?= =?utf-8?B?V0ljVmY2ZGlDSSthc0dwOHFTbEVMTlBmWk1malRKejEvcTM5VURGY3ZXZWJh?= =?utf-8?B?bVErYS93RTVGekxCSE4vV2QzZm5KVnlLK0FoMEkzOW5YbVRLbDcwT2xFc3Q2?= =?utf-8?B?L0J4QXlTek5hV0RxV3ZyYTRya045c3VRcURZcGVveHhCK2t1WmM1TnNQMlZr?= =?utf-8?B?UWRpd3QwTVpRMVB0UFBSYzZOQ2QrUTQvV0syQVZIMGY2aEpnOExRSGNLVGUv?= =?utf-8?B?bis1R0xlUzZUNFIxRlhpVUFxQjh4RXExZ3I4SVVyWkEzNmhvcDltZXJIcExN?= =?utf-8?B?T3hXK1BrT29jRmVNSWxhb2thRmZwTER0cnZpcmRDYlpPNkR0aVJwL0FSU1FG?= =?utf-8?B?ZkQ1ald1V3ludXlpZmxEdmkvcTVnWVowQ3k5QUNEUVEyMVNFWHA4amxrQkZ6?= =?utf-8?B?a0NCQVpqMFNPRk9JZmk1a3Q2QUNsbEdJaTZpWXJwOWxSMVZrN1FyNWhSTjF4?= =?utf-8?B?RFYvRU1ZQW1sZzBXOEd3V1ZmdHB4Q3NMeUFtaE9IZzk2UC9hdXZYbEJBYkxR?= =?utf-8?B?dnp0aFlSVDJzU3llckt3Rms1VUhENldkcWk1enJNQUpRalJDKzFlZ0liZEZC?= =?utf-8?B?TFZzc3NMS2NJcGJWdVkrTXhIMWhPL3RiaTZ1cUoyeld2dHk3TEcxNmFaZnVv?= =?utf-8?B?dHp4R0ZUNWdFMTJQNWhjZytEaVdHUUVXVjJNaTA5bzRMUEtFVlZ6R1ZaZWFV?= =?utf-8?B?TVVPMVUzbFRDM2l2ZTl4S2s0TGp6eDVHSTk1eERMY3QxSmw1WWhKWHhDQzc3?= =?utf-8?B?SHpybnZBQ1FMU003VlRQNWFXcWlxcVVDYUlHNHNGMWt4SDNQL1ZSLzNaK2lK?= =?utf-8?B?RlNrVmR1NGMwQTdmcW9XV2h3ZFk2VmszV1gzOFcxK05SaGl4eHpabERPM2tH?= =?utf-8?B?K2hsUDVZcnZRS0Y4WEpBQ1Z5Qi8xckxETXhPR01VUkcyT2ozLzNRQ3N1VDJ4?= =?utf-8?B?NEZIYURUeVlxRFJ2akZMcXR2RDRERVEyVUQ4anNaNjM2dUFqbENFamNUU3Qx?= =?utf-8?B?bG9Jckd3NytKbjhzYytSRDdqZG95RXplSUhnNjhEK3dYSXo5bjh4c0JBR21m?= =?utf-8?Q?HNtCo5lv/6SkOITjjSHMepnBdyS9i+L05qfmt/AF7s=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0950706AC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(39860400002)(376002)(346002)(51914003)(189003)(199004)(51444003)(53936002)(93886005)(76176011)(476003)(6246003)(7736002)(236005)(9686003)(186003)(446003)(74316002)(11346002)(478600001)(606006)(7696005)(486006)(102836004)(6436002)(6306002)(561944003)(110136005)(54906003)(54896002)(4326008)(2906002)(10710500007)(6116002)(5070765005)(33656002)(53946003)(790700001)(68736007)(5024004)(256004)(316002)(97736004)(25786009)(71190400001)(46003)(8936002)(14454004)(86362001)(14444005)(30864003)(99286004)(229853002)(71200400001)(81156014)(105586002)(81166006)(966005)(8676002)(15650500001)(66574012)(106356001)(55016002)(2420400007)(53546011)(7110500001)(6506007)(5660300002)(579004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1491; H:BN6PR11MB2050.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Q5cUq+gLz8bgYTC7R3stTtDCRscyFCTuBgeKo3atQyhjM84BfFa86fxxxlsvlo90pPOaF3PPdFyb96OmYkp7mci5tgcrpBxrbXiOvC5QN80RuBuMpV01KK2CXt9kjYxZTMUgZwmNKt8cklJuVSNQv+nhoB8dmotWIfvXfGXSYZlbaptsQGlfuVKSczm89v0SPIDGm6BYYEfhKTs8TUkL96P+wwykDUWlB+U1oLaLFZ/fGjK7OtUyaL4y0oKrOWUTZCvzPoYFRAbjbOsVWdiZxOKvXKhM4h7Z6Efxg3LLv8g86QrNmYEB2O9YldIzsDuP2UVWldI8M20aDbzsgTMzCRiwuUVPhxMZo6yKN+WrBtcNfOF2hqQRIME7Rt10O2tTZbw/+xsIuZVFBywUa/ZIh+LXF7p4YR5PWDWXdo05N10= Content-Type: multipart/alternative; boundary="_000_BN6PR11MB2050623467364B68264208D6C0610BN6PR11MB2050namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4cec8048-6d35-4933-6660-08d693aa5658 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2019 01:01:52.0490 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1491 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 01:02:06 -0000 --_000_BN6PR11MB2050623467364B68264208D6C0610BN6PR11MB2050namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhIHNob3cgc3RvcHBlciBmb3IgbWUgdG9vLg0KDQpPbmUgd2F5IHRvIHNvbHZlIGl0 IHdvdWxkIGJlIHRvIHJlc3RyaWN0IHRoZSBleHRlbmRlZCBtZXNzYWdlcyB0byBuZXcgYWRkcmVz cyBmYW1pbGllcyBvbmx5Lg0KQW55IG5ldyBhZGRyZXNzIGZhbWlseSB3b3VsZCB0aGVuIG5lZWQg dG8gc3BlY2lmeSB0aGF0IGl0IG11c3Qgc3VwcG9ydCBleHRlbmRlZCBtZXNzYWdlcywNCnN1Y2gg dGhhdCBhbGwgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBuZXcgYWRkcmVzcyBmYW1pbHkgbXVzdCBz dXBwb3J0IHRoZSBleHRlbmRlZCBtZXNzYWdlcy4NCg0KUmVnYXJkcywNCkpha29iLg0KDQpbQnJ1 bm9dIExldOKAmXMgdGFrZSB0aGUgZXhhbXBsZSBvZiBhIEJHUCBSb3V0ZSBSZWZsZWN0b3IgaGF2 aW5nIGEgbWl4ZWQgb2YgY2xpZW50cywgc29tZSBzdXBwb3J0aW5nIEV4dGVuZCBNZXNzYWdlIChF TSkgYW5kIHNvbWUgbm90Lg0KRnJvbSBhbiBFTSBjbGllbnQsIGl0IHJlY2VpdmVzIGEgQkdQIHVw ZGF0ZSBjb250YWluaW5nIG9uZSAoc2luZ2xlKSBOTFJJIHdpdGggYW4gVG90YWwgUGF0aCBBdHRy aWJ1dGUgTGVuZ3RoIGJpZ2dlciB0aGFuICA0MDkwIGJ5dGUgKGUuZy4gaGF2aW5nIDEwMDAgbGFy Z2UgY29tbXVuaXRpZXNzKQ0KQ2FuIHlvdSBleHBsYWluIG1lIGhvdyBpdCBiZWhhdmVzIHRvIHNl bmQgdGhpcyBOTFJJIHRvIGFuIElCR1AgcGVlciBub3Qgc3VwcG9ydGluZyBFTT8NCg0KDQpGcm9t OiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0K U2VudDogRnJpZGF5LCBGZWJydWFyeSAxNSwgMjAxOSAxOjM0IEFNDQpUbzogU3VzYW4gSGFyZXMg PHNoYXJlc0BuZHpoLmNvbT4NCkNjOiBCcnVubyBEZWNyYWVuZSA8YnJ1bm8uZGVjcmFlbmVAb3Jh bmdlLmNvbT47IGlkckBpZXRmLiBvcmcgPGlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWRy XSBXRyBMYXN0IENhbGwgb24gRXh0ZW5lZCBNZXNzYWdlIFN1cHBvcnQNCg0KRGVhciBTdWUgJiBh dXRob3JzIG9mIHRoaXMgcHJvcG9zYWwsDQoNCj4gVGhlcmVmb3JlLCBwdXR0aW5nIGFuIGF0dHJp YnV0ZSB3aGljaCBjYW5ub3QgYmUgZGVjb21wb3NlZCB0bw0KPiA0MDk2IG9jdGV0cyBvciBsZXNz IGluIGFuIEV4dGVuZGVkIE1lc3NhZ2UgaXMgYSBsaWtlbHkgcGF0aCB0bw0KPiByb3V0aW5nIGZh aWx1cmUuDQoNClRoYXQncyBicmlsbGlhbnQgc3RhdGVtZW50IGJ1dCBub3QgZW5vdWdoIHRvIHBy b2NlZWQgd2l0aCB0aGlzIHNwZWMuDQoNClNlZSB0aGUgZnVuZGFtZW50YWwgY2hhbmdlIHRoYXQg dG9kYXkgc3VjaCBpc3N1ZSBpcyBpbiB2YXN0IG1ham9yaXR5IG9mIGNhc2VzIGxvY2FsbHkgc2ln bmlmaWNhbnQuIFRoYXQgbWVhbnMgdGhhdCBpZiBJIHNlbmQgTkxSSSB0byBCR1AgaXQgd2lsbCBo YXZlIGEgZGVjZW50IGNoYW5jZSB0byBiZSByZWNlaXZlZCBieSBhbGwgaW50ZW5kZWQgcGFydGll cy4NCg0KV2l0aCBuZXcgc3BlYyB3ZSBhcmUgc2F5aW5nIHRoYXQgaXQgbWF5IHNpbGVudGx5IGZh aWwgc29tZXdoZXJlIGluIHRoZSBtaWRkbGUgYW5kIHdlIGRvIG5vdCBkbyBhbnl0aGluZyBhYm91 dCBpdC4gVGhhdCdzIHRvIG1lIHNob3dzdG9wcGVyLg0KDQpBdCBtaW4gaWYgZ2l2ZW4gTkxSSSBj YW4gbm90IGJlIHNlbnQgd2l0aCBYWEwgYXR0cmlidXRlcyB0byBzb21lIHBlZXJzIChzYXkgb24g dGhlIFJSIHdoaWNoIEJydW5vIG1lbnRpb25lZCkgd2UgbXVzdCBzcGVjaWZ5IHByb3RvY29sIGV4 dGVuc2lvbiBpbiB0aGlzIHZlcnkgc3BlYyBvbiBob3cgdG8gZGVhbCB3aXRoIGl0Lg0KDQpTdWNo IGV4dGVuc2lvbiBtYXkgYmUgYXMgc2ltcGxlIGFzIHRvIGRlZmluZSBhIHNob3J0IGF0dHJpYnV0 ZSBCR1BfUElQRV9UT09fVEhJTiB3aGljaCB3aWxsIGJlIGluc2VydGVkIGluIHRoZSBwbGFjZSB3 aGVyZSBYWEwgYXR0cmlidXRlIGp1c3QgZGlkIG5vdCBmaXQgc21hbGxlciBtZXNzYWdlIHNpemUg cGVlcnMgdG8gdGVsbCB0aGVtIHRoZW4gIkhleSBzb21ldGhpbmcgaXMgYnJva2VuIHdpdGggdGhp cyBOTFJJIiAtIHBscyBjaGVjay4gVGhlbiBpdCB3aWxsIGJlIHVwIHRvIGxvY2FsIHBvbGljeSB0 byBpbnN0YWxsIHN1Y2ggTkxSSSBvciBkcm9wIGl0Lg0KDQpUaHgsDQpSLg0KDQoNCk9uIFRodSwg RmViIDE0LCAyMDE5IGF0IDY6MjEgUE0gU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWls dG86c2hhcmVzQG5kemguY29tPj4gd3JvdGU6DQpCcnVubzoNCg0KVGhhbmsgeW91IGZvciBjYXJl ZnVsIGNvbnNpZGVyYXRpb25zIG9uIHRoZSB1c2UgY2FzZS4gICBJIHRoaW5rIHdlIGhhdmUgdHJh bnNsYXRpb24gaXNzdWVzIGJldHdlZW4gb3VyIOKAnEVuZ2xpc2jigJ0gbGFuZ3VhZ2UgYWdhaW4g c28gSSBoYXZlIHRyaWVkIHRvIGJlIHByZWNpc2UgaW4gdGhlIGRldGFpbGVkIGNvbW1lbnRzLiAg SeKAmXZlIHN1bW1hcml6ZWQgbXkgY29tbWVudHMgYXMgd2VsbCB0byBoZWxwIHVzIHRha2UgdGhl IG5leHQgc3RlcC4NCg0KU3VlDQoNClN1bW1hcnkNCi0tLS0NCkdvb2QgY2F0Y2ggb24gdGhlIDEw MDAgbGFyZ2UgQkdQIGNvbW11bml0aWVzIGJsb3dpbmcgdXAgdGhlIG1lc3NhZ2Ugc2l6ZSEgIFRo aXMgaXMgYSBjYXNlIHdoZXJlIGEgY29kZSBwYXRoIGNvdWxkIGdldCBjYXVnaHQgd2l0aCBwcm9n cmFtIGVycm9yLi4gIFRoZSBlcnJvciBoYW5kbGluZyAoc2VjdGlvbiA2LjEgaW4gUkZDNDI3MSBw ZXIgc2VjdGlvbiA1IGluIHRoZSBleHRlbmRlZCBzcGVjaWZpY2F0aW9uKSBJTUhPIGhhbmRsZXMg dGhlIGNhc2Ugd2hlcmUgdGhlIGF0dHJpYnV0ZSBpcyBsb25nZXIgdGhhbiB0aGUgbWVzc2FnZS4g ICBQbGVhc2UgbGV0IG1lIGtub3cgaWYgSeKAmXZlIG1pc3NlZCBzb21ldGhpbmcuDQoNCkFzIEkg dW5kZXJzdGFuZCBpdCwgIHlvdSBhcmUgYXNraW5nIHRoaXMgc3BlY2lmaWNhdGlvbiB0byBiZSBl eHBhbmRlZCB0byBhZGQgbm90ZXMgb24gcG9saWNpZXMgb24gd2hhdCBpbXBsZW1lbnRhdGlvbiBz aG91bGQgZG8gdG8gY29ycmVjdGx5IGNvbWJpbmUgUkZDNDI3MSBsZW5ndGggc2l6ZXMgd2l0aCBl eHRlbmRlZCBsZW5ndGggc2l6ZXMuICAgVGhlIGltcGxlbWVudGVycyBhbmQgb3BlcmF0aW9ucyBw ZW9wbGUgY29tbWVudGVkIGVhcmxpZXIgdGhhdCB0aGlzIHNob3VsZCBub3QgYmUgaW4gdGhlIHBy b3RvY29sIHNwZWNpZmljYXRpb24gb3RoZXIgdGhhbiBhcyBhIGJyaWVmIGZvb3Rub3RlLg0KDQpJ IGFncmVlIHRoZXJlIGlzIGEgbmVlZCBmb3Igc3VjaCBzdGFuZGFyZGl6YXRpb24gYXMgQkNQcyBm b3IgcGFydGljdWxhciB1c2UgY2FzZXMgKGxhcmdlIGNvbW11bml0aWVzLCBCRVNTIChFVlBOIG9y IGNlbnRyYWxpemVkIGNvbnRyb2xsZXIpLCBTUFJJTkcsIEJHUC1MUyBpbmZvcm1hdGlvbiAoc2Vl IERheWxpZ2h0IGNvbW1lbnRzIHllc3RlcmRheSksIFNELVdBTnMgKHJ0Z3dnKSwgYW5kIFNQUklO Ry4gICBJIHRoaW5rIHRoZSBjaGFpcnMgb2YgdGhlIFdHcyB1dGlsaXppbmcgc2hvdWxkIGNvbnNp ZGVyIGlmIHRoZXJlIGlzIG5lZWQgZm9yIHN0YW5kYXJkaXphdGlvbiBmb3IgYSBtaW5pbWFsIHNl dCBvZiBwb2xpY3kgZm9yIG1lc3NhZ2Ugc2l6ZXMgZm9yIHNwZWNpZmljIHVzZSBjYXNlcy4gICBJ IHdpbGwgYmUgZ2xhZCB0byBzZW5kIHJlcXVlc3QgdG8gdGhlc2UgV0cgb3IgdG8gaG9zdCBzb21l dGhpbmcgaW4gSURSIGlmIHRoZXJlIGlzIHBvbGljeSB0aGF0IGNhbiBiZSB1c2VkIGFjcm9zcyBh bGwgdXNlIGNhc2VzLg0KDQpUbyBwcm92aWRlIGEgc2xpZ2h0IGV4cGFuc2lvbiB0byBwb2ludCBw ZW9wbGUgaW4gdGhpcyBkaXJlY3Rpb24sIGhvdyBhYm91dCB0aGlzIGNoYW5nZSB0byBwYXJhZ3Jh cGggaW4gc2VjdGlvbiA0Og0KDQpPbGQvDQogICBBIEJHUCBhbm5vdW5jZW1lbnQgd2lsbCwgaW4g dGhlIG5vcm1hbCBjYXNlLCBwcm9wYWdhdGUgdGhyb3VnaG91dCB0aGUNCiAgIEJHUCBzcGVha2lu ZyBJbnRlcm5ldDsgYW5kIHRoZXJlIHdpbGwgdW5kb3VidGVkbHkgYmUgQkdQIHNwZWFrZXJzDQog ICB3aGljaCBkbyBub3QgaGF2ZSB0aGUgRXh0ZW5kZWQgTWVzc2FnZSBjYXBhYmlsaXR5LiAgVGhl cmVmb3JlLA0KICAgcHV0dGluZyBhbiBhdHRyaWJ1dGUgd2hpY2ggY2FuIG5vdCBiZSBkZWNvbXBv c2VkIHRvIDQwOTYgb2N0ZXRzIG9yDQogICBsZXNzIGluIGFuIEV4dGVuZGVkIE1lc3NhZ2UgaXMg YSBsaWtlbHkgcGF0aCB0byByb3V0aW5nIGZhaWx1cmUuDQovDQpOZXcvDQogICBBIEJHUCBhbm5v dW5jZW1lbnQgd2lsbCwgaW4gdGhlIG5vcm1hbCBjYXNlLCBwcm9wYWdhdGUgdGhyb3VnaG91dCB0 aGUNCiAgIEJHUCBzcGVha2luZyBJbnRlcm5ldDsgYW5kIHRoZXJlIHdpbGwgdW5kb3VidGVkbHkg YmUgQkdQIHNwZWFrZXJzDQogICB3aGljaCBkbyBub3QgaGF2ZSB0aGUgRXh0ZW5kZWQgTWVzc2Fn ZSBjYXBhYmlsaXR5LiAgVGhlcmVmb3JlLA0KICAgcHV0dGluZyBhbiBhdHRyaWJ1dGUgd2hpY2gg Y2Fubm90IGJlIGRlY29tcG9zZWQgdG8gNDA5NiBvY3RldHMgb3INCiAgIGxlc3MgaW4gYW4gRXh0 ZW5kZWQgTWVzc2FnZSBpcyBhIGxpa2VseSBwYXRoIHRvIHJvdXRpbmcgZmFpbHVyZS4NCiAgIE9u ZSBleGFtcGxlIG9mIGEgdmFsaWQgYXR0cmlidXRlIHdoaWNoIGNhbm5vdCBiZSBwcmVjaXNlbHkg ZGVjb21wb3NlZCBpZiBpdA0KICAgc2VudCBpbiBFeHRlbmRlZCBtZXNzYWdlIGlzIGEgbGFyZ2Ug Y29tbXVuaXR5IGF0dHJpYnV0ZSB3aXRoIDEwMDAgY29tbXVuaXRpZXMuDQogICAoMTIsMDAwIGJ5 dGVzKS4NCi8NCltQUyDigJMgaW4gQW1lcmljYW4gRW5nbGlzaCDigJxDYW4gbm904oCdIGlzIG5v cm1hbGx5IGNvbmNhdGVuYXRlZCDigJxjYW5ub3TigJ0uXQ0KDQoNCg0KDQpGcm9tOiBicnVuby4u ZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4gW21h aWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFu Z2UuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNCwgMjAxOSAzOjI5IEFNDQpUbzog U3VzYW4gSGFyZXMNCkNjOiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz47ICdKYWtv YiBIZWl0eiAoamhlaXR6KScNClN1YmplY3Q6IFJFOiBbSWRyXSBXRyBMYXN0IENhbGwgb24gRXh0 ZW5lZCBNZXNzYWdlIFN1cHBvcnQNCg0KU3VlLA0KDQpUaGFua3MgZm9yIHRoZSByZXBseS4gUGxl YXNlIHNlZSBpbmxpbmUgW0JydW5vXQ0KDQpGcm9tOiBTdXNhbiBIYXJlcyBbbWFpbHRvOnNoYXJl c0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPl0NClNlbnQ6IFdlZG5lc2RheSwgRmVi cnVhcnkgMTMsIDIwMTkgODowMyBQTQ0KVG86IERFQ1JBRU5FIEJydW5vIFRHSS9PTE4NCkNjOiBp ZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz47ICdKYWtvYiBIZWl0eiAoamhlaXR6KScN ClN1YmplY3Q6IFJFOiBbSWRyXSBXRyBMYXN0IENhbGwgb24gRXh0ZW5lZCBNZXNzYWdlIFN1cHBv cnQNCg0KQnJ1bm86DQoNCknigJlkIGxpa2UgdG8gYW5zd2VyIHNvbWUgb2YgdGhlIHF1ZXN0aW9u cyB5b3Ugc2VudCBSYW5keSBiYXNlZCBvbiBjb21tZW50cyAocHVibGljIGFuZCBwcml2YXRlKSB0 aGUgY2hhaXJzIGFuZCBJIGFzIHRoZSBzaGVwaGVyZCByZWNlaXZlZCBvbiB0aGlzIGRyYWZ0IGlu IG91ciBsYXN0IFdHIExDcy4NCg0KU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMgeW91IHF1ZXN0aW9u ZWQgd2VyZSBwdXQgaW4gdG8gYW5zd2VyIG90aGVyIHF1ZXN0aW9ucy4gICBUaGlzIGdldHMgaW50 byBhIGNhdGNoLTIy4oCmIHByb2JsZW0g4oCTIHdoZXJlIHlvdSBwdXQgY2hhbmdlcyBpbiBmb3Ig b25lIHBlcnNvbi90YWtlIG91dCB0aGUgY2hhbmdlcyBvdXQgZm9yIGFub3RoZXIuICBJbiBhY2Fk ZW1pYyBjaXJjbGVzIHRoaXMgaXMgY2FsbGVkIHRoZSByZXZpZXdlciAjMiBwcm9ibGVtIChyZXZp ZXdlciAxIGluc2lzdHMgY2hhbmdlcyBnbyBpbiwgcmV2aWV3ZXIgMiBpbnNpc3RzIGNoYW5nZXMg Z28gb3V0KSBkdXJpbmcgcHVibGljYXRpb24uICBUaGVyZWZvcmUsIEnigJltIEkgYW0gZ29pbmcg dG8gYW5zd2VyIG1vc3Qgb2YgeW91ciBxdWVzdGlvbnMgd2hlcmUgdGhpcyBpcyB0aGUgY2FzZS4N Cg0KSSBiZWxpZXZlIHRoYXQgUmFuZHkgaGFzIG5ldyB2ZXJzaW9uIHdpdGggdGhlIGNoYW5nZXMg SeKAmXZlIGluZGljYXRlZC4gIEnigJltIGhvcGluZyBoZeKAmWxsIGp1c3QgcG9zdCB0aGF0IHZl cnNpb24uICBBRkFJTEssIHdlIGRvIGhhdmUgMiBjb21wbGlhbnQgaW1wbGVtZW50YXRpb25zLg0K DQpTdWUNCg0KDQoNCjxzaGVwaGVyZCBoYXQgb24+DQpUaGlzIGRyYWZ04oCZcyB0ZWNobm9sb2d5 IHByb3ZpZGVzIGVmZmljaWVudCBwcm9jZXNzaW5nIGZvciBzb21lIGFwcGxpY2F0aW9uIGJ5IGFs bG93IGEgaHVnZSBCR1AgbWVzc2FnZSBzaXplLiAgV2hldGhlciDigJxjaHVua2luZ+KAnSBCR1Ag dG8gNDA5NiBieXRlIG1lc3NhZ2VzIG9yIHBhY2tpbmcgbGFyZ2UgYW1vdW50cyBvZiBkYXRhIGlu dG8gNjUsMDAwIGJ5dGUgbWVzc2FnZSBpcyBtb3JlIGVmZmVjdGl2ZSBmb3IgYSBwYXJ0aWN1bGFy IGFwcGxpY2F0aW9uIGlzIHNvbWV0aGluZyBvbmx5IGFuIGltcGxlbWVudGVyIG9mIGEgcGFydGlj dWxhciBCR1AgaW1wbGVtZW50YXRpb24gIGNhbiBkZWNpZGUuLiAgIFRoaXMgZHJhZnQgc2ltcGx5 IGdpdmVzIGZyZWVkb20gZm9yIGFwcGxpY2F0aW9ucyB0byBub3QgYmUgcmVzdHJpY3QgdG8gYW4g YXJ0aWZpY2lhbGx5IHNtYWxsIG1lc3NhZ2Ugc2l6ZS4gIFRoZSBtYXJrZXQgcGxhY2Ugd2lsbCBj aG9vc2Ugd2hldGhlciB0aGlzIHRlY2hub2xvZ3kgaXMgdXNlZCBvciBub3QuDQoNCkFzIEpha29i IHBvaW50ZWQgb3V0LCBjaGFuZ2luZyBhIGhpZ2hseSB0dW5lZCBCR1AgaW1wbGVtZW50YXRpb24g d2hpY2gg4oCcY2h1bmtz4oCdIEJHUCBkYXRhIGludG8gNDA5NiBieXRlIG1lc3NhZ2VzIG1heSBp bnZvbHZlIHN1YnN0YW50aWFsIHJld29yayBvZiB0aGUgaW1wbGVtZW50YXRpb24uDQoNCg0KKHNu aXApDQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNlc0Bp ZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpi cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPg0KU2VudDogMjkgSmFudWFyeSAyMDE5IDEzOjMzDQpU bzogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4N CkNjOiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWRy XSBXRyBMYXN0IENhbGwgb24gRXh0ZW5lZCBNZXNzYWdlIFN1cHBvcnQNCg0KSGkgV0csDQoNCj5Q bGVhc2UgZmluZCBiZWxvdyBzb21lIGNvbW1lbnRzLg0KPkFzIG9mIHRvZGF5LCBJIGRvbuKAmXQg YmVsaWV2ZSB0aGlzIHNwZWNpZmljYXRpb24gaXMgcmVhZHkgdG8gYmUgcHJvZ3Jlc3NlZCB0byBJ RVNHL1JGQywgZXNwZWNpYWxseSBmb3IgYSBkb2N1bWVudCA+dXBkYXRpbmcgUkZDIDQyNzEgKGNv cmUgQkdQIHNwZWMpLg0KDQo+IFRoZSBXRyBjaGFpcnMgaW50ZW5kIHRvIGZvcndhcmQgdGhpcyBk cmFmdCB0byB0aGUgSUVTRyB3aXRoIHRoZSBjdXJyZW50IGxldmVsIG9mIGltcGxlbWVudGF0aW9u Lg0KDQo+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHIt YmdwLWV4dGVuZGVkLT5pbXBsZW1lbnRhdGlvbnM8aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv aWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLSUzZWltcGxlbWVudGF0aW9ucz4g c2F5cyA6IDVhDQoNCkRvZXMgbm90IHNlbmQgRXh0ZW5kZWQgTWVzc2FnZSBjYXBhYmlsaXR5DQoN Clllcw0KDQpZZXMNCg0KWWVzDQoNCg0KPkkgbWF5IGJlIG1pc3VuZGVyc3RhbmRpbmcgdGhlIGlt cGxlbWVudGF0aW9uIHJlcG9ydCwgYnV0IG15IHJlYWRpbmcgb2YgdGhlIGFib3ZlIGlzIHRoYXQg bm9uZSBvZiB0aGUgcmVwb3J0ZWQgPmltcGxlbWVudGF0aW9ucyBzZW5kcyB0aGUgY2FwYWJpbGl0 eSBoZW5jZSBubyBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyBkcmFmdC1pZXRmLWlkci1iZ3AtZXh0 ZW5kZWQtbWVzc2FnZXMuLg0KPkhlcmUgdGhpcyBkb2N1bWVudCBpcyB1cGRhdGluZyBSRkMgNDI3 MSwgc28gaXQgaXMgbm90IGEgbWlub3IgZXh0ZW5zaW9uIGZvciBhIG5pY2hlIHVzZSBjYXNlLiBT byBJIGRvbuKAmXQgc2VlIHRoZSA+YXJndW1lbnRzIGZvciBub3QgcmVxdWlyaW5nIHRoZSBJRFLi gJlzIHVzdWFsIHR3byBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4NCg0KPkluIG91ciBt YWlsIHRocmVhZCwgd2UgZGlzY292ZXJlZCB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiByZXBvcnQg c2hvdWxkIGhhdmUgaW5kaWNhdGUNCj5mdWxsIHN1cHBvcnQuICAgSeKAmW0gd2FpdGluZyBmb3Ig T2xpdmllciB0byB1cGRhdGUgYmFzZWQgb24gdGhlIGxhc3QgcG9pbnQsIGJ1dCBteSB1bmRlcnN0 YW5kaW5nIGlzIHRoYXQNCkFsbCBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBmdWxsIHN1cHBvcnQuDQoN CltCcnVub10gb2ssIHNvbHZlZA0KPi0tLS0NCj7CpyAxDQo+4oCcIEFzIEJHUCBpcyBleHRlbmRl ZCB0byBzdXBwb3J0IG5ld2VyIEFGSS9TQUZJcyBhbmQNCj4gICBuZXdlciBjYXBhYmlsaXRpZXMg KGUuZy4sIFtJLUQuaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbDxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTI3I3JlZi1JLUQu aWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbD5dKSwgdGhlcmUgaXMNCj4gICBhIG5lZWQgdG8gZXh0 ZW5kIHRoZSBtYXhpbXVtIG1lc3NhZ2Ugc2l6ZSBiZXlvbmQgNDA5NiBvY3RldHMuICDigJwNCj4N Cj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRl ZC1tZXNzYWdlcy0yNyNzZWN0aW9uLTENCg0KDQo+W0ktRC5pZXRmLXNpZHItYmdwc2VjLXByb3Rv Y29sPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5k ZWQtbWVzc2FnZXMtMjcjcmVmLUktRC5pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sPiBpcyBub3cg UkZDIDgyMDUgKHRoYW5rcyBmb3IgdXBkYXRpbmcgdGhlIHJlZmVyZW5jZSkuIEl0IGhhcyByZW1v dmVkIHRoZSBub3JtYXRpdmUvYW55ID5yZWZlcmVuY2UgdG8gZHJhZnQtaWV0Zi1pZHItYmdwLWV4 dGVuZGVkLW1lc3NhZ2VzLiBTbyBwcmVzdW1hYmx5IEJHUCBTZWMgZG9lcyBub3QgbmVlZCBkcmFm dC1pZXRmLWlkci1iZ3AtPmV4dGVuZGVkLW1lc3NhZ2VzLiBDYW4gd2UgaGF2ZSBhbiB1cGRhdGUg b24gdGhpcz8gIENhbiB0aGUgaW50cm9kdWN0aW9uIG9mIGRyYWZ0LWlldGYtaWRyLWJncC1leHRl bmRlZC1tZXNzYWdlcyA+YmUgdXBkYXRlZCB0byBpbnRyb2R1Y2Ugb24gdGhlIHJlYWwgcmVhc29u cy9uZWVkcz8NCg0KU0lEUiBnYXZlIHVwIHdhaXRpbmcgb24gSURS4oCZcyB3b3JrIGFuZCB0b29r IGEgcmVkdWNlZCBzaXplIG9mIGVuY3J5cHRpb24uICAgVGhlIHNlY3VyaXR5IHBlb3BsZSB3ZXJl IHZlcnkgc2FkIGFib3V0IHRoZSByZWR1Y3Rpb24uICBIb3cgaXMgdGhpcyB3b3JraW5nIGluIHBy YWN0aWNlPyBXRyBzaWRyb3BzIGNhbiBhbnN3ZXIgdGhpcyBxdWVzdGlvbi4NCg0KVGhlIHJlYWwg cHJvYmxlbSBpcyB0aGVyZSBpcyBmaW5pdGUgbWVzc2FnZSBzcGFjZS4NCltCcnVub10gU28gdG9v IGJhZCB0aGUgZHJhZnQgZG9lcyBub3Qgc29sdmUgdGhlIHJlYWwgcHJvYmxlbSA7LSkgKGFzIG1l c3NhZ2Ugc3BhY2UgaXMgc3RpbGwgbGltaXRlZCkNCg0KW1N1ZV06IFRoZSBtZXNzYWdlIGlzIHN0 aWxsIGZpbml0ZSAoc21pbGUpLCAgYnV0IEkgaG9wZSA2NSw2MzUgKHNtaWxlKSBpcyBwcm9iYWJs eSBlbm91Z2ggZm9yIDEwIHllYXJzLg0KDQpUaGVyZSBhcmUgdHdvIHdheXMgdG8gc2VuZCBsb3Rz IG9mIEJHUCByb3V0ZXMgYW5kL29yIGF0dHJpYnV0ZXMg4oCTIHRvIOKAnGNodW5r4oCdIHRoZXNl IGludG8gc21hbGwgbWVzc2FnZSBzaXplcyBvciBwbGFjZSB0aGVzZSBpbnRvIGEgbGFyZ2UgbWVz c2FnZS4gICAgU29tZSBhcHBsaWNhdGlvbnMgbWF5IGFsd2F5cyB3YW50IHRvIOKAnGNodW5r4oCd IGludG8gbWVzc2FnZSBzaXplcyBzbWFsbGVyIHRoYW4gNDA5Ni4gICBTb21lIGFwcGxpY2F0aW9u IG1ha2Ugd29yayBtb3JlIGVmZmljaWVudGx5IHV0aWxpemluZyBsYXJnZSBtZXNzYWdlIHNpemUu ICBBcyB0aGUgcG90ZW50aWFsIG51bWJlciBvZiBOTFJJIGFuZCBCR1AgYXR0cmlidXRlcyBncm93 cywgbmV3IGFwcGxpY2F0aW9ucyBtYXkgY29uc2lkZXIgbGFyZ2UgbWVzc2FnZSBzaXplcyB0byBh IG1vcmUgcmVhc29uYWJsZSB3YXkgdG8gZXhjaGFuZ2UgYW1vdW50cyBvZiBCR1AgZGF0YS4NCg0K VGhlIGRlY2lzaW9uIG9uIGhvdyB0byBzZW5kIEJHUCBtZXNzYWdlcyBvdmVyIHRoZSB3aXJlIGlz IGEgcGVlci1ieS1wZWVyIGRlY2lzaW9uIGluIGEgbmV0d29yay4gICBFYWNoIEJHUCBwZWVyIGlz IGluIGNoYXJnZSBvZiByZWZvcm1hdHRpbmcgdGhlIEJHUCBtZXNzYWdlIGl0IHNlbmRzIHRvIHRo ZSByZW1vdGUgQkdQIHBlZXIuICAgVGhlIEJHUCBjYXBhYmlsaXRpZXMgaW4gdGhpcyBkcmFmdCBy ZXByZXNlbnQgYW4gYWdyZWVtZW50IGJldHdlZW4gdHdvIEJHUCBwZWVycy4gIFRoZXNlIGFyZSBm YWN0cyBvZiBiYXNpYyBCR1AgaW1wbGVtZW50YXRpb25zDQpbQnJ1bm9dIExldOKAmXMgdGFrZSB0 aGUgZXhhbXBsZSBvZiBhIEJHUCBSb3V0ZSBSZWZsZWN0b3IgaGF2aW5nIGEgbWl4ZWQgb2YgY2xp ZW50cywgc29tZSBzdXBwb3J0aW5nIEV4dGVuZCBNZXNzYWdlIChFTSkgYW5kIHNvbWUgbm90Lg0K RnJvbSBhbiBFTSBjbGllbnQsIGl0IHJlY2VpdmVzIGEgQkdQIHVwZGF0ZSBjb250YWluaW5nIG9u ZSAoc2luZ2xlKSBOTFJJIHdpdGggYW4gVG90YWwgUGF0aCBBdHRyaWJ1dGUgTGVuZ3RoIGJpZ2dl ciB0aGFuICA0MDkwIGJ5dGUgKGUuZy4gaGF2aW5nIDEwMDAgbGFyZ2UgY29tbXVuaXRpZXNzKQ0K Q2FuIHlvdSBleHBsYWluIG1lIGhvdyBpdCBiZWhhdmVzIHRvIHNlbmQgdGhpcyBOTFJJIHRvIGFu IElCR1AgcGVlciBub3Qgc3VwcG9ydGluZyBFTT8NCltTdWVdOiAgR2xhZGx54oCmDQpBIEJHUCBy b3V0ZSByZWZsZWN0b3IgKFJSLUEpIGlzIHBlZXJpbmcgd2l0aCBlYWNoIG9mIGl0cyBCR1AgY2xp ZW50cy4gICBJdCBhZ3JlZXMgd2l0aCBlYWNoIG9mIGl0cyBjbGllbnRzIChCR1AtQzEsIEJHUEMy LCBCR1BDMykgd2hldGhlciB0aGUgQkdQIEV4dGVuZGVkIG1lc3NhZ2VzIGlzIGFjY2VwdGVkIG9y IG5vdCAoYmFzZWQgb24gY2FwYWJpbGl0eSBhbm5vdW5jZW1lbnQpLg0KTGV0IHVzIGFzc3VtZSB0 aGF0IEJHUC1DMSBkb2VzIG5vdCBzdXBwb3J0IGV4dGVuZGVkIG1lc3NhZ2VzLCBhbmQgIEJHUC1D MiBhbmQgQkdQLUMzIGRvIHN1cHBvcnQgZXh0ZW5kZWQgbWVzc2FnZXMuDQoNCklmIHRoZSBwb2xp Y3kgaW4gUlIgYWNjZXB0cyBhIHRvdGFsIHBhdGggbGVuZ3RoIG9mIDEwMDAgbGFyZ2UgY29tbXVu aXRpZXMgd2l0aCAgYSBzaW5nbGUgTkxSSSwgaXQgbWF5IHNlbmQgdGhlIEJHUCBhdHRyaWJ1dGUg dmlhIGV4dGVuZGVkIGNvbW11bml0aWVzIHRvIEJHUC1DMiBhbmQgQkdQLUMyLg0KVGhlIHBvbGlj eSBpbiB0aGUgUlIgbXVzdCBzcGVjaWZ5IHdoZXRoZXI6DQoNCmEpICAgICAgdGhlIOKAnHRvbyBs b25n4oCdIGF0dHJpYnV0ZSBwYXRoIGxlbmd0aCBtdXN0IGJlIGRyb3BwZWQsIG9yDQoNCmIpICAg ICAgdGhlIEJHUCBhdHRyaWJ1dGUgcGF0aCBjYW4gYmUgdHJ1bmNhdGVkLg0KDQpUaGlzIGlzIGEg cG9saWN5IGlzc3VlIHdpdGhpbiB0aGUgQkdQIHBlZXIgYW5kIHRoZSBuZXR3b3JrIG9wZXJhdGlv biBzdGFmZi4gIEVhY2ggb3BlcmF0b3IgbWF5IGNob29zZSB0byB3cml0ZSB0aGlzIHBvbGljeSBk aWZmZXJlbnRseS4NCg0KUmF0aGVyIHRoYW4gc3BlY2lmeSB0aGUgbnVtZXJvdXMgY2FzZXMgaW4g dGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24sICB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbnMgKHBy aXZhdGUgYW5kIHB1YmxpYykgYXNrZWQgdXMgdG8gdHJpbSB0aGlzIGluZm9ybWF0aW9uIG91dCBv ZiB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbi4NCg0KSWYgeW91IGJlbGlldmUgdGhpcyBpcyB3 b3J0aHkgb2YgYSB1c2UgY2FzZSBkcmFmdCBmb3IgdGhlIHNha2Ugb2YgQkVTUywgTFNWUiwgU1BS SU5HLCBHcm93IGFuZCBvdGhlcnMsIEkgd2lsbCBoYXBwaWx5IFdHIGNoYWlyIHNwb25zb3IgYSBk cmFmdCB0aGF0IGNhbiBiZSByZXZpZXdlZCBieSBhbGwgdGhlc2UgV0dzLg0KDQoNCuKAkyBzbyBJ IGRvIG5vdCBiZWxpZXZlIGFkZGluZyB0aGVzZSBmYWN0cyB0byBSYW5keeKAmXMgZHJhZnQgaXMg dXNlZnVsLiAgSW4gZmFjdCwgaW4gdGhlIHByZXZpb3VzIHJvdW5kcyBvZiByZXZpZXcgdGhpcyBw b2ludCB3YXMgbWFkZS4NCg0KWW91ciBxdWVzdGlvbiAoYW5kIHBlcmhhcHMgSmFrb2LigJlzKSBp cyB3aGV0aGVyIHdlIGhhdmUgcmVhY2hlZCBhIHRpbWUvcGxhY2Ugd2hlcmUgdGhlIOKAnGNodW5r aW5n4oCdIGFwcHJvYWNoIHdpbGwgZmFpbCBvbiBhIHBlZXItYnktcGVlciBiYXNpcz8gICBUaGlz IGRyYWZ0IGRvZXMgbm90IG1ha2UgdGhpcyBzdGF0ZW1lbnQuDQoNClRoZSBwb2ludCBvZiB0aGlz IGRyYWZ0IGlzIHRvIGVuYWJsZSBtb3JlIGVmZmljaWVudCBwcm9jZXNzaW5nIGJ5IGluY3JlYXNp bmcgdGhlIG1lc3NhZ2Ugc2l6ZSBmb3IgQkdQIHBlZXJzIHRoYXQgc2VuZCBhIGxvdCBvZiBkYXRh IChlLmcuIEJHUC1MUykgLiAgIFRoZSBjaG9pY2UgdG8g4oCcY2h1bmvigJ0gb3Igc3RyZWFtIGlu IGxhcmdlIEJHUCBtZXNzYWdlIGlzIGFuIGltcGxlbWVudGF0aW9uIGNob2ljZSBmb3IgYSBwYXJ0 aWN1bGFyIEJHUCBhcHBsaWNhdGlvbi4NCg0KLS0tLQ0Kwqc0DQoNCsKnMyBzYXlzIOKAnEEgcGVl ciB3aGljaCBkb2VzIG5vdCBhZHZlcnRpc2UgdGhpcyBjYXBhYmlsaXR5IE1VU1QgTk9UIHNlbmQg QkdQDQogICBFeHRlbmRlZCBNZXNzYWdlcywgYW5kIEJHUCBFeHRlbmRlZCBNZXNzYWdlcyBNVVNU IE5PVCBiZSBzZW50IHRvIGl0LuKAnQ0KW0kgYmVsaWV2ZSByYW5keSBhY2NlcHRlZCB0aGlzIGNo YW5nZSB3aXRoIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiB2ZXJzaW9uIDQgW3VwY29taW5nIGJlbG93 XV0vLg0KDQotLS0tLS0tLS0tLS0tLQ0KDQpGaW5lLiBUZXh0IGluIMKnNCBzaG91bGQgcHJvYmFi bHkgYmUgYWxpZ25lZCB3aXRoIHRoZSBhYm92ZSAuLmUuZy4NCg0KT0xEOiBBIEJHUCBzcGVha2Vy DQogICBNQVkgc2VuZCBFeHRlbmRlZCBNZXNzYWdlcyB0byBpdHMgcGVlciBvbmx5IGlmIGl0IGhh cyByZWNlaXZlZCB0aGUNCiAgIEV4dGVuZGVkIE1lc3NhZ2UgQ2FwYWJpbGl0eSBmcm9tIHRoYXQg cGVlci4NCg0KTkVXOg0KQSBCR1Agc3BlYWtlcg0KICAgTUFZIHNlbmQgRXh0ZW5kZWQgTWVzc2Fn ZXMgdG8gaXRzIHBlZXIgb25seSBpZiBpdCBoYXMgc2VudCBhbmQgcmVjZWl2ZWQgdGhlDQogICBF eHRlbmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgdG8gYW5kIGZyb20gdGhhdCBwZWVyLg0KDQoNCi0t LS0NCg0KPuKAnCAgIEFwcGxpY2F0aW9ucyBnZW5lcmF0aW5nIGluZm9ybWF0aW9uIHdoaWNoIG1p Z2h0IGJlIGVuY2Fwc3VsYXRlZA0KPiAgIHdpdGhpbiBCR1AgbWVzc2FnZXMgTVVTVCBsaW1pdCB0 aGUgc2l6ZSBvZiB0aGVpciBwYXlsb2FkIHRvIHRha2UgdGhlDQo+ICAgbWF4aW11bSBtZXNzYWdl IHNpemUgaW50byBhY2NvdW50LuKAnQ0KPg0KPkkgZG9u4oCZdCBzZWUgd2hhdCBuZXcgYmVoYXZp b3IgaXMgYmVlbiBkZWZpbmVkIGhlcmUuIElmIHRoZXJlIGlzIG5vbmUsIEkgd291bGQgc3VnZ2Vz dCB0byByZW1vdmUgdGhpcyBzZW50ZW5jZQ0KDQpCcnVubyDigJMgcGVvcGxlIGFza2VkIHRvIHB1 dCB0aGlzIHRleHQgaW4gYXMgYW4gb3BlcmF0aW9uYWwgd2FybmluZy4gIEF0IHRoaXMgcG9pbnQs IEnigJltIGdvaW5nIHRvIHNheSB1bmxlc3MgdGhlcmUgaXMgaGFybSBpdCBzaG91bGQgcmVtYWlu Lg0KW0JydW5vXSBPSy4NCg0KLS0tLQ0KPiAgIEEgQkdQIGFubm91bmNlbWVudCB3aWxsLCBpbiB0 aGUgbm9ybWFsIGNhc2UsIHByb3BhZ2F0ZSB0aHJvdWdob3V0IHRoZQ0KPiAgIEJHUCBzcGVha2lu ZyBJbnRlcm5ldDsgYW5kIHRoZXJlIHdpbGwgdW5kb3VidGVkbHkgYmUgQkdQIHNwZWFrZXJzDQo+ ICAgd2hpY2ggZG8gbm90IGhhdmUgdGhlIEV4dGVuZGVkIE1lc3NhZ2UgY2FwYWJpbGl0eS4gIFRo ZXJlZm9yZSwNCj4gICBwdXR0aW5nIGFuIGF0dHJpYnV0ZSB3aGljaCBjYW4gbm90IGJlIGRlY29t cG9zZWQgdG8gNDA5NiBvY3RldHMgb3INCj4gICBsZXNzIGluIGFuIEV4dGVuZGVkIE1lc3NhZ2Ug aXMgYSBsaWtlbHkgcGF0aCB0byByb3V0aW5nIGZhaWx1cmUuDQo+DQo+VGhlIGlzc3VlIGlzIG5v dCBzcGVjaWZpYyB0byBhdHRyaWJ1dGVzIGJpZ2dlciB0aGFuIDQwOTYgb2N0ZXRzLCBidXQgdG8g QkdQIG1lc3NhZ2Ugd2hvc2UgbGVuZ3RoIGlzIGJpZ2dlciB0aGFuID40MDk2LCBpcnJlc3BlY3Rp dmUgb2YgdGhlIHNpemUgb2YgZWFjaCBhdHRyaWJ1dGUuDQo+UGxlYXNlIGVsYWJvcmF0ZSBvbiB3 aGF0IHlvdSBtZWFuIGJ5DQo+DQo+4oCcYW4gYXR0cmlidXRlIHdoaWNoIGNhbm5vdCBiZSBkZWNv bXBvc2VkIHRvIDQwOTYgb2N0ZXRz4oCdDQoNCkFuIGF0dHJpYnV0ZSB3aGljaCBjYW5ub3QgYmUg ZGVjb21wb3NlZCB0byA0MDk2IGlzIGFuIGF0dHJpYnV0ZSB3aXRoIGxlbmd0aCA2MDAwIGluc2lk ZSBvZiBhIEJHUCBtZXNzYWdlIHdoaWNoIHJlcXVpcmVzIHRoZSBlbnRpcmUgYXR0cmlidXRlIHRv IGJlIGluY2x1ZGVkLiAgIE5vIHN1Y2ggYXR0cmlidXRlIGV4aXN0cyB0b2RheS4gICBJZiBhIHNt YWxsIEJHUCBwZWVycyBjcmVhdGUgYSDigJxraWxsZXIgYXBwbGljYXRpb27igJ0gdGhhdCB1c2Vz IGEgNjAwMCBieXRlIGF0dHJpYnV0ZSwgdGhlIHJlc3Qgb2YgdGhlIEludGVybmV0IGRvZXMgbm90 IGhhdmUgdG8gdXNlIGl0LiAgIEhvd2V2ZXIsIHRoZSBwZXJzb24gZGVmaW5pbmcgdGhhdCBhdHRy aWJ1dGUgbXVzdCBjYXJlZnVsbHkgc3BlY2lmeSBpdCBtdXN0IGdvIHdpdGggRXh0ZW5kZWQgQkdQ IG1lc3NhZ2VzLg0KDQoNCltCcnVub10gSSBkb27igJl0IHRoaW5rIHRoYXQgSSBhZ3JlZSB3aXRo IHRoaXMuIEUuZy4gSSBkb27igJl0IHNlZSB3aGVyZSBSRkNzIDE5OTcgb3IgODA5MiBbKGxhcmdl KWNvbW11bml0eV0gbGltaXRzIHRoZSBzaXplIG9mIHRoZWlyIGF0dHJpYnV0ZS4gSGVuY2UgSSBk b27igJl0IHNlZSB3aHkgeW91IGNvdWxkIG5vdCBoYXZlLCB0b2RheSAod2l0aCBFeHRlbmRlZCBN ZXNzYWdlIHN1cHBvcnQpICwgYXR0cmlidXRlcyBsYXJnZXIgdGhhbiA0MDk2IG9jdGV0cy4gTW9z dCBwcm9iYWJseSBzYW1lIHN0YXR1cyBmb3IgdGhlIEJHUFNlYyBhdHRyaWJ1dGUgc2luY2UgdGhl eSB3YW50ZWQgZm9yIG1vcmUgc3BhY2UuDQpbU3VlXTogWW91IG1ha2UgYSBnb29kIHBvaW50IGFi b3V0IHRoZSBwb3NzaWJpbGl0eSBvZiBsYXJnZSBjb21tdW5pdGllcyBub3QgbGltaXRpbmcgdGhl IHNpemUuICBJdCBpcyB3b3J0aHkgb2YgYSBjaGFuZ2UgdG8gYm90aCB0aGUgbGFyZ2UgY29tbXVu aXRpZXMgYW5kIGEgZm9vdG5vdGUgaW4gUmFuZHnigJlzIHNwZWNpZmljYXRpb24uICBIb3cgYWJv dXQgdGhlIGFkZGl0aW9uIG9mIGEgc2luZ2xlIHNlbnRlbmNlIHRvIHBvaW50IHBlb3BsZSBpbiB0 aGUgcmlnaHQgZGlyZWN0aW9uLg0KDQpPbGQvDQogICBBIEJHUCBhbm5vdW5jZW1lbnQgd2lsbCwg aW4gdGhlIG5vcm1hbCBjYXNlLCBwcm9wYWdhdGUgdGhyb3VnaG91dCB0aGUNCiAgIEJHUCBzcGVh a2luZyBJbnRlcm5ldDsgYW5kIHRoZXJlIHdpbGwgdW5kb3VidGVkbHkgYmUgQkdQIHNwZWFrZXJz DQogICB3aGljaCBkbyBub3QgaGF2ZSB0aGUgRXh0ZW5kZWQgTWVzc2FnZSBjYXBhYmlsaXR5LiAg VGhlcmVmb3JlLA0KICAgcHV0dGluZyBhbiBhdHRyaWJ1dGUgd2hpY2ggY2FuIG5vdCBiZSBkZWNv bXBvc2VkIHRvIDQwOTYgb2N0ZXRzIG9yDQogICBsZXNzIGluIGFuIEV4dGVuZGVkIE1lc3NhZ2Ug aXMgYSBsaWtlbHkgcGF0aCB0byByb3V0aW5nIGZhaWx1cmUuDQovDQpOZXcvDQogICBBIEJHUCBh bm5vdW5jZW1lbnQgd2lsbCwgaW4gdGhlIG5vcm1hbCBjYXNlLCBwcm9wYWdhdGUgdGhyb3VnaG91 dCB0aGUNCiAgIEJHUCBzcGVha2luZyBJbnRlcm5ldDsgYW5kIHRoZXJlIHdpbGwgdW5kb3VidGVk bHkgYmUgQkdQIHNwZWFrZXJzDQogICB3aGljaCBkbyBub3QgaGF2ZSB0aGUgRXh0ZW5kZWQgTWVz c2FnZSBjYXBhYmlsaXR5LiAgVGhlcmVmb3JlLA0KICAgcHV0dGluZyBhbiBhdHRyaWJ1dGUgd2hp Y2ggY2Fubm90IGJlIGRlY29tcG9zZWQgdG8gNDA5NiBvY3RldHMgb3INCiAgIGxlc3MgaW4gYW4g RXh0ZW5kZWQgTWVzc2FnZSBpcyBhIGxpa2VseSBwYXRoIHRvIHJvdXRpbmcgZmFpbHVyZS4NCiAg IE9uZSBleGFtcGxlIG9mIGEgdmFsaWQgYXR0cmlidXRlIHdoaWNoIGNhbm5vdCBiZSBwcmVjaXNl bHkgZGVjb21wb3NlZCBpZiBpdA0KICAgc2VudCBpbiBFeHRlbmRlZCBtZXNzYWdlIGlzIGEgbGFy Z2UgY29tbXVuaXR5IGF0dHJpYnV0ZSB3aXRoIDEwMDAgY29tbXVuaXRpZXMuDQogICAoMTIsMDAw IGJ5dGVzKS4NCi8NCg0KDQpUaGlzIHRleHQgd2FzIGFkZGVkIGR1cmluZyBhbiBlYXJsaWVyIGRp c2N1c3Npb24gd2hlcmUgdGhlIGVycm9yIGNhc2VzIG9mIGEgbGFyZ2UgQkdQIGF0dHJpYnV0ZSB3 YXMgZ2l2ZW4uICBUaGUgb3JpZ2luYXRvciBvZiB0aGUgY29tbW9uIGNvdWxkIG5vdCBwcm92aWRl IHRoZSBleGFjdCBkZXNjcmlwdGlvbiwgYnV0IHdlIGFncmVlZCB0byBwdXQgdGhpcyAg4oCcd2Fy bmluZyBsYWJlbOKAnSBpbnRvIHRoZSBkcmFmdC4gICBUaGlzIGlzIG9uZSBvZiB0aGUgY2FzZXMg d2hlcmUgYWRkaW5nL3JlbW92aW5nIHRleHQgZ2V0cyB0byBiZSBwcm9ibGVtYXRpYy4NCg0KPi0t LQ0KPuKAnCAgIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgQkdQIHByb3RvY29sIGRldmVsb3BlcnMg YW5kIGltcGxlbWVudGVycyBhcmUNCj4gICBjb25zZXJ2YXRpdmUgaW4gdGhlaXIgYXBwbGljYXRp b24gYW5kIHVzZSBvZiBFeHRlbmRlZCBNZXNzYWdlcy7igJ0NCj4NCj5XaGF0IGRvZXMgdGhpcyBt ZWFuIGV4YWN0bHk/IFRoYXQgdGhleSBkb27igJl0IHVzZSB0aGlzIGV4dGVuc2lvbj8NCj5UaGF0 IHRoZXkgZG9u4oCZdCB1c2UgdGhpcyBleHRlbnNpb24gdW5sZXNzIFhYX1RPIEJFIFNQRUNJRklF RF9YWD8NCg0KVGhpcyB3YXJuaW5nIHdhcyB0ZXh0IHRoYXQgb3RoZXIgcGFydGljaXBhbnRzIGFz a2VkIHRvIGJlIGFkZGVkLg0KDQpJdCBpcyBhIGNvbW1vbiBzZW5zZSB3YXJuaW5nLiAgRXh0ZW5k ZWQgbWVzc2FnZXMgYXJlIGVuYWJsZWQgb24gYSBwZWVyIGJ5IHBlZXIgYmFzaXMgYXMgYWxsIEJH UCBjYXBhYmlsaXRpZXMgYXJlLiAgSWYgeW91IHJ1biBpbnRvIGEgUGVlciB0aGF0IGRvZXMgbm90 IHN1cHBvcnQgdGhlIGxhcmdlciBzaXplcywgdGhlIEJHUCBtZXNzYWdlcyB3aWxsIG5lZWQgdG8g YmUgcmVmb3JtYXR0ZWQgdG8gdGhlIHNtYWxsZXIgc2l6ZS4gICBSdW5uaW5nIGltbWVkaWF0ZWx5 IHRvIHRoZSBFeHRlbmRlZCBtZXNzYWdlcyBhcyB0aGUgZGVmYXVsdCBjb3VsZCBjYXVzZSBwcm9i bGVtcy4uDQoNCltCcnVub10gSSB0aGluayB0aGF0IHRoZSBzZW50ZW5jZSBjb3VsZCBiZSBlbGFi b3JhdGVkLiBJbmRpY2F0aW5nIHRoZSBwcm9ibGVtLCBob3cgdGhlIHNwZWNpZmljYXRpb24gcGFy dGlhbGx5IGFkZHJlc3MgaXQsIGFuZCBob3cgdGhlIHNwZWNpZmljYXRpb24gZG9lcyBub3QgYWRk cmVzcyBpdC4NCkluIOKAnFJ1bm5pbmcgaW1tZWRpYXRlbHkgdG8gRXh0ZW5kZWQgTWVzc2FnZeKA nSBJIGRvbuKAmXQgdGhpbmsgdGhleSB0aGF0IHRoZSBpc3N1ZSBpcyB3aXRoIOKAnGltbWVkaWF0 ZWx54oCdLiBXaGVuZXZlciB5b3Ugc3RhcnQgdGhlIHRyYW5zaXRpb24sIHlvdXIgbGlrZWx5IHRv IHJ1biBpbnRvIHByb2JsZW1zLg0KDQoNCltTdWVdOiBJTUhPIHNwZWNpZmljYXRpb24gc3BlY2lm aWVzIGhvdyB0byBlbmNvZGUgdGhlIGJ5dGVzIG9uIHRoZSB3aXJlIGFuZCB0aGUgYXBwcm9wcmlh dGUgZXJyb3IgaGFuZGxpbmcgb2YgdGhlIG1lc3NhZ2VzLiAgIElmIEkgaGF2ZSBtaXNzZWQgc29t ZXRoaW5nIGluIHRoaXMgY2FzZSwgcGxlYXNlIGxldCBtZSBrbm93Lg0KDQpUaGUgc3BlY2lmaWNh dGlvbiBkb2VzIG5vdCBzcGVjaWZ5IHRoZSBuZWNlc3NhcnkgcG9saWNpZXMgaW1wbGVtZW50YXRp b24gc2hvdWxkIGhhdmUgaW4gb3JkZXIgdG8gZGVjaWRlIHdoYXQgdG8gZG8gaW4gdGhlIGNhc2Ug b2YgbWl4ZWQgbmV0d29yay4gICBUaGUgY2xlYXIgaW5kaWNhdGlvbiB3YXMgdGhpcyB0eXBlIHdh cyBub3QgYXBwcm9wcmlhdGUgZm9yIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uLg0KDQpFYXJs aWVyIGRpc2N1c3Npb24gaW5kaWNhdGVkIHRoYXQgdGhlc2UgaXMgcG9saWN5IGFuZCBtZWNoYW5p c20gc3BlY2lmaWMuICBJdCBpcyB3b3J0aHkgb2Yg4oCcdXNlIGNhc2Ugb3IgYXBwbGljYXRpb24g bm90ZXPigJ0gd3JpdHRlbiBmb3Igc3BlY2lmaWMgYXBwbGljYXRpb25zIChCRVNTLCBTUFJJTkcs IEdST1cpLCBidXQgbm90IGluIHRoZSBzcGVjaWZpY2F0aW9uLiAgQWdhaW4sIGlmIGl0IGlzIHNp Z25pZmljYW50IGVub3VnaCBjb25jZXJuIGZvciBvcGVyYXRvcnMgYW5kIGltcGxlbWVudGVycyDi gJMgaXQgd291bGQgYmUgd29ydGh5IHRvIGhhdmUgY29tYmluZWQgdXNlIGNhc2UgZG9jdW1lbnQg YmVzaWRlcyB0aGlzIHBvaW50LiAgICBJ4oCZbSBoYXBweSB0byBzcG9uc29yIGNyb3NzLWFyZWEg d29yayBvbiB0aGlzIHVzZSBjYXNlLg0KDQotLS0NCiAgRnV0dXJlIHByb3RvY29sIHNwZWNpZmlj YXRpb25zIHdpbGwgbmVlZCB0byBkZXNjcmliZSBob3cgdG8gaGFuZGxlDQogICBwZWVycyB3aGlj aCBjYW4gb25seSBhY2NvbW1vZGF0ZSA0MDk2IG9jdGV0IG1lc3NhZ2VzLg0KDQo+V2h5IGlzIHRo aXMgbGltaXRlZCB0byBmdXR1cmUgc3BlY2lmaWNhdGlvbnM/IEEgcHJpb3JpLCB1c2luZyBleGlz dGluZyBCR1AgbWVjaGFuaXNtIChBRkkvU0FGSSwgYXR0cmlidXRlcywgKiA+Y29tbXVuaXRpZXMp IG9uZSBjb3VsZCBleGNlZWQgdGhlIHNpemUgb2YgNDA5NiBvY3RldHMuIEhvdyBkb2VzIHRoZSBC R1Agc3BlYWtlciBzdXBwb3NlZCB0byBiZWhhdmUgaW4gdGhpcyA/PmNhc2U/IFRoaXMgc2hvdWxk IGJlIGRlc2NyaWJlZCBpbiB0aGlzIHNwZWNpZmljYXRpb24uIE5vdGUgdGhhdCB0aGlzIGlzIG5v dCBhIGNhc2Ugb2YgZXJyb3IgaGFuZGxpbmcsIGFzIGV2ZXJ5IEJHUA0KPiBzcGVha2VyIGlzIGJl aGF2aW5nIGFzIHNwZWNpZmllZC4NCg0KSSBmYWlsIHRvIHNlZSB5b3VyIGxvZ2ljLiAgQXQgdGhp cyBwb2ludCwgYWxsIEJHUCBkYXRhIChBRkkvU0FGSSBhbmQgYXR0cmlidXRlcykgbXVzdCBmaXQg d2l0aGluIGEgNDA5NiBtZXNzYWdlLiAgIFRoZXJlZm9yZSwgYSBCR1AgcGVlciBBIHdoaWNoIGNv bm5lY3RzIG9uIGxpbmsgMSB0byBCR1AgcGVlciBCIHdpdGggNDA5NiBtZXNzYWdlIGFuZCBvbiBs aW5rIHRvIGEgQkdQIHBlZXIgQyB3aXRoIGV4dGVuZGVkIG1lc3NhZ2VzIG9ubHkgaGFzIHRvIHdv cnJ5IGFib3V0IHJlZm9ybWF0dGluZyB0aGUgZGF0YS4NCg0KSW4gdGhlIGZ1dHVyZSwgdGhlIGZp cnN0IGdyb3VwIHRoYXQgZGVmaW5lcyBhdHRyaWJ1dGUgb3IgYW4gTkxSSSB0aGF0IGRvZXMgbm90 IGZpdCB3aXRoaW4gYSA0MDk2IEJHUCBtZXNzYWdlIGFuZCBjYW5ub3QgYmUgc3BsaXQsIHdpbGwg bmVlZCB0byBkZWZpbmUgaG93IHRoYXQgd29ya3MgaW4gdGhlIHNwZWNpZmljYXRpb24uICBUaGVy ZSBpcyBubyBuZWVkIHRvIHJlZmluZSB0aGUgY3VycmVudCBzZXQgb2Ygc3BlY2lmaWNhdGlvbnMu DQpbQnJ1bm9dDQoxKSBjZiBhYm92ZSwgSSBiZWxpZXZlIHRoYXQgdGhlcmUgYXJlIGV4aXN0aW5n IEJHUCBBdHRyaWJ1dGVzIHdoaWNoIG1heSBub3QgZml0IGludG8gYSBieXRlcyA0MDk2IEJHUCBt ZXNzYWdlDQoyKUV2ZW4gaW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCBhdHRyaWJ1dGUsIHlvdSBoYXZl IHRoZSBpc3N1ZSBvZiAyIHNtYWxsZXIgYXR0cmlidXRlcyB3aG9zZSBjdW11bGF0aXZlIHNpemUg ZG9lcyBub3QgZml0IGludG8gYSA0MDk2IGJ5dGVzIG1lc3NhZ2UuDQoNClRoZSBwcm9ibGVtIGlz IGludHJvZHVjZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uLCBoZW5jZSBJIGJlbGlldmUgdGhpcyBz cGVjaWZpY2F0aW9uIG5lZWRzIHRvIHNwZWNpZnkgaG93IHRvIGhhbmRsZSB0aGlzIGNhc2UuDQoN CltTdWVdOiAgSUhNTyB0aGUgbWVzc2FnZSB0cmFuc21pc3Npb24gYW5kIHJlY2VwdGlvbiBlcnJv ciBoYW5kbGluZyBpc3N1ZXMgYXJlIGNvbXBsZXRlIGluIHRoZSBjb21iaW5hdGlvbiBvZiBSRkM0 MjcxIGFuZCB0aGUgZXh0ZW5kZWQgbWVzc2FnZSBzZWN0aW9uIDUuDQoNCldoYXQgaXMgbm90IGlu IHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0aGUgcG9saWN5IGlzc3VlcyBhYm91dCB3aGF0IGhhcHBl bnMgaWYgeW91IGNvbWJpbmUgMiBzbWFsbGVyIGF0dHJpYnV0ZXMuICBGb3IgZXhhbXBsZSwgaWYg eW91IGhhdmUgYSBsYXJnZSBjb21tdW5pdHkgYXR0cmlidXRlIG9mIDQwMCBjb21tdW5pdGllcyAo NDgwMCBieXRlcyksIHlvdSB3aWxsIGxpa2VseSBydW4gaW50byBwcm9ibGVtcyB3aGVuIGNvbWJp bmluZyB3aXRoIHNvbWUgbG9uZ2VyIEFTIHBhdGggbGVuZ3Rocy4gIFs0ODAwLS0+IDUwOTYgYnl0 ZXMgaXMgYSBzaG9ydCBqdW1wXS4gUGVvcGxlIG9uIHRoZSBsaXN0IGFuZCBpbi1wZXJzb24gYXJn dWVkIHRoaXMgd2FzIHBvbGljeSBhbmQgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgZGV0YWlscy4N Cg0KSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGl0IGlzIGV4dHJlbWVseSB1c2VmdWwgdG8gdGhlIG9w ZXJhdG9yIGNvbW11bml0eSB0byBoYXZlIHRoaXMgdHlwZSBvZiBwb2xpY3kgZGV0YWlscyBkaXNj dXNzZWQgdG8gc2VlIGlmIHRoZXJlIGlzIHNvbWUgZGVzaXJlIHRvIGhhdmUgY29tbW9uIHBvbGlj aWVzIGFuZCBlcnJvciBjb21tdW5pdGllcy4gICBJdCBpcyB0aGUgdHlwZSBvZiB0aGluZyB0aGF0 IEdST1cgYW5kIElEUiBzaG91bGQgYmUgZGVlcGx5IGludm9sdmVkIGZvciBsYXJnZSBjb21tdW5p dGllcy4gICBCRVNTLCBMU1ZSLCBTUFJJTkcgYW5kIG90aGVycyBzaG91bGQgY29uc2lkZXIgd2hh dCBwb2xpY3kgc2hvdWxkIGJlIGFkYXB0ZWQgZm9yIHRoZWlyIGFwcGxpY2F0aW9ucy4NCg0KPi0t LS0NCj5EZXBlbmRpbmcgb24gdGhlIGFib3ZlIHNwZWNpZmljYXRpb24sIGEgc2VjdGlvbiBkZXNj cmliaW5nIHRoZSBvcGVyYXRpb25hbCBjb25zZXF1ZW5jZXMgaW4gYSBuZXR3b3JrIChzdWNoIGFz IHRoZSA+SW50ZXJuZXQsIEJHUCBFbmFibGVkIFNlcnZpY2VTL1ZQTiBuZXR3b3JrcykgaXMgcHJv YmFibHkgbmVlZGVkLiBQb3NzaWJsZSBjb25zZXF1ZW5jZXMgY291bGQgYmUgQkdQIE5MUkkgPmJl aW5nIHJlbW92ZWQgaW4gdGhlIG1pZGRsZSBvZiBzdWNoIG5ldHdvcmssIG9yIChleHRlbmRlZCkg Y29tbXVuaXR5IChzdWNoIGFzIFJvdXRlIFRhcmdldHMpIGJlZW4gcmVtb3ZlZC4gPkJvdGggaGF2 aW5nIHNpZ25pZmljYW50IGNvbnNlcXVlbmNlcyBvbiB0aGUgYXZhaWxhYmlsaXR5IHByb3ZpZGVk IGJ5IHRoZSBuZXR3b3JrLg0KDQpBdCB0aGlzIHBvaW50LCB0aGVyZSBhcmUgbm8gYXR0cmlidXRl cyBvciBOTFJJIGdyb3VwaW5ncyB0aGF0IGRvIG5vdCBmaXQgd2l0aGluIDQwOTYuICAgSWYgeW91 IGRlZmluZSBvbmUgKGFzIFNJRFIgZGlkKSwgdGhlbiB5b3Ugd2lsbCBuZWVkIHRvIGhhdmUgaXQg cmV2aWV3ZWQgYnkgSURSLCBCRVNTLCBTUFJJTkcsIGFuZCBvcGVyYXRpb25hbCBncm91cHMgKEdS T1csIGV0YykuDQpbQnJ1bm9dIG5vLCBjZiBhYm92ZS4NCltTdWVdOiAgVGhhbmsgeW91IGZvciBy ZW1pbmRpbmcgbWUgb2YgdGhlIHBvdGVudGlhbCBvZiBsYXJnZSBjb21tdW5pdGllcyB0byBibG93 IHVwIEJHUC4gIEkgaGF2ZSBhIG5ldyB3b3JyeSB0byBhZGQgdG8gbXkgQkdQIGNvbmNlcm5zIGxp c3QhDQoNClRoYW5rcywNCi0tQnJ1bm8NCg0KDQotLS0NCj7CpzQNCj5PTEQ6IFRoZSBFeHRlbmRl ZCBNZXNzYWdlIENhcGFiaWxpdHkgb25seSBhcHBsaWVzIHRvIGFsbCBtZXNzYWdlcyBleGNlcHQg Zm9yIHRoZSA+T1BFTiBtZXNzYWdlLg0KPlByb2JhYmx5DQo+TkVXOiBUaGUgRXh0ZW5kZWQgTWVz c2FnZSBDYXBhYmlsaXR5IGFwcGxpZXMgdG8gYWxsIG1lc3NhZ2UgdHlwZXMgZXhjZXB0IGZvciB0 aGUgPk9QRU4gbWVzc2FnZSAodHlwZSAxKS4NCj4tLS0tDQo+wqc4DQoNCj7igJxUaGlzIGV4dGVu c2lvbiB0byBCR1AgZG9lcyBub3QgY2hhbmdlIEJHUCdzIHVuZGVybHlpbmcgc2VjdXJpdHkgaXNz dWVzIMK7DQoNCj5CZWZvcmUgZXZhbHVhdGluZyB0aGlzLCBJIHRoaW5rIHRoaXMgZG9jdW1lbnQg c2hvdWxkIGZpcnN0IHNwZWNpZmllZCBob3cgYSBCR1ANCg0KPm1lc3NhZ2VzIGJpZ2dlciB0aGFu IDQwOTYgb2N0ZXRzIGlzIGhhbmRsZWQgd2hlbiBpdCBuZWVkcyB0byBiZSBzZW50IHRvIGENCg0K PnJlY2VpdmVkIG5vdCBzdXBwb3J0aW5nIHRoaXMgZXh0ZW5zaW9uLg0KDQpOaXRzOg0KPk9MRCA6 IHRvIHJlZHVjZSBjb21wZXhpdHkNCj5ORVcgOiB0byByZWR1Y2UgY29tcGxleGl0eQ0KDQpUaGFu a3MsDQotLUJydW5vDQoNCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgU3VzYW4gSGFyZXMNClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjksIDIwMTkg MTI6MzMgUE0NClRvOiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLi5vcmc+DQpTdWJqZWN0 OiBbSWRyXSBXRyBMYXN0IENhbGwgb24gRXh0ZW5lZCBNZXNzYWdlIFN1cHBvcnQNCg0KDQpUaGlz IGJlZ2lucyBhIDIgd2VlayBXRyBMQyBvbiBFeHRlbmRlZCBNZXNzYWdlIFN1cHBvcnQgZm9yIEJH UCAoZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTI3KS4gIFlvdSBjYW4gYWNj ZXNzIHRoZSBkcmFmdCBhdDoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLw0KDQpUaGUgYXV0aG9ycyBzaG91bGQg aW5kaWNhdGUgd2hldGhlciB0aGV5IGtub3cgb2YgYW55IElQUi4gICBJbXBsZW1lbnRlcnMgYXJl IGVuY291cmFnZWQgdG8gdXBkYXRlIHRoZSAgaW1wbGVtZW50YXRpb24gZGF0YSBhdDoNCg0KaHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVu ZGVkLWltcGxlbWVudGF0aW9ucw0KDQpUaGUgZHJhZnQgcHJvdmlkZXMgYSBtZWFucyBmb3IgZXhw YW5kaW5nIHRoZSBCR1AgbWVzc2FnZSB0byA2NTUzNSBvY3RldHMgZm9yIGFsbCBtZXNzYWdlcyBl eGNlcHQgT1BFTiBtZXNzYWdlcy4gIEJHUCBtZXNzYWdlIHNwYWNlIGlzIHJ1bm5pbmcgc2hvcnQg Zm9yIGFsbCBvZiB0aGUgcG90ZW50aWFsIGF0dHJpYnV0ZXMgb3IgYWRkaXRpb25zIHByb3Bvc2Vk IGJ5IEJHUC1MUyBmZWF0dXJlcy4NCg0KVGhlIFdHIGNoYWlycyBpbnRlbmQgdG8gZm9yd2FyZCB0 aGlzIGRyYWZ0IHRvIHRoZSBJRVNHIHdpdGggdGhlIGN1cnJlbnQgbGV2ZWwgb2YgaW1wbGVtZW50 YXRpb24uDQoNCkFzIHlvdSBjb21tZW50IG9uIHRoZSBkcmFmdCwgcGxlYXNlIGNvbnNpZGVyIGlm OiBhKSB0aGUgdGVjaG5vbG9neSBpcyBtYXR1cmUsIGIpIHRoZSBhZGRpdGlvbmFsIHNwYWNlIGlu IGEgQkdQIG1lc3NhZ2Ugd291bGQgYmUgaGVscGZ1bCBmb3IgdGhvc2UgZGVwbG95aW5nIEJHUC1M UyBvciBTUiwgYW5kIGMpIGlmIHRoZSBzcGVjaWZpY2F0aW9uIGlzIHJlYWR5IGZvciBwdWJsaWNh dGlvbi4NCg0KU3VlIEhhcmVzIChXRyBDaGFpciwgU2hlcGhlcmQpDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN Cg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoN Cg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoN CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRm Lm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pZHINCg== --_000_BN6PR11MB2050623467364B68264208D6C0610BN6PR11MB2050namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tNzE1Mjk3ODc1 OTEwNjgyODY1bXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbTcxNTI5Nzg3NTkxMDY4Mjg2NW1z b2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tNzE1Mjk3ODc1OTEwNjgyODY1bXNvbGlzdHBhcmFn cmFwaA0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXzcxNTI5Nzg3NTkxMDY4Mjg2NW1zb2xpc3Rw YXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCWNvbG9yOiM3MDMwQTA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojNzAzMEEwIj5UaGlzIGlzIGEgc2hvdyBzdG9wcGVyIGZvciBtZSB0b28uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Izcw MzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+T25lIHdheSB0byBzb2x2ZSBpdCB3b3VsZCBiZSB0byBy ZXN0cmljdCB0aGUgZXh0ZW5kZWQgbWVzc2FnZXMgdG8gbmV3IGFkZHJlc3MgZmFtaWxpZXMgb25s eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojNzAzMEEwIj5BbnkgbmV3IGFkZHJlc3MgZmFtaWx5IHdvdWxkIHRoZW4gbmVlZCB0byBz cGVjaWZ5IHRoYXQgaXQgbXVzdCBzdXBwb3J0IGV4dGVuZGVkIG1lc3NhZ2VzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAi PnN1Y2ggdGhhdCBhbGwgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBuZXcgYWRkcmVzcyBmYW1pbHkg bXVzdCBzdXBwb3J0IHRoZSBleHRlbmRlZCBtZXNzYWdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj NzAzMEEwIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPkpha29iLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5bQnJ1bm9dIExldOKAmXMgdGFrZSB0aGUgZXhhbXBsZSBvZiBhIEJH UCBSb3V0ZSBSZWZsZWN0b3IgaGF2aW5nIGEgbWl4ZWQgb2YgY2xpZW50cywgc29tZSBzdXBwb3J0 aW5nIEV4dGVuZCBNZXNzYWdlIChFTSkgYW5kIHNvbWUgbm90Ljwvc3Bhbj48L2k+PC9iPjxiPjxp PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5Gcm9tIGFuIEVNIGNsaWVudCwgaXQgcmVjZWl2ZXMgYSBCR1AgdXBkYXRlIGNvbnRhaW5pbmcg b25lIChzaW5nbGUpIE5MUkkgd2l0aCBhbiBUb3RhbCBQYXRoIEF0dHJpYnV0ZSBMZW5ndGggYmln Z2VyIHRoYW4mbmJzcDsgNDA5MCBieXRlIChlLmcuIGhhdmluZyAxMDAwIGxhcmdlIGNvbW11bml0 aWVzcyk8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DYW4geW91IGV4cGxhaW4gbWUgaG93 IGl0IGJlaGF2ZXMgdG8gc2VuZCB0aGlzIE5MUkkgdG8gYW4gSUJHUCBwZWVyIG5vdCBzdXBwb3J0 aW5nIEVNPzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IElkciAm bHQ7aWRyLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpSb2JlcnQg UmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMTUsIDIwMTkgMTozNCBB TTxicj4NCjxiPlRvOjwvYj4gU3VzYW4gSGFyZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDs8YnI+ DQo8Yj5DYzo8L2I+IEJydW5vIERlY3JhZW5lICZsdDticnVuby5kZWNyYWVuZUBvcmFuZ2UuY29t Jmd0OzsgaWRyQGlldGYuIG9yZyAmbHQ7aWRyQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0lkcl0gV0cgTGFzdCBDYWxsIG9uIEV4dGVuZWQgTWVzc2FnZSBTdXBwb3J0PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgU3VlICZhbXA7 IGF1dGhvcnMgb2YgdGhpcyBwcm9wb3NhbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgVGhlcmVmb3JlLCZu YnNwO3B1dHRpbmcgYW4gYXR0cmlidXRlIHdoaWNoJm5ic3A7Y2Fubm90IGJlIGRlY29tcG9zZWQg dG8mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IDQwOTYgb2N0ZXRzIG9yJm5ic3A7bGVzcyBpbiBhbiBF eHRlbmRlZCBNZXNzYWdlIGlzIGEgbGlrZWx5IHBhdGggdG8mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7 IHJvdXRpbmcgZmFpbHVyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoYXQncyBicmlsbGlhbnQgc3RhdGVtZW50 IGJ1dCBub3QgZW5vdWdoIHRvIHByb2NlZWQgd2l0aCB0aGlzIHNwZWMuJm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPlNlZSB0aGUgZnVuZGFtZW50YWwgY2hhbmdlIHRoYXQgdG9kYXkgc3VjaCBpc3N1ZSBp cyBpbiB2YXN0IG1ham9yaXR5IG9mIGNhc2VzIGxvY2FsbHkgc2lnbmlmaWNhbnQuIFRoYXQgbWVh bnMNCiB0aGF0IGlmIEkgc2VuZCBOTFJJIHRvIEJHUCBpdCB3aWxsIGhhdmUgYSBkZWNlbnQgY2hh bmNlIHRvIGJlIHJlY2VpdmVkIGJ5IGFsbCBpbnRlbmRlZCBwYXJ0aWVzLiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5XaXRoIG5l dyBzcGVjIHdlIGFyZSBzYXlpbmcgdGhhdCBpdCBtYXkgc2lsZW50bHkgZmFpbCBzb21ld2hlcmUg aW4gdGhlIG1pZGRsZSBhbmQgd2UgZG8gbm90IGRvIGFueXRoaW5nIGFib3V0DQogaXQuIFRoYXQn cyB0byBtZSBzaG93c3RvcHBlci4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QXQgbWluIGlmIGdpdmVuIE5MUkkgY2FuIG5vdCBi ZSBzZW50IHdpdGggWFhMIGF0dHJpYnV0ZXMgdG8gc29tZSBwZWVycyAoc2F5IG9uIHRoZSBSUiB3 aGljaCBCcnVubyBtZW50aW9uZWQpDQogd2UgbXVzdCBzcGVjaWZ5IHByb3RvY29sIGV4dGVuc2lv biZuYnNwO2luIHRoaXMgdmVyeSBzcGVjIG9uIGhvdyB0byBkZWFsIHdpdGggaXQuJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlN1 Y2ggZXh0ZW5zaW9uIG1heSBiZSBhcyBzaW1wbGUgYXMgdG8gZGVmaW5lIGEgc2hvcnQgYXR0cmli dXRlIEJHUF9QSVBFX1RPT19USElOIHdoaWNoIHdpbGwgYmUgaW5zZXJ0ZWQgaW4gdGhlDQogcGxh Y2Ugd2hlcmUgWFhMIGF0dHJpYnV0ZSBqdXN0IGRpZCBub3QgZml0IHNtYWxsZXIgbWVzc2FnZSBz aXplIHBlZXJzIHRvIHRlbGwgdGhlbSB0aGVuICZxdW90O0hleSBzb21ldGhpbmcgaXMgYnJva2Vu IHdpdGggdGhpcyBOTFJJJnF1b3Q7IC0gcGxzIGNoZWNrLiBUaGVuIGl0IHdpbGwgYmUgdXAgdG8g bG9jYWwgcG9saWN5IHRvIGluc3RhbGwgc3VjaCBOTFJJIG9yIGRyb3AgaXQuJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoeCw8 YnI+DQpSLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUaHUsIEZlYiAxNCwgMjAxOSBhdCA2OjIxIFBNIFN1c2FuIEhhcmVz ICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ QnJ1bm86DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFuayB5 b3UgZm9yIGNhcmVmdWwgY29uc2lkZXJhdGlvbnMgb24gdGhlIHVzZSBjYXNlLiZuYnNwOyZuYnNw OyBJIHRoaW5rIHdlIGhhdmUgdHJhbnNsYXRpb24gaXNzdWVzIGJldHdlZW4gb3VyIOKAnEVuZ2xp c2jigJ0gbGFuZ3VhZ2UgYWdhaW4gc28gSSBoYXZlIHRyaWVkIHRvIGJlDQogcHJlY2lzZSBpbiB0 aGUgZGV0YWlsZWQgY29tbWVudHMuJm5ic3A7IEnigJl2ZSBzdW1tYXJpemVkIG15IGNvbW1lbnRz IGFzIHdlbGwgdG8gaGVscCB1cyB0YWtlIHRoZSBuZXh0IHN0ZXAuDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TdWUNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlN1bW1hcnk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLS0tPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+R29vZCBjYXRjaCBvbiB0aGUgMTAwMCBsYXJnZSBCR1AgY29tbXVuaXRpZXMgYmxvd2lu ZyB1cCB0aGUgbWVzc2FnZSBzaXplISZuYnNwOyBUaGlzIGlzIGEgY2FzZSB3aGVyZSBhIGNvZGUg cGF0aCBjb3VsZCBnZXQgY2F1Z2h0IHdpdGggcHJvZ3JhbSBlcnJvci4uJm5ic3A7IFRoZQ0KIGVy cm9yIGhhbmRsaW5nIChzZWN0aW9uIDYuMSBpbiBSRkM0MjcxIHBlciBzZWN0aW9uIDUgaW4gdGhl IGV4dGVuZGVkIHNwZWNpZmljYXRpb24pIElNSE8gaGFuZGxlcyB0aGUgY2FzZSB3aGVyZSB0aGUg YXR0cmlidXRlIGlzIGxvbmdlciB0aGFuIHRoZSBtZXNzYWdlLiZuYnNwOyAmbmJzcDtQbGVhc2Ug bGV0IG1lIGtub3cgaWYgSeKAmXZlIG1pc3NlZCBzb21ldGhpbmcuICZuYnNwOyZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFzIEkgdW5kZXJzdGFuZCBpdCwg Jm5ic3A7eW91IGFyZSBhc2tpbmcgdGhpcyBzcGVjaWZpY2F0aW9uIHRvIGJlIGV4cGFuZGVkIHRv IGFkZCBub3RlcyBvbiBwb2xpY2llcyBvbiB3aGF0IGltcGxlbWVudGF0aW9uIHNob3VsZCBkbyB0 byBjb3JyZWN0bHkgY29tYmluZQ0KIFJGQzQyNzEgbGVuZ3RoIHNpemVzIHdpdGggZXh0ZW5kZWQg bGVuZ3RoIHNpemVzLiZuYnNwOyZuYnNwOyBUaGUgaW1wbGVtZW50ZXJzIGFuZCBvcGVyYXRpb25z IHBlb3BsZSBjb21tZW50ZWQgZWFybGllciB0aGF0IHRoaXMgc2hvdWxkIG5vdCBiZSBpbiB0aGUg cHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBvdGhlciB0aGFuIGFzIGEgYnJpZWYgZm9vdG5vdGUuJm5i c3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRo ZXJlIGlzIGEgbmVlZCBmb3Igc3VjaCBzdGFuZGFyZGl6YXRpb24gYXMgQkNQcyBmb3IgcGFydGlj dWxhciB1c2UgY2FzZXMgKGxhcmdlIGNvbW11bml0aWVzLCBCRVNTIChFVlBOIG9yIGNlbnRyYWxp emVkIGNvbnRyb2xsZXIpLCBTUFJJTkcsDQogQkdQLUxTIGluZm9ybWF0aW9uIChzZWUgRGF5bGln aHQgY29tbWVudHMgeWVzdGVyZGF5KSwgU0QtV0FOcyAocnRnd2cpLCBhbmQgU1BSSU5HLiZuYnNw OyAmbmJzcDtJIHRoaW5rIHRoZSBjaGFpcnMgb2YgdGhlIFdHcyB1dGlsaXppbmcgc2hvdWxkIGNv bnNpZGVyIGlmIHRoZXJlIGlzIG5lZWQgZm9yIHN0YW5kYXJkaXphdGlvbiBmb3IgYSBtaW5pbWFs IHNldCBvZiBwb2xpY3kgZm9yIG1lc3NhZ2Ugc2l6ZXMgZm9yIHNwZWNpZmljIHVzZSBjYXNlcy4m bmJzcDsmbmJzcDsgSSB3aWxsDQogYmUgZ2xhZCB0byBzZW5kIHJlcXVlc3QgdG8gdGhlc2UgV0cg b3IgdG8gaG9zdCBzb21ldGhpbmcgaW4gSURSIGlmIHRoZXJlIGlzIHBvbGljeSB0aGF0IGNhbiBi ZSB1c2VkIGFjcm9zcyBhbGwgdXNlIGNhc2VzLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+VG8gcHJvdmlkZSBhIHNsaWdodCBleHBhbnNpb24gdG8gcG9pbnQgcGVv cGxlIGluIHRoaXMgZGlyZWN0aW9uLCBob3cgYWJvdXQgdGhpcyBjaGFuZ2UgdG8gcGFyYWdyYXBo IGluIHNlY3Rpb24gNDoNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi Pk9sZC88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQSBCR1AgYW5ub3VuY2VtZW50IHdpbGwsIGlu IHRoZSBub3JtYWwgY2FzZSwgcHJvcGFnYXRlIHRocm91Z2hvdXQgdGhlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IEJHUCBzcGVha2luZyBJbnRlcm5ldDsgYW5kIHRoZXJlIHdpbGwgdW5kb3VidGVk bHkgYmUgQkdQIHNwZWFrZXJzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHdoaWNoIGRvIG5vdCBo YXZlIHRoZSBFeHRlbmRlZCBNZXNzYWdlIGNhcGFiaWxpdHkuJm5ic3A7IFRoZXJlZm9yZSw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgcHV0dGluZyBhbiBhdHRyaWJ1dGUgd2hpY2ggY2FuIG5vdCBi ZSBkZWNvbXBvc2VkIHRvIDQwOTYgb2N0ZXRzIG9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGxl c3MgaW4gYW4gRXh0ZW5kZWQgTWVzc2FnZSBpcyBhIGxpa2VseSBwYXRoIHRvIHJvdXRpbmcgZmFp bHVyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4vPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TmV3Lzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBBIEJHUCBhbm5vdW5jZW1lbnQgd2lsbCwgaW4gdGhlIG5vcm1hbCBjYXNlLCBwcm9wYWdhdGUg dGhyb3VnaG91dCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQkdQIHNwZWFraW5nIEludGVy bmV0OyBhbmQgdGhlcmUgd2lsbCB1bmRvdWJ0ZWRseSBiZSBCR1Agc3BlYWtlcnM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgd2hpY2ggZG8gbm90IGhhdmUgdGhlIEV4dGVuZGVkIE1lc3NhZ2UgY2Fw YWJpbGl0eS4mbmJzcDsgVGhlcmVmb3JlLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwdXR0aW5n IGFuIGF0dHJpYnV0ZSB3aGljaCBjYW5ub3QgYmUgZGVjb21wb3NlZCB0byA0MDk2IG9jdGV0cyBv cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBsZXNzIGluIGFuIEV4dGVuZGVkIE1lc3NhZ2UgaXMg YSBsaWtlbHkgcGF0aCB0byByb3V0aW5nIGZhaWx1cmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IE9uZSBleGFtcGxlIG9mIGEgdmFsaWQgYXR0cmlidXRlIHdoaWNoIGNhbm5vdCBiZSBwcmVjaXNl bHkgZGVjb21wb3NlZCBpZiBpdA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7c2VudCBp biBFeHRlbmRlZCBtZXNzYWdlIGlzIGEgbGFyZ2UgY29tbXVuaXR5IGF0dHJpYnV0ZSB3aXRoIDEw MDAgY29tbXVuaXRpZXMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsoMTIsMDAwIGJ5 dGVzKS4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPi88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bUFMg4oCTIGluIEFtZXJpY2Fu IEVuZ2xpc2gg4oCcQ2FuIG5vdOKAnSBpcyBub3JtYWxseSBjb25jYXRlbmF0ZWQg4oCcY2Fubm90 4oCdLl0NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWYiPg0KPGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20i IHRhcmdldD0iX2JsYW5rIj5icnVuby4uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4gW21haWx0bzo8 YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz ZGF5LCBGZWJydWFyeSAxNCwgMjAxOSAzOjI5IEFNPGJyPg0KPGI+VG86PC9iPiBTdXNhbiBIYXJl czxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmlkckBpZXRmLm9yZzwvYT47ICdKYWtvYiBIZWl0eiAoamhlaXR6KSc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3Vw cG9ydDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlN1ZSw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgcmVwbHku IFBsZWFzZSBzZWUgaW5saW5lIFtCcnVub108L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8Yj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBTdXNh biBIYXJlcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iIHRhcmdldD0i X2JsYW5rIj5zaGFyZXNAbmR6aC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgRmVicnVhcnkgMTMsIDIwMTkgODowMyBQTTxicj4NCjxiPlRvOjwvYj4gREVDUkFFTkUgQnJ1 bm8gVEdJL09MTjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmlkckBpZXRmLm9yZzwvYT47ICdKYWtvYiBIZWl0eiAoamhlaXR6KSc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtJZHJdIFdHIExhc3QgQ2FsbCBvbiBFeHRlbmVkIE1l c3NhZ2UgU3VwcG9ydDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkZSIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CcnVubzogPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRw dCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+SeKAmWQgbGlrZSB0byBhbnN3ZXIgc29tZSBvZiB0aGUgcXVl c3Rpb25zIHlvdSBzZW50IFJhbmR5IGJhc2VkIG9uIGNvbW1lbnRzIChwdWJsaWMgYW5kIHByaXZh dGUpIHRoZSBjaGFpcnMgYW5kIEkgYXMgdGhlIHNoZXBoZXJkIHJlY2VpdmVkIG9uIHRoaXMgZHJh ZnQgaW4gb3VyIGxhc3QgV0cgTENzLiAmbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5TZXZlcmFsIG9mIHRoZSBjb21tZW50cyB5b3UgcXVlc3Rpb25lZCB3ZXJlIHB1dCBpbiB0 byBhbnN3ZXIgb3RoZXIgcXVlc3Rpb25zLiZuYnNwOyZuYnNwOyBUaGlzIGdldHMgaW50byBhIGNh dGNoLTIy4oCmIHByb2JsZW0g4oCTIHdoZXJlIHlvdSBwdXQgY2hhbmdlcyBpbiBmb3Igb25lIHBl cnNvbi90YWtlIG91dCB0aGUgY2hhbmdlcyBvdXQgZm9yIGFub3RoZXIuJm5ic3A7IEluIGFjYWRl bWljIGNpcmNsZXMgdGhpcyBpcyBjYWxsZWQNCiB0aGUgcmV2aWV3ZXIgIzIgcHJvYmxlbSAocmV2 aWV3ZXIgMSBpbnNpc3RzIGNoYW5nZXMgZ28gaW4sIHJldmlld2VyIDIgaW5zaXN0cyBjaGFuZ2Vz IGdvIG91dCkgZHVyaW5nIHB1YmxpY2F0aW9uLiZuYnNwOyBUaGVyZWZvcmUsIEnigJltIEkgYW0g Z29pbmcgdG8gYW5zd2VyIG1vc3Qgb2YgeW91ciBxdWVzdGlvbnMgd2hlcmUgdGhpcyBpcyB0aGUg Y2FzZS4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYmVsaWV2ZSB0aGF0IFJh bmR5IGhhcyBuZXcgdmVyc2lvbiB3aXRoIHRoZSBjaGFuZ2VzIEnigJl2ZSBpbmRpY2F0ZWQuJm5i c3A7IEnigJltIGhvcGluZyBoZeKAmWxsIGp1c3QgcG9zdCB0aGF0IHZlcnNpb24uJm5ic3A7IEFG QUlMSywgd2UgZG8gaGF2ZSAyIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMuDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4N CjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5TdWUgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1 LjRwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O3NoZXBoZXJkIGhhdCBvbiZndDsgPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhpcyBkcmFmdOKAmXMgdGVjaG5vbG9neSBw cm92aWRlcyBlZmZpY2llbnQgcHJvY2Vzc2luZyBmb3Igc29tZSBhcHBsaWNhdGlvbiBieSBhbGxv dyBhIGh1Z2UgQkdQIG1lc3NhZ2Ugc2l6ZS4mbmJzcDsgV2hldGhlciDigJxjaHVua2luZ+KAnSBC R1AgdG8gNDA5NiBieXRlIG1lc3NhZ2VzIG9yIHBhY2tpbmcgbGFyZ2UgYW1vdW50cyBvZiBkYXRh IGludG8gNjUsMDAwIGJ5dGUgbWVzc2FnZSBpcyBtb3JlIGVmZmVjdGl2ZQ0KIGZvciBhIHBhcnRp Y3VsYXIgYXBwbGljYXRpb24gaXMgc29tZXRoaW5nIG9ubHkgYW4gaW1wbGVtZW50ZXIgb2YgYSBw YXJ0aWN1bGFyIEJHUCBpbXBsZW1lbnRhdGlvbiAmbmJzcDtjYW4gZGVjaWRlLi4gJm5ic3A7Jm5i c3A7VGhpcyBkcmFmdCBzaW1wbHkgZ2l2ZXMgZnJlZWRvbSBmb3IgYXBwbGljYXRpb25zIHRvIG5v dCBiZSByZXN0cmljdCB0byBhbiBhcnRpZmljaWFsbHkgc21hbGwgbWVzc2FnZSBzaXplLiZuYnNw OyBUaGUgbWFya2V0IHBsYWNlIHdpbGwgY2hvb3NlIHdoZXRoZXINCiB0aGlzIHRlY2hub2xvZ3kg aXMgdXNlZCBvciBub3QuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgSmFrb2Ig cG9pbnRlZCBvdXQsIGNoYW5naW5nIGEgaGlnaGx5IHR1bmVkIEJHUCBpbXBsZW1lbnRhdGlvbiB3 aGljaCDigJxjaHVua3PigJ0gQkdQIGRhdGEgaW50byA0MDk2IGJ5dGUgbWVzc2FnZXMgbWF5IGlu dm9sdmUgc3Vic3RhbnRpYWwgcmV3b3JrIG9mIHRoZSBpbXBsZW1lbnRhdGlvbi4mbmJzcDsNCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz NS40cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzUuNHB0Ij4NCjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+KHNuaXApIDwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRw dCI+DQo8Yj5Gcm9tOjwvYj4gSWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5P biBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29t IiB0YXJnZXQ9Il9ibGFuayI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5T ZW50OjwvYj4gMjkgSmFudWFyeSAyMDE5IDEzOjMzPGJyPg0KPGI+VG86PC9iPiBTdXNhbiBIYXJl cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNo YXJlc0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86aWRy QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWRyQGlldGYub3JnPC9hPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW0lkcl0gV0cgTGFzdCBDYWxsIG9uIEV4dGVuZWQgTWVzc2FnZSBTdXBwb3J0 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5IaSBXRyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40 cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPlBsZWFzZSBmaW5kIGJlbG93IHNvbWUgY29tbWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QXMgb2YgdG9kYXks IEkgZG9u4oCZdCBiZWxpZXZlIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyByZWFkeSB0byBiZSBwcm9n cmVzc2VkIHRvIElFU0cvUkZDLCBlc3BlY2lhbGx5IGZvciBhIGRvY3VtZW50DQo8c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj51cGRhdGluZyBSRkMgNDI3MSAoY29yZSBCR1Ag c3BlYykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7IFRoZSBXRyBjaGFpcnMgaW50ZW5kIHRvIGZvcndhcmQgdGhpcyBk cmFmdCB0byB0aGUgSUVTRyB3aXRoIHRoZSBjdXJyZW50IGxldmVsIG9mIGltcGxlbWVudGF0aW9u LiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0i NSIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI2MzYiIHN0eWxlPSJ3aWR0aDo0NzYuOXB0O21hcmdp bi1sZWZ0OjM1LjRwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQg Ljc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVk LSUzZWltcGxlbWVudGF0aW9ucyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdHJhYy5pZXRmLm9y Zy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC0mZ3Q7aW1wbGVtZW50 YXRpb25zPC9hPg0KIHNheXMgOiA8L3NwYW4+NWEgPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+RG9lcyBub3Qgc2VuZCBFeHRlbmRlZCBNZXNzYWdlIGNhcGFiaWxpdHkNCjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAu NzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcw0KPG86cD48L286cD48L3A+DQo8L3Rk Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlllcw0KPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVzDQo8bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5JIG1heSBiZSBtaXN1bmRlcnN0YW5kaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiByZXBvcnQsIGJ1 dCBteSByZWFkaW5nIG9mIHRoZSBhYm92ZSBpcyB0aGF0IG5vbmUgb2YgdGhlIHJlcG9ydGVkDQo8 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5pbXBsZW1lbnRhdGlvbnMgc2Vu ZHMgdGhlIGNhcGFiaWxpdHkgaGVuY2Ugbm8gaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgZHJhZnQt aWV0Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SGVyZSB0aGlzIGRvY3Vt ZW50IGlzIHVwZGF0aW5nIFJGQyA0MjcxLCBzbyBpdCBpcyBub3QgYSBtaW5vciBleHRlbnNpb24g Zm9yIGEgbmljaGUgdXNlIGNhc2UuIFNvIEkgZG9u4oCZdCBzZWUgdGhlDQo8c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5hcmd1bWVudHMgZm9yIG5vdCByZXF1aXJpbmcgdGhl IElEUuKAmXMgdXN1YWwgdHdvIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDtJbiBvdXIgbWFpbCB0aHJlYWQsIHdlIGRpc2NvdmVyZWQg dGhhdCB0aGUgaW1wbGVtZW50YXRpb24gcmVwb3J0IHNob3VsZCBoYXZlIGluZGljYXRlPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRw dCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0O2Z1bGwgc3VwcG9ydC4mbmJzcDsm bmJzcDsgSeKAmW0gd2FpdGluZyBmb3IgT2xpdmllciB0byB1cGRhdGUgYmFzZWQgb24gdGhlIGxh c3QgcG9pbnQsIGJ1dCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQNCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFsbCBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBmdWxsIHN1cHBv cnQuICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltCcnVub10gb2ssIHNvbHZlZDwvc3Bhbj48L2k+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRw dCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+wqcgMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+4oCcIEFzIEJHUCBpcyBleHRlbmRlZCB0byBzdXBwb3J0IG5ld2VyIEFGSS9TQUZJcyBh bmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyBuZXdlciBjYXBhYmlsaXRpZXMgKGUuZy4sIFs8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTI3I3JlZi1JLUQuaWV0Zi1zaWRyLWJncHNlYy1w cm90b2NvbCIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtCR1BTRUMgUHJvdG9jb2wgU3Bl Y2lmaWNhdGlvbiZxdW90OyI+PHNwYW4gbGFuZz0iRU4tVVMiPkktRC5pZXRmLXNpZHItYmdwc2Vj LXByb3RvY29sPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl0pLA0KIHRoZXJlIGlzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRw dCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgYSBuZWVkIHRvIGV4dGVuZCB0aGUgbWF4aW11bSBtZXNzYWdlIHNpemUgYmV5b25kIDQw OTYgb2N0ZXRzLiZuYnNwOyDigJw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZn dDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMtMjcjc2VjdGlvbi0xIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRy LWJncC1leHRlbmRlZC1tZXNzYWdlcy0yNyNzZWN0aW9uLTE8L2E+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Wzwvc3Bhbj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0yNyNyZWYtSS1ELmlldGYtc2lk ci1iZ3BzZWMtcHJvdG9jb2wiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7QkdQU0VDIFBy b3RvY29sIFNwZWNpZmljYXRpb24mcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5JLUQuaWV0Zi1z aWRyLWJncHNlYy1wcm90b2NvbDwvc3Bhbj48L2E+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+aXMg bm93IFJGQyA4MjA1ICh0aGFua3MgZm9yIHVwZGF0aW5nIHRoZSByZWZlcmVuY2UpLiBJdCBoYXMg cmVtb3ZlZCB0aGUgbm9ybWF0aXZlL2FueQ0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZn dDs8L3NwYW4+cmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdl cy4gU28gcHJlc3VtYWJseSBCR1AgU2VjIGRvZXMgbm90IG5lZWQgZHJhZnQtaWV0Zi1pZHItYmdw LTxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPmV4dGVuZGVkLW1lc3NhZ2Vz LjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj5DYW4gd2UgaGF2ZSBhbiB1cGRh dGUgb24gdGhpcz88c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ICZuYnNwOzwvc3Bhbj5DYW4g dGhlIGludHJvZHVjdGlvbiBvZg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5kcmFmdC1pZXRm LWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMgPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+YmUgdXBkYXRlZCB0byBp bnRyb2R1Y2Ugb24gdGhlIHJlYWwgcmVhc29ucy9uZWVkcz88L3NwYW4+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+U0lEUiBnYXZlIHVwIHdhaXRpbmcgb24gSURS4oCZcyB3b3JrIGFuZCB0b29r IGEgcmVkdWNlZCBzaXplIG9mIGVuY3J5cHRpb24uJm5ic3A7Jm5ic3A7IFRoZSBzZWN1cml0eSBw ZW9wbGUgd2VyZSB2ZXJ5IHNhZCBhYm91dCB0aGUgcmVkdWN0aW9uLiZuYnNwOyBIb3cgaXMgdGhp cyB3b3JraW5nIGluIHByYWN0aWNlPyBXRyBzaWRyb3BzIGNhbiBhbnN3ZXIgdGhpcyBxdWVzdGlv bi4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz NS40cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSByZWFsIHByb2JsZW0gaXMg dGhlcmUgaXMgZmluaXRlIG1lc3NhZ2Ugc3BhY2UuJm5ic3A7IDwvc3Bhbj4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+W0JydW5vXSBTbyB0b28gYmFkIHRoZSBkcmFmdCBkb2VzIG5vdCBzb2x2ZSB0aGUgcmVh bCBwcm9ibGVtIDstKSAoYXMgbWVzc2FnZSBzcGFjZSBpcyBzdGlsbCBsaW1pdGVkKTwvc3Bhbj48 L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W1N1ZV06IFRoZSBtZXNz YWdlIGlzIHN0aWxsIGZpbml0ZSAoc21pbGUpLCAmbmJzcDtidXQgSSBob3BlIDY1LDYzNSAoc21p bGUpIGlzIHByb2JhYmx5IGVub3VnaCBmb3IgMTAgeWVhcnMuJm5ic3A7ICZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZXJlIGFyZSB0d28gd2F5cyB0byBzZW5kIGxvdHMgb2YgQkdQ IHJvdXRlcyBhbmQvb3IgYXR0cmlidXRlcyDigJMgdG8g4oCcY2h1bmvigJ0gdGhlc2UgaW50byBz bWFsbCBtZXNzYWdlIHNpemVzIG9yIHBsYWNlIHRoZXNlIGludG8gYSBsYXJnZSBtZXNzYWdlLiZu YnNwOyZuYnNwOyAmbmJzcDtTb21lIGFwcGxpY2F0aW9ucyBtYXkgYWx3YXlzIHdhbnQgdG8g4oCc Y2h1bmvigJ0gaW50byBtZXNzYWdlIHNpemVzIHNtYWxsZXIgdGhhbiA0MDk2LiZuYnNwOw0KICZu YnNwO1NvbWUgYXBwbGljYXRpb24gbWFrZSB3b3JrIG1vcmUgZWZmaWNpZW50bHkgdXRpbGl6aW5n IGxhcmdlIG1lc3NhZ2Ugc2l6ZS4mbmJzcDsgQXMgdGhlIHBvdGVudGlhbCBudW1iZXIgb2YgTkxS SSBhbmQgQkdQIGF0dHJpYnV0ZXMgZ3Jvd3MsIG5ldyBhcHBsaWNhdGlvbnMgbWF5IGNvbnNpZGVy IGxhcmdlIG1lc3NhZ2Ugc2l6ZXMgdG8gYSBtb3JlIHJlYXNvbmFibGUgd2F5IHRvIGV4Y2hhbmdl IGFtb3VudHMgb2YgQkdQIGRhdGEuJm5ic3A7Jm5ic3A7ICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlRoZSBkZWNpc2lvbiBvbiBob3cgdG8gc2VuZCBCR1AgbWVzc2FnZXMgb3ZlciB0 aGUgd2lyZSBpcyBhIHBlZXItYnktcGVlciBkZWNpc2lvbiBpbiBhIG5ldHdvcmsuJm5ic3A7ICZu YnNwO0VhY2ggQkdQIHBlZXIgaXMgaW4gY2hhcmdlIG9mIHJlZm9ybWF0dGluZyB0aGUgQkdQIG1l c3NhZ2UgaXQgc2VuZHMgdG8gdGhlIHJlbW90ZSBCR1AgcGVlci4mbmJzcDsmbmJzcDsgVGhlIEJH UCBjYXBhYmlsaXRpZXMgaW4gdGhpcyBkcmFmdCByZXByZXNlbnQNCiBhbiBhZ3JlZW1lbnQgYmV0 d2VlbiB0d28gQkdQIHBlZXJzLiZuYnNwOyBUaGVzZSBhcmUgZmFjdHMgb2YgYmFzaWMgQkdQIGlt cGxlbWVudGF0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltCcnVub10gTGV04oCZcyB0YWtl IHRoZSBleGFtcGxlIG9mIGEgQkdQIFJvdXRlIFJlZmxlY3RvciBoYXZpbmcgYSBtaXhlZCBvZiBj bGllbnRzLCBzb21lIHN1cHBvcnRpbmcgRXh0ZW5kIE1lc3NhZ2UgKEVNKSBhbmQgc29tZSBub3Qu PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Gcm9tIGFuIEVNIGNsaWVudCwgaXQgcmVj ZWl2ZXMgYSBCR1AgdXBkYXRlIGNvbnRhaW5pbmcgb25lIChzaW5nbGUpIE5MUkkgd2l0aCBhbiBU b3RhbCBQYXRoIEF0dHJpYnV0ZSBMZW5ndGggYmlnZ2VyIHRoYW4mbmJzcDsgNDA5MCBieXRlIChl LmcuIGhhdmluZw0KIDEwMDAgbGFyZ2UgY29tbXVuaXRpZXNzKTwvc3Bhbj48L2k+PC9iPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Q2FuIHlvdSBleHBsYWluIG1lIGhvdyBpdCBiZWhhdmVzIHRvIHNlbmQgdGhp cyBOTFJJIHRvIGFuIElCR1AgcGVlciBub3Qgc3VwcG9ydGluZyBFTT88L3NwYW4+PC9pPjwvYj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPltTdWVdOiZuYnNwOyBHbGFkbHnigKYNCjwvc3Bhbj48L2k+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+QSBCR1Agcm91dGUgcmVmbGVjdG9yIChSUi1BKSBpcyBwZWVyaW5nIHdp dGggZWFjaCBvZiBpdHMgQkdQIGNsaWVudHMuJm5ic3A7ICZuYnNwO0l0IGFncmVlcyB3aXRoIGVh Y2ggb2YgaXRzIGNsaWVudHMgKEJHUC1DMSwgQkdQQzIsIEJHUEMzKSB3aGV0aGVyIHRoZSBCR1AN CiBFeHRlbmRlZCBtZXNzYWdlcyBpcyBhY2NlcHRlZCBvciBub3QgKGJhc2VkIG9uIGNhcGFiaWxp dHkgYW5ub3VuY2VtZW50KS4gPC9zcGFuPg0KPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkxldCB1 cyBhc3N1bWUgdGhhdCBCR1AtQzEgZG9lcyBub3Qgc3VwcG9ydCBleHRlbmRlZCBtZXNzYWdlcywg YW5kICZuYnNwO0JHUC1DMiBhbmQgQkdQLUMzIGRvIHN1cHBvcnQgZXh0ZW5kZWQgbWVzc2FnZXMu DQo8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SWYgdGhlIHBvbGljeSBpbiBSUiBhY2NlcHRzIGEgdG90YWwgcGF0aCBs ZW5ndGggb2YgMTAwMCBsYXJnZSBjb21tdW5pdGllcyB3aXRoICZuYnNwO2Egc2luZ2xlIE5MUkks IGl0IG1heSBzZW5kIHRoZSBCR1AgYXR0cmlidXRlIHZpYSBleHRlbmRlZCBjb21tdW5pdGllcw0K IHRvIEJHUC1DMiBhbmQgQkdQLUMyLjwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhl IHBvbGljeSBpbiB0aGUgUlIgbXVzdCBzcGVjaWZ5IHdoZXRoZXI6DQo8L3NwYW4+PC9pPjwvYj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNzE1Mjk3ODc1OTEwNjgyODY1bXNvbGlz dHBhcmFncmFwaCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmEpPC9zcGFuPjwv aT48L2I+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPnRo ZSDigJx0b28gbG9uZ+KAnSBhdHRyaWJ1dGUgcGF0aCBsZW5ndGggbXVzdCBiZSBkcm9wcGVkLCBv cg0KPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTcxNTI5 Nzg3NTkxMDY4Mjg2NW1zb2xpc3RwYXJhZ3JhcGgiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5iKTwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj50aGUgQkdQIGF0dHJpYnV0ZSBwYXRoIGNhbiBiZSB0cnVuY2F0ZWQu IDwvc3Bhbj4NCjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgYSBwb2xpY3kgaXNzdWUgd2l0aGluIHRoZSBCR1AgcGVl ciBhbmQgdGhlIG5ldHdvcmsgb3BlcmF0aW9uIHN0YWZmLiZuYnNwOyBFYWNoIG9wZXJhdG9yIG1h eSBjaG9vc2UgdG8gd3JpdGUgdGhpcyBwb2xpY3kgZGlmZmVyZW50bHkuDQo8L3NwYW4+PC9pPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ UmF0aGVyIHRoYW4gc3BlY2lmeSB0aGUgbnVtZXJvdXMgY2FzZXMgaW4gdGhlIHByb3RvY29sIHNw ZWNpZmljYXRpb24sICZuYnNwO3RoZSBwcmV2aW91cyBkaXNjdXNzaW9ucyAocHJpdmF0ZSBhbmQg cHVibGljKSBhc2tlZCB1cyB0byB0cmltIHRoaXMgaW5mb3JtYXRpb24NCiBvdXQgb2YgdGhlIHBy b3RvY29sIHNwZWNpZmljYXRpb24uIDwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZiB5b3UgYmVsaWV2ZSB0aGlzIGlz IHdvcnRoeSBvZiBhIHVzZSBjYXNlIGRyYWZ0IGZvciB0aGUgc2FrZSBvZiBCRVNTLCBMU1ZSLCBT UFJJTkcsIEdyb3cgYW5kIG90aGVycywgSSB3aWxsIGhhcHBpbHkgV0cgY2hhaXIgc3BvbnNvciBh IGRyYWZ0DQogdGhhdCBjYW4gYmUgcmV2aWV3ZWQgYnkgYWxsIHRoZXNlIFdHcy4gPC9zcGFuPjwv aT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+4oCTIHNvIEkgZG8gbm90IGJlbGll dmUgYWRkaW5nIHRoZXNlIGZhY3RzIHRvIFJhbmR54oCZcyBkcmFmdCBpcyB1c2VmdWwuJm5ic3A7 IEluIGZhY3QsIGluIHRoZSBwcmV2aW91cyByb3VuZHMgb2YgcmV2aWV3IHRoaXMgcG9pbnQgd2Fz IG1hZGUuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5Zb3VyIHF1ZXN0aW9uIChhbmQgcGVyaGFwcyBKYWtvYuKAmXMpIGlzIHdo ZXRoZXIgd2UgaGF2ZSByZWFjaGVkIGEgdGltZS9wbGFjZSB3aGVyZSB0aGUg4oCcY2h1bmtpbmfi gJ0gYXBwcm9hY2ggd2lsbCBmYWlsIG9uIGEgcGVlci1ieS1wZWVyIGJhc2lzPyAmbmJzcDsmbmJz cDtUaGlzIGRyYWZ0DQogZG9lcyBub3QgbWFrZSB0aGlzIHN0YXRlbWVudC4mbmJzcDsgPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRw dCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ VGhlIHBvaW50IG9mIHRoaXMgZHJhZnQgaXMgdG8gZW5hYmxlIG1vcmUgZWZmaWNpZW50IHByb2Nl c3NpbmcgYnkgaW5jcmVhc2luZyB0aGUgbWVzc2FnZSBzaXplIGZvciBCR1AgcGVlcnMgdGhhdCBz ZW5kIGEgbG90IG9mIGRhdGEgKGUuZy4gQkdQLUxTKSAuJm5ic3A7Jm5ic3A7DQogVGhlIGNob2lj ZSB0byDigJxjaHVua+KAnSBvciBzdHJlYW0gaW4gbGFyZ2UgQkdQIG1lc3NhZ2UgaXMgYW4gaW1w bGVtZW50YXRpb24gY2hvaWNlIGZvciBhIHBhcnRpY3VsYXIgQkdQIGFwcGxpY2F0aW9uLiZuYnNw Ow0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj7C pzQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj7CpzMgc2F5cyDigJw8L3NwYW4+QSBwZWVyIHdo aWNoIGRvZXMgbm90IGFkdmVydGlzZSB0aGlzIGNhcGFiaWxpdHkgTVVTVCBOT1Qgc2VuZCBCR1A8 bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1Li40 cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDtFeHRlbmRlZCBNZXNzYWdlcywgYW5kIEJHUCBF eHRlbmRlZCBNZXNzYWdlcyBNVVNUIE5PVCBiZSBzZW50IHRvIGl0Ljwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bSSBiZWxpZXZlIHJhbmR5IGFjY2VwdGVkIHRoaXMg Y2hhbmdlIHdpdGggdGhlIGZvbGxvd2luZyB0ZXh0IGluIHZlcnNpb24gNCBbdXBjb21pbmcgYmVs b3ddXS8uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4tLS0tLS0tLS0tLS0tLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5GaW5lLiBUZXh0IGluIMKnNCBzaG91bGQg cHJvYmFibHkgYmUgYWxpZ25lZCB3aXRoIHRoZSBhYm92ZSAuLmUuZy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PTEQ6IDwvc3Bhbj5BIEJHUCBzcGVha2VyPG86cD48L286 cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBN QVkgc2VuZCBFeHRlbmRlZCBNZXNzYWdlcyB0byBpdHMgcGVlciBvbmx5IGlmIGl0IGhhcyByZWNl aXZlZCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgRXh0ZW5kZWQgTWVzc2FnZSBDYXBhYmlsaXR5IGZyb20gdGhh dCBwZWVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5ORVc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+QSBCR1Agc3BlYWtlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBNQVkgc2VuZCBFeHRlbmRl ZCBNZXNzYWdlcyB0byBpdHMgcGVlciBvbmx5IGlmIGl0IGhhcyBzZW50IGFuZCByZWNlaXZlZCB0 aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgRXh0ZW5kZWQgTWVzc2FnZSBDYXBhYmlsaXR5IHRvIGFuZCBmcm9tIHRo YXQgcGVlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPi0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPuKAnDwvc3Bhbj4mbmJzcDsmbmJzcDsgQXBwbGljYXRp b25zIGdlbmVyYXRpbmcgaW5mb3JtYXRpb24gd2hpY2ggbWlnaHQgYmUgZW5jYXBzdWxhdGVkPG86 cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHdpdGhpbiBCR1AgbWVzc2Fn ZXMgTVVTVCBsaW1pdCB0aGUgc2l6ZQ0KIG9mIHRoZWlyIHBheWxvYWQgdG8gdGFrZSB0aGU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBtYXhpbXVtIG1lc3Nh Z2Ugc2l6ZSBpbnRvIGFjY291bnQu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0OyZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBzZWUgd2hh dCBuZXcgYmVoYXZpb3IgaXMNCiBiZWVuIGRlZmluZWQgaGVyZS4gSWYgdGhlcmUgaXMgbm9uZSwg SSB3b3VsZCBzdWdnZXN0IHRvIHJlbW92ZSB0aGlzIHNlbnRlbmNlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QnJ1bm8g4oCTIHBl b3BsZSBhc2tlZCB0byBwdXQgdGhpcyB0ZXh0IGluIGFzIGFuIG9wZXJhdGlvbmFsIHdhcm5pbmcu Jm5ic3A7IEF0IHRoaXMgcG9pbnQsIEnigJltIGdvaW5nIHRvIHNheSB1bmxlc3MgdGhlcmUgaXMg aGFybSBpdCBzaG91bGQgcmVtYWluLiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0Jy dW5vXSBPSy48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4tLS0tPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQSBCR1AgYW5ub3VuY2VtZW50IHdp bGwsIGluIHRoZSBub3JtYWwNCiBjYXNlLCBwcm9wYWdhdGUgdGhyb3VnaG91dCB0aGU8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBCR1Agc3BlYWtpbmcgSW50 ZXJuZXQ7IGFuZCB0aGVyZSB3aWxsDQogdW5kb3VidGVkbHkgYmUgQkdQIHNwZWFrZXJzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgd2hpY2ggZG8gbm90IGhh dmUgdGhlIEV4dGVuZGVkIE1lc3NhZ2UNCiBjYXBhYmlsaXR5LiZuYnNwOyBUaGVyZWZvcmUsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcHV0dGluZyBhbiBh dHRyaWJ1dGUgd2hpY2ggY2FuIG5vdCBiZQ0KIGRlY29tcG9zZWQgdG8gNDA5NiBvY3RldHMgb3I8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBsZXNzIGluIGFu IEV4dGVuZGVkIE1lc3NhZ2UgaXMgYSBsaWtlbHkNCiBwYXRoIHRvIHJvdXRpbmcgZmFpbHVyZS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5UaGUgaXNzdWUgaXMgbm90IHNwZWNpZmljDQogdG8gYXR0cmlidXRlcyBiaWdnZXIgdGhh biA0MDk2IG9jdGV0cywgYnV0IHRvIEJHUCBtZXNzYWdlIHdob3NlIGxlbmd0aCBpcyBiaWdnZXIg dGhhbg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj40MDk2LCBpcnJlc3BlY3RpdmUgb2YgdGhlIHNpemUgb2Yg ZWFjaCBhdHRyaWJ1dGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+UGxlYXNlIGVsYWJvcmF0ZSBvbg0KIHdoYXQgeW91IG1lYW4gYnkgPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jmd0OyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPuKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YW4NCiBhdHRyaWJ1 dGUgd2hpY2ggY2Fubm90IGJlIGRlY29tcG9zZWQgdG8gNDA5NiBvY3RldHPigJ08L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BbiBhdHRyaWJ1dGUgd2hpY2ggY2Fubm90 IGJlIGRlY29tcG9zZWQgdG8gNDA5NiBpcyBhbiBhdHRyaWJ1dGUgd2l0aCBsZW5ndGggNjAwMCBp bnNpZGUgb2YgYSBCR1AgbWVzc2FnZSB3aGljaCByZXF1aXJlcyB0aGUgZW50aXJlIGF0dHJpYnV0 ZSB0byBiZSBpbmNsdWRlZC4mbmJzcDsNCiAmbmJzcDtObyBzdWNoIGF0dHJpYnV0ZSBleGlzdHMg dG9kYXkuJm5ic3A7ICZuYnNwO0lmIGEgc21hbGwgQkdQIHBlZXJzIGNyZWF0ZSBhIOKAnGtpbGxl ciBhcHBsaWNhdGlvbuKAnSB0aGF0IHVzZXMgYSA2MDAwIGJ5dGUgYXR0cmlidXRlLCB0aGUgcmVz dCBvZiB0aGUgSW50ZXJuZXQgZG9lcyBub3QgaGF2ZSB0byB1c2UgaXQuJm5ic3A7Jm5ic3A7IEhv d2V2ZXIsIHRoZSBwZXJzb24gZGVmaW5pbmcgdGhhdCBhdHRyaWJ1dGUgbXVzdCBjYXJlZnVsbHkg c3BlY2lmeSBpdCBtdXN0IGdvIHdpdGggRXh0ZW5kZWQNCiBCR1AgbWVzc2FnZXMuIDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bQnJ1bm9dIEkgZG9u4oCZdCB0aGlu ayB0aGF0IEkgYWdyZWUgd2l0aCB0aGlzLiBFLmcuIEkgZG9u4oCZdCBzZWUgd2hlcmUgUkZDcyAx OTk3IG9yIDgwOTIgWyhsYXJnZSljb21tdW5pdHldIGxpbWl0cyB0aGUgc2l6ZSBvZiB0aGVpciBh dHRyaWJ1dGUuIEhlbmNlDQogSSBkb27igJl0IHNlZSB3aHkgeW91IGNvdWxkIG5vdCBoYXZlLCB0 b2RheSAod2l0aCBFeHRlbmRlZCBNZXNzYWdlIHN1cHBvcnQpICwgYXR0cmlidXRlcyBsYXJnZXIg dGhhbiA0MDk2IG9jdGV0cy4gTW9zdCBwcm9iYWJseSBzYW1lIHN0YXR1cyBmb3IgdGhlIEJHUFNl YyBhdHRyaWJ1dGUgc2luY2UgdGhleSB3YW50ZWQgZm9yIG1vcmUgc3BhY2UuPC9zcGFuPjwvaT48 L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5bU3VlXTogWW91IG1ha2UgYSBnb29kIHBvaW50IGFib3V0IHRo ZSBwb3NzaWJpbGl0eSBvZiBsYXJnZSBjb21tdW5pdGllcyBub3QgbGltaXRpbmcgdGhlIHNpemUu Jm5ic3A7IEl0IGlzIHdvcnRoeSBvZiBhIGNoYW5nZSB0byBib3RoIHRoZSBsYXJnZSBjb21tdW5p dGllcw0KIGFuZCBhIGZvb3Rub3RlIGluIFJhbmR54oCZcyBzcGVjaWZpY2F0aW9uLiZuYnNwOyBI b3cgYWJvdXQgdGhlIGFkZGl0aW9uIG9mIGEgc2luZ2xlIHNlbnRlbmNlIHRvIHBvaW50IHBlb3Bs ZSBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uLg0KPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5PbGQvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgQkdQIGFu bm91bmNlbWVudCB3aWxsLCBpbiB0aGUgbm9ybWFsIGNhc2UsIHByb3BhZ2F0ZSB0aHJvdWdob3V0 IHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBCR1Agc3BlYWtpbmcgSW50ZXJuZXQ7IGFuZCB0 aGVyZSB3aWxsIHVuZG91YnRlZGx5IGJlIEJHUCBzcGVha2Vyczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyB3aGljaCBkbyBub3QgaGF2ZSB0aGUgRXh0ZW5kZWQgTWVzc2FnZSBjYXBhYmlsaXR5LiZu YnNwOyBUaGVyZWZvcmUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHB1dHRpbmcgYW4gYXR0cmli dXRlIHdoaWNoIGNhbiBub3QgYmUgZGVjb21wb3NlZCB0byA0MDk2IG9jdGV0cyBvcjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBsZXNzIGluIGFuIEV4dGVuZGVkIE1lc3NhZ2UgaXMgYSBsaWtlbHkg cGF0aCB0byByb3V0aW5nIGZhaWx1cmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Lzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk5ldy88L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgQSBCR1AgYW5ub3VuY2VtZW50IHdpbGwsIGluIHRoZSBub3Jt YWwgY2FzZSwgcHJvcGFnYXRlIHRocm91Z2hvdXQgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IEJHUCBzcGVha2luZyBJbnRlcm5ldDsgYW5kIHRoZXJlIHdpbGwgdW5kb3VidGVkbHkgYmUgQkdQ IHNwZWFrZXJzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHdoaWNoIGRvIG5vdCBoYXZlIHRoZSBF eHRlbmRlZCBNZXNzYWdlIGNhcGFiaWxpdHkuJm5ic3A7IFRoZXJlZm9yZSw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgcHV0dGluZyBhbiBhdHRyaWJ1dGUgd2hpY2ggY2Fubm90IGJlIGRlY29tcG9z ZWQgdG8gNDA5NiBvY3RldHMgb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbGVzcyBpbiBhbiBF eHRlbmRlZCBNZXNzYWdlIGlzIGEgbGlrZWx5IHBhdGggdG8gcm91dGluZyBmYWlsdXJlLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBPbmUgZXhhbXBsZSBvZiBhIHZhbGlkIGF0dHJpYnV0ZSB3aGlj aCBjYW5ub3QgYmUgcHJlY2lzZWx5IGRlY29tcG9zZWQgaWYgaXQNCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwO3NlbnQgaW4gRXh0ZW5kZWQgbWVzc2FnZSBpcyBhIGxhcmdlIGNvbW11bml0 eSBhdHRyaWJ1dGUgd2l0aCAxMDAwIGNvbW11bml0aWVzLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7KDEyLDAwMCBieXRlcykuJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4vPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoaXMgdGV4dCB3YXMgYWRkZWQgZHVyaW5nIGFu IGVhcmxpZXIgZGlzY3Vzc2lvbiB3aGVyZSB0aGUgZXJyb3IgY2FzZXMgb2YgYSBsYXJnZSBCR1Ag YXR0cmlidXRlIHdhcyBnaXZlbi4mbmJzcDsgVGhlIG9yaWdpbmF0b3Igb2YgdGhlIGNvbW1vbiBj b3VsZCBub3QgcHJvdmlkZSB0aGUgZXhhY3QgZGVzY3JpcHRpb24sIGJ1dCB3ZSBhZ3JlZWQgdG8g cHV0IHRoaXMgJm5ic3A74oCcd2FybmluZyBsYWJlbOKAnSBpbnRvIHRoZQ0KIGRyYWZ0LiZuYnNw OyZuYnNwOyBUaGlzIGlzIG9uZSBvZiB0aGUgY2FzZXMgd2hlcmUgYWRkaW5nL3JlbW92aW5nIHRl eHQgZ2V0cyB0byBiZSBwcm9ibGVtYXRpYy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m Z3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPi0tLTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCcJm5ic3A7Jm5ic3A7IEl0 IGlzIFJFQ09NTUVOREVEIHRoYXQgQkdQIHByb3RvY29sIGRldmVsb3BlcnMgYW5kIGltcGxlbWVu dGVycyBhcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyBjb25zZXJ2YXRpdmUgaW4gdGhlaXIgYXBwbGljYXRpb24gYW5k IHVzZSBvZiBFeHRlbmRlZCBNZXNzYWdlcy7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgZG9lcyB0aGlz IG1lYW4gZXhhY3RseT8gVGhhdCB0aGV5IGRvbuKAmXQgdXNlIHRoaXMgZXh0ZW5zaW9uPw0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1 LjRwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0O1Q8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+aGF0IHRoZXkgZG9u4oCZdCB1c2UgdGhpcyBleHRlbnNpb24gdW5sZXNzIFhYX1RPIEJF IFNQRUNJRklFRF9YWD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGlzIHdhcm5pbmcgd2Fz IHRleHQgdGhhdCBvdGhlciBwYXJ0aWNpcGFudHMgYXNrZWQgdG8gYmUgYWRkZWQuDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0 Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5JdCBpcyBhIGNvbW1vbiBzZW5zZSB3YXJuaW5nLiZuYnNwOyBF eHRlbmRlZCBtZXNzYWdlcyBhcmUgZW5hYmxlZCBvbiBhIHBlZXIgYnkgcGVlciBiYXNpcyBhcyBh bGwgQkdQIGNhcGFiaWxpdGllcyBhcmUuJm5ic3A7IElmIHlvdSBydW4gaW50byBhIFBlZXIgdGhh dCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBsYXJnZXIgc2l6ZXMsIHRoZSBCR1AgbWVzc2FnZXMgd2ls bCBuZWVkIHRvIGJlIHJlZm9ybWF0dGVkIHRvIHRoZQ0KIHNtYWxsZXIgc2l6ZS4mbmJzcDsgJm5i c3A7UnVubmluZyBpbW1lZGlhdGVseSB0byB0aGUgRXh0ZW5kZWQgbWVzc2FnZXMgYXMgdGhlIGRl ZmF1bHQgY291bGQgY2F1c2UgcHJvYmxlbXMuLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltCcnVub10gSSB0aGlu ayB0aGF0IHRoZSBzZW50ZW5jZSBjb3VsZCBiZSBlbGFib3JhdGVkLiBJbmRpY2F0aW5nIHRoZSBw cm9ibGVtLCBob3cgdGhlIHNwZWNpZmljYXRpb24gcGFydGlhbGx5IGFkZHJlc3MgaXQsIGFuZCBo b3cgdGhlIHNwZWNpZmljYXRpb24NCiBkb2VzIG5vdCBhZGRyZXNzIGl0Ljwvc3Bhbj48L2k+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SW4g4oCcUnVubmluZyBpbW1lZGlhdGVseSB0byBFeHRlbmRlZCBN ZXNzYWdl4oCdIEkgZG9u4oCZdCB0aGluayB0aGV5IHRoYXQgdGhlIGlzc3VlIGlzIHdpdGgg4oCc aW1tZWRpYXRlbHnigJ0uIFdoZW5ldmVyIHlvdSBzdGFydCB0aGUgdHJhbnNpdGlvbiwgeW91ciBs aWtlbHkNCiB0byBydW4gaW50byBwcm9ibGVtcy48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwv aT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bU3VlXTogSU1ITyBzcGVjaWZpY2F0aW9uIHNwZWNpZmll cyBob3cgdG8gZW5jb2RlIHRoZSBieXRlcyBvbiB0aGUgd2lyZSBhbmQgdGhlIGFwcHJvcHJpYXRl IGVycm9yIGhhbmRsaW5nIG9mIHRoZSBtZXNzYWdlcy4mbmJzcDsgJm5ic3A7SWYgSSBoYXZlIG1p c3NlZA0KIHNvbWV0aGluZyBpbiB0aGlzIGNhc2UsIHBsZWFzZSBsZXQgbWUga25vdy4gPC9zcGFu PjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPlRoZSBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IHNwZWNpZnkgdGhlIG5lY2Vzc2FyeSBw b2xpY2llcyBpbXBsZW1lbnRhdGlvbiBzaG91bGQgaGF2ZSBpbiBvcmRlciB0byBkZWNpZGUgd2hh dCB0byBkbyBpbiB0aGUgY2FzZSBvZiBtaXhlZCBuZXR3b3JrLiZuYnNwOw0KICZuYnNwO1RoZSBj bGVhciBpbmRpY2F0aW9uIHdhcyB0aGlzIHR5cGUgd2FzIG5vdCBhcHByb3ByaWF0ZSBmb3IgdGhl IHByb3RvY29sIHNwZWNpZmljYXRpb24uICZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FYXJsaWVyIGRpc2N1 c3Npb24gaW5kaWNhdGVkIHRoYXQgdGhlc2UgaXMgcG9saWN5IGFuZCBtZWNoYW5pc20gc3BlY2lm aWMuJm5ic3A7IEl0IGlzIHdvcnRoeSBvZiDigJx1c2UgY2FzZSBvciBhcHBsaWNhdGlvbiBub3Rl c+KAnSB3cml0dGVuIGZvciBzcGVjaWZpYw0KIGFwcGxpY2F0aW9ucyAoQkVTUywgU1BSSU5HLCBH Uk9XKSwgYnV0IG5vdCBpbiB0aGUgc3BlY2lmaWNhdGlvbi4mbmJzcDsgQWdhaW4sIGlmIGl0IGlz IHNpZ25pZmljYW50IGVub3VnaCBjb25jZXJuIGZvciBvcGVyYXRvcnMgYW5kIGltcGxlbWVudGVy cyDigJMgaXQgd291bGQgYmUgd29ydGh5IHRvIGhhdmUgY29tYmluZWQgdXNlIGNhc2UgZG9jdW1l bnQgYmVzaWRlcyB0aGlzIHBvaW50LiAmbmJzcDsmbmJzcDsmbmJzcDtJ4oCZbSBoYXBweSB0byBz cG9uc29yIGNyb3NzLWFyZWEgd29yaw0KIG9uIHRoaXMgdXNlIGNhc2UuIDwvc3Bhbj48L2k+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPi0tLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBGdXR1cmUgcHJvdG9j b2wgc3BlY2lmaWNhdGlvbnMgd2lsbCBuZWVkIHRvIGRlc2NyaWJlIGhvdyB0byBoYW5kbGU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUu NHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcGVlcnMgd2hpY2ggY2FuIG9ubHkgYWNjb21t b2RhdGUgNDA5NiBvY3RldCBtZXNzYWdlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldoeSBpcyB0aGlzIGxpbWl0ZWQgdG8gZnV0dXJlIHNwZWNp ZmljYXRpb25zPyBBIHByaW9yaSwgdXNpbmcgZXhpc3RpbmcgQkdQIG1lY2hhbmlzbSAoQUZJL1NB RkksIGF0dHJpYnV0ZXMsICoNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFu PmNvbW11bml0aWVzKSBvbmUgY291bGQgZXhjZWVkIHRoZSBzaXplIG9mIDQwOTYgb2N0ZXRzLiBI b3cgZG9lcyB0aGUgQkdQIHNwZWFrZXIgc3VwcG9zZWQgdG8gYmVoYXZlIGluIHRoaXMNCjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4/Jmd0Ozwvc3Bhbj5jYXNlPyBUaGlzIHNob3VsZCBiZSBk ZXNjcmliZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiBOb3RlIHRoYXQgdGhpcyBpcyBub3QgYSBj YXNlIG9mIGVycm9yIGhhbmRsaW5nLCBhcyBldmVyeSBCR1ANCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPnNwZWFrZXIgaXMg YmVoYXZpbmcgYXMgc3BlY2lmaWVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgZmFpbCB0 byBzZWUgeW91ciBsb2dpYy4mbmJzcDsgQXQgdGhpcyBwb2ludCwgYWxsIEJHUCBkYXRhIChBRkkv U0FGSSBhbmQgYXR0cmlidXRlcykgbXVzdCBmaXQgd2l0aGluIGEgNDA5NiBtZXNzYWdlLiZuYnNw OyAmbmJzcDtUaGVyZWZvcmUsIGEgQkdQIHBlZXIgQSB3aGljaCBjb25uZWN0cyBvbiBsaW5rIDEg dG8gQkdQIHBlZXIgQiB3aXRoIDQwOTYgbWVzc2FnZSBhbmQgb24gbGluayB0byBhIEJHUCBwZWVy IEMgd2l0aA0KIGV4dGVuZGVkIG1lc3NhZ2VzIG9ubHkgaGFzIHRvIHdvcnJ5IGFib3V0IHJlZm9y bWF0dGluZyB0aGUgZGF0YS4mbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SW4gdGhl IGZ1dHVyZSwgdGhlIGZpcnN0IGdyb3VwIHRoYXQgZGVmaW5lcyBhdHRyaWJ1dGUgb3IgYW4gTkxS SSB0aGF0IGRvZXMgbm90IGZpdCB3aXRoaW4gYSA0MDk2IEJHUCBtZXNzYWdlIGFuZCBjYW5ub3Qg YmUgc3BsaXQsIHdpbGwgbmVlZCB0byBkZWZpbmUgaG93IHRoYXQgd29ya3MgaW4gdGhlIHNwZWNp ZmljYXRpb24uJm5ic3A7IFRoZXJlIGlzIG5vIG5lZWQgdG8gcmVmaW5lIHRoZSBjdXJyZW50IHNl dA0KIG9mIHNwZWNpZmljYXRpb25zLiZuYnNwOyZuYnNwOyA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5bQnJ1bm9dPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4xKSBjZiBhYm92ZSwgSSBi ZWxpZXZlIHRoYXQgdGhlcmUgYXJlIGV4aXN0aW5nIEJHUCBBdHRyaWJ1dGVzIHdoaWNoIG1heSBu b3QgZml0IGludG8gYSBieXRlcyA0MDk2IEJHUCBtZXNzYWdlPC9zcGFuPjwvaT48L2I+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4yKUV2ZW4gaW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCBhdHRyaWJ1dGUsIHlvdSBo YXZlIHRoZSBpc3N1ZSBvZiAyIHNtYWxsZXIgYXR0cmlidXRlcyB3aG9zZSBjdW11bGF0aXZlIHNp emUgZG9lcyBub3QgZml0IGludG8gYSA0MDk2IGJ5dGVzIG1lc3NhZ2UuPC9zcGFuPjwvaT48L2I+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRo ZSBwcm9ibGVtIGlzIGludHJvZHVjZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uLCBoZW5jZSBJIGJl bGlldmUgdGhpcyBzcGVjaWZpY2F0aW9uIG5lZWRzIHRvIHNwZWNpZnkgaG93IHRvIGhhbmRsZSB0 aGlzIGNhc2UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5bU3VlXTogJm5ic3A7SUhNTyB0aGUgbWVzc2FnZSB0cmFuc21pc3Npb24gYW5kIHJlY2VwdGlv biBlcnJvciBoYW5kbGluZyBpc3N1ZXMgYXJlIGNvbXBsZXRlIGluIHRoZSBjb21iaW5hdGlvbiBv ZiBSRkM0MjcxIGFuZCB0aGUgZXh0ZW5kZWQgbWVzc2FnZSBzZWN0aW9uDQogNS4gPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2hhdCBpcyBub3QgaW4gdGhpcyBzcGVj aWZpY2F0aW9uIGlzIHRoZSBwb2xpY3kgaXNzdWVzIGFib3V0IHdoYXQgaGFwcGVucyBpZiB5b3Ug Y29tYmluZSAyIHNtYWxsZXIgYXR0cmlidXRlcy4mbmJzcDsgRm9yIGV4YW1wbGUsIGlmIHlvdSBo YXZlIGEgbGFyZ2UgY29tbXVuaXR5DQogYXR0cmlidXRlIG9mIDQwMCBjb21tdW5pdGllcyAoNDgw MCBieXRlcyksIHlvdSB3aWxsIGxpa2VseSBydW4gaW50byBwcm9ibGVtcyB3aGVuIGNvbWJpbmlu ZyB3aXRoIHNvbWUgbG9uZ2VyIEFTIHBhdGggbGVuZ3Rocy4mbmJzcDsgWzQ4MDA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DoDwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+IDUwOTYgYnl0ZXMgaXMgYSBzaG9ydCBqdW1wXS4g UGVvcGxlDQogb24gdGhlIGxpc3QgYW5kIGluLXBlcnNvbiBhcmd1ZWQgdGhpcyB3YXMgcG9saWN5 IGFuZCBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBkZXRhaWxzLiZuYnNwOw0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGl0IGlz IGV4dHJlbWVseSB1c2VmdWwgdG8gdGhlIG9wZXJhdG9yIGNvbW11bml0eSB0byBoYXZlIHRoaXMg dHlwZSBvZiBwb2xpY3kgZGV0YWlscyBkaXNjdXNzZWQgdG8gc2VlIGlmIHRoZXJlIGlzIHNvbWUg ZGVzaXJlIHRvDQogaGF2ZSBjb21tb24gcG9saWNpZXMgYW5kIGVycm9yIGNvbW11bml0aWVzLiAm bmJzcDsmbmJzcDtJdCBpcyB0aGUgdHlwZSBvZiB0aGluZyB0aGF0IEdST1cgYW5kIElEUiBzaG91 bGQgYmUgZGVlcGx5IGludm9sdmVkIGZvciBsYXJnZSBjb21tdW5pdGllcy4mbmJzcDsgJm5ic3A7 QkVTUywgTFNWUiwgU1BSSU5HIGFuZCBvdGhlcnMgc2hvdWxkIGNvbnNpZGVyIHdoYXQgcG9saWN5 IHNob3VsZCBiZSBhZGFwdGVkIGZvciB0aGVpciBhcHBsaWNhdGlvbnMuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4tLS0t PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+RGVwZW5kaW5nIG9uIHRoZSBhYm92ZSBzcGVjaWZpY2F0aW9u LCBhIHNlY3Rpb24gZGVzY3JpYmluZyB0aGUgb3BlcmF0aW9uYWwgY29uc2VxdWVuY2VzIGluIGEg bmV0d29yaw0KIChzdWNoIGFzIHRoZSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkludGVybmV0LCBCR1AgRW5h YmxlZCBTZXJ2aWNlUy9WUE4gbmV0d29ya3MpIGlzIHByb2JhYmx5IG5lZWRlZC4gUG9zc2libGUg Y29uc2VxdWVuY2VzDQogY291bGQgYmUgQkdQIE5MUkkgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5iZWluZyBy ZW1vdmVkIGluIHRoZSBtaWRkbGUgb2Ygc3VjaCBuZXR3b3JrLCBvciAoZXh0ZW5kZWQpIGNvbW11 bml0eSAoc3VjaA0KIGFzIFJvdXRlIFRhcmdldHMpIGJlZW4gcmVtb3ZlZC4gPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5Cb3RoIGhhdmluZyBzaWduaWZpY2FudCBjb25zZXF1ZW5jZXMgb24gdGhlIGF2YWlsYWJp bGl0eSBwcm92aWRlZA0KIGJ5IHRoZSBuZXR3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkF0IHRoaXMgcG9pbnQsIHRoZXJlIGFyZSBubyBhdHRyaWJ1dGVzIG9yIE5MUkkgZ3JvdXBpbmdz IHRoYXQgZG8gbm90IGZpdCB3aXRoaW4gNDA5Ni4mbmJzcDsgJm5ic3A7SWYgeW91IGRlZmluZSBv bmUgKGFzIFNJRFIgZGlkKSwgdGhlbiB5b3Ugd2lsbCBuZWVkIHRvIGhhdmUgaXQgcmV2aWV3ZWQg YnkgSURSLCBCRVNTLCBTUFJJTkcsIGFuZCBvcGVyYXRpb25hbCBncm91cHMgKEdST1csIGV0Yyku Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0JydW5vXSBubywgY2YgYWJvdmUuPC9zcGFu PjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bU3VlXTogJm5ic3A7VGhhbmsgeW91IGZvciByZW1p bmRpbmcgbWUgb2YgdGhlIHBvdGVudGlhbCBvZiBsYXJnZSBjb21tdW5pdGllcyB0byBibG93IHVw IEJHUC4mbmJzcDsgSSBoYXZlIGEgbmV3IHdvcnJ5IHRvIGFkZCB0byBteSBCR1AgY29uY2VybnMg bGlzdCENCjwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvaT48 L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4tLUJydW5vPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+wqc0 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5P TEQ6IFRoZSBFeHRlbmRlZCBNZXNzYWdlIENhcGFiaWxpdHkgb25seSBhcHBsaWVzIHRvIGFsbCBt ZXNzYWdlcyBleGNlcHQgZm9yIHRoZQ0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8 L3NwYW4+T1BFTiBtZXNzYWdlLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZn dDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPlByb2JhYmx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5ORVc6IFRoZSBFeHRlbmRlZCBNZXNzYWdlIENhcGFi aWxpdHkgYXBwbGllcyB0byBhbGwgbWVzc2FnZSB0eXBlcyBleGNlcHQgZm9yIHRoZQ0KPHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+T1BFTiBtZXNzYWdlICh0eXBlIDEpLiA8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0t LS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PsKnODwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+4oCcVGhpcyBleHRlbnNp b24gdG8gQkdQIGRvZXMgbm90IGNoYW5nZSBCR1AncyB1bmRlcmx5aW5nIHNlY3VyaXR5IGlzc3Vl cyZuYnNwO8K7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+QmVmb3JlIGV2YWx1YXRp bmcgdGhpcywgSSB0aGluayB0aGlzIGRvY3VtZW50IHNob3VsZCBmaXJzdCBzcGVjaWZpZWQgaG93 IGEgQkdQIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPm1lc3NhZ2VzIGJpZ2dlciB0 aGFuIDQwOTYgb2N0ZXRzIGlzIGhhbmRsZWQgd2hlbiBpdCBuZWVkcyB0byBiZSBzZW50IHRvIGEg PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+cmVjZWl2ZWQgbm90IHN1cHBvcnRp bmcgdGhpcyBleHRlbnNpb24uPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Tml0czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9MRCZuYnNwOzogdG8gcmVkdWNlIGNvbXBleGl0eTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz NS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TkVX Jm5ic3A7OiB0byByZWR1Y2UgY29tcGxleGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz NS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhhbmtzLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LS1CcnVubzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IElkciBbPGEgaHJl Zj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmlk ci1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3VzYW4gSGFyZXM8 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAyOSwgMjAxOSAxMjozMyBQTTxicj4N CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pZHJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtJZHJdIFdHIExhc3QgQ2Fs bCBvbiBFeHRlbmVkIE1lc3NhZ2UgU3VwcG9ydDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxz cGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhpcyBiZWdpbnMg YSAyIHdlZWsgV0cgTEMgb24gRXh0ZW5kZWQgTWVzc2FnZSBTdXBwb3J0IGZvciBCR1AgKGRyYWZ0 LWlldGYtaWRyLWJncC1leHRlbmRlZC1tZXNzYWdlcy0yNykuJm5ic3A7IFlvdSBjYW4gYWNjZXNz IHRoZSBkcmFmdCBhdDoNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjM1LjRwdCI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWlkci1iZ3AtZXh0ZW5kZWQtbWVzc2FnZXMvIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1p ZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhl IGF1dGhvcnMgc2hvdWxkIGluZGljYXRlIHdoZXRoZXIgdGhleSBrbm93IG9mIGFueSBJUFIuJm5i c3A7Jm5ic3A7IEltcGxlbWVudGVycyBhcmUgZW5jb3VyYWdlZCB0byB1cGRhdGUgdGhlJm5ic3A7 IGltcGxlbWVudGF0aW9uIGRhdGEgYXQ6DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwLWV4dGVuZGVkLWltcGxlbWVudGF0aW9ucyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L2lkci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRlZC1pbXBsZW1lbnRhdGlvbnM8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBkcmFmdCBwcm92aWRlcyBhIG1lYW5zIGZvciBl eHBhbmRpbmcgdGhlIEJHUCBtZXNzYWdlIHRvIDY1NTM1IG9jdGV0cyBmb3IgYWxsIG1lc3NhZ2Vz IGV4Y2VwdCBPUEVOIG1lc3NhZ2VzLiZuYnNwOyBCR1AgbWVzc2FnZSBzcGFjZSBpcyBydW5uaW5n IHNob3J0IGZvciBhbGwgb2YgdGhlIHBvdGVudGlhbCBhdHRyaWJ1dGVzDQogb3IgYWRkaXRpb25z IHByb3Bvc2VkIGJ5IEJHUC1MUyBmZWF0dXJlcy4mbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPlRoZSBXRyBjaGFpcnMgaW50ZW5kIHRvIGZvcndhcmQgdGhpcyBkcmFmdCB0byB0aGUgSUVT RyB3aXRoIHRoZSBjdXJyZW50IGxldmVsIG9mIGltcGxlbWVudGF0aW9uLiZuYnNwOw0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRw dCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkFzIHlvdSBjb21tZW50IG9uIHRoZSBkcmFmdCwgcGxlYXNlIGNv bnNpZGVyIGlmOiBhKSB0aGUgdGVjaG5vbG9neSBpcyBtYXR1cmUsIGIpIHRoZSBhZGRpdGlvbmFs IHNwYWNlIGluIGEgQkdQIG1lc3NhZ2Ugd291bGQgYmUgaGVscGZ1bCBmb3IgdGhvc2UgZGVwbG95 aW5nIEJHUC1MUyBvciBTUiwgYW5kIGMpIGlmIHRoZQ0KIHNwZWNpZmljYXRpb24gaXMgcmVhZHkg Zm9yIHB1YmxpY2F0aW9uLiZuYnNwOyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3VlIEhhcmVz IChXRyBDaGFpciwgU2hlcGhlcmQpDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNS40cHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZh bWlseTpDb25zb2xhcyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5 OkNvbnNvbGFzIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTpDb25z b2xhcyI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNS40cHQiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40 cHQiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPk9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTpD b25zb2xhcyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29s YXMiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40 cHQiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUu NHB0Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzIj5JZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+QXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt ZmFtaWx5OkNvbnNvbGFzIj5UaGFuayB5b3UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp dj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRw dCI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9 IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiPk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBs YW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJGUiI+SWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFu IGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40 cHQiPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkZSIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRlIiPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0 IG5lIGRvaXZlbnQgZG9uYzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJGUiI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXI8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi PmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRlIiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkZSIj50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRlIiPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhhbmsgeW91Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWRyIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5J ZHJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZHIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR11MB2050623467364B68264208D6C0610BN6PR11MB2050namp_-- From nobody Tue Feb 19 16:40:02 2019 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F691277CC; Tue, 19 Feb 2019 16:39:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <155062319323.20730.10418140109717672958@ietfa.amsl.com> Date: Tue, 19 Feb 2019 16:39:53 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-msd-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 00:39:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State Authors : Jeff Tantsura Uma Chunduri Greg Mirsky Siva Sivabalan Nikos Triantafillis Filename : draft-ietf-idr-bgp-ls-segment-routing-msd-03.txt Pages : 7 Date : 2019-02-19 Abstract: This document defines a way for a Border Gateway Protocol Link-State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow logically centralized entities (e.g., centralized controllers) to determine whether a particular SID stack can be supported in a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-03 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-msd-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-msd-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 19 16:51:04 2019 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2005D130E25; Tue, 19 Feb 2019 16:50:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <155062385607.20612.12949942163605730618@ietfa.amsl.com> Date: Tue, 19 Feb 2019 16:50:56 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-msd-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 00:50:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State Authors : Jeff Tantsura Uma Chunduri Greg Mirsky Siva Sivabalan Nikos Triantafillis Filename : draft-ietf-idr-bgp-ls-segment-routing-msd-04.txt Pages : 7 Date : 2019-02-19 Abstract: This document defines a way for a Border Gateway Protocol Link-State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow logically centralized entities (e.g., centralized controllers) to determine whether a particular SID stack can be supported in a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-04 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-msd-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-msd-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 21 07:24:39 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80108130EA3 for ; Thu, 21 Feb 2019 07:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRVvZtdAz7xr for ; Thu, 21 Feb 2019 07:24:29 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38BE130DE3 for ; Thu, 21 Feb 2019 07:24:28 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.248.72; From: "Susan Hares" To: Cc: , "'Robert Raszuk'" References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk> <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> <17281_1550132953_5C6526D9_17281_161_1_53C29892C857584299CBF5D05346208A489D3D92@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <00c901d4c489$8f311830$ad934890$@ndzh.com> <31634_1550226311_5C669387_31634_352_1_53C29892C857584299CBF5D05346208A489D6640@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <31634_1550226311_5C669387_31634_352_1_53C29892C857584299CBF5D05346208A489D6640@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Date: Thu, 21 Feb 2019 10:24:22 -0500 Message-ID: <021401d4c9f9$8629c0f0$927d42d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0215_01D4C9CF.9D5E4040" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rAefZHwsB7dxHTgI7AvBBAac2MMMBU1Q3bAF8mWGhpD/wQyA= Content-Language: en-us X-Antivirus: AVG (VPS 190221-0, 02/21/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 15:24:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0215_01D4C9CF.9D5E4040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno:=20 =20 Thank you for your specific suggestion. It helps us work through the specifics of the changes to the BGP specification. I do not see the = text in draft-ietf-idr-bgp-extended-messages-28.txt changing section 6.3 of RFC4271. I=92ve included my understanding of how draft-ietf-idr-bgp-extended-messages-28.txt changes RFC4271 in the = detailed comments below. =20 =20 Your suggestion to improve section 6.3 of RFC4271 to handle the case = where a BGP speaker peers with two different messages sizes (4096, 65,535) has operational merit. Would you mind this modification to you text: =20 =93A BGP speaker which peers with some peers with extended message = capability and other peers without extended message capability, MUST do both of the following things:=20 - The BGP speaker MUST support [RFC7606], and=20 - The BGP speaker MUST handle a BGP Route (attribute, NLRI = pair) that is too large to be sent to a BGP peer without the extended message capability using the =93treat-as-withdraw=94 approach defined in = [RFC7606]. =20 The BGP speaker, MAY remove some BGP attributes which are eligible to = use the Attribute discard approach [RFC7606]. =93 =20 =20 This would be added to section 5 of = draft-idr-bgp-extended-messages-25.txt. See my suggested RFC4271 text changes for a logical placement within RFC4271. =20 =20 If this change to your text is agreeable, then section 8 would need to change to: =20 /New text for the end of section 8/=20 =20 This draft requires support for RFC7606 update error handling and as = such inherits the security considerations of RFC7606. This draft also = recommends BGP peers avoid such issues by using Authenticated Encryption with additional Data (AEAD) ciphers [RFC5116] and thus to discard messages = that do not verify. It also recommends that IBGP peers all support extended message capability and [RFC7606]. =20 =20 During the transition to deploy extended messages and RFC7606 on an IBGP cloud, operators should monitor any routes dropped as =93treat as = withdraw=94. =20 =20 One example of a RFC7606 attack profile using the extended message is if = the remote attacker is able that to craft a large BGP route to send along a = BGP path in which at least one peer does not support extended messages. This peer which does not support extended message capability may encounter a drain on internal resources (processing, message sizes) if it = continually reformats the large messages. If the =93treat as withdraw=94 feature of = RFC7606 is utilized, some routes may be consistently withdrawn at this point = causing inconsistent routing. =20 =20 BGP routes are filtered by policies set by the operators. = Implementations may provide policies to filter routes that would cause the =93treat as withdraw=94 from being pass by an extended message speaker. =20 /=20 =20 Please let me know I understand your suggested changes.=20 =20 Sue Hares=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com Sent: Friday, February 15, 2019 5:25 AM To: Susan Hares Cc: idr@ietf.org; Robert Raszuk Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Susan, =20 We now agree that the problem can happen with existing BGP attributes. = Good. So the argument to postpone the error handling discussion for future specification defining large attributes does not hold anymore. =20 Coming back to the draft, =20 Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. =20 1) As a minor comment, the error is not limited to an (one single) attribute (type) which size is bigger than 4096 octets. The error = happens when the Total Path Attribute Length (for all attributes) is bigger than 4096 octets. =20 [Sue]: My understanding of the Extended message draft is that it is not dealing with section 6.3 of RFC4271. Here=92s my understanding of the=20 =20 RFC4271 states: =20 =93All Errors detected while processing the Message header must be = indicated by sending a NOTIFICATION message with the Message Header error. The = Error subcode elaborates on the specific nature of the error. =93 =20 One of the errors is a message header length: =93If the length field of = the message header is less than 19 or greater than 4096.=94 If any of these = super large attributes causes the message length to be greater than 4096, then with RFC4271, the error code sent would be =93Bad Message length.=94 =20 If the message length is switch from 4096 to 65535 octets, the RFC4271 = error handling would allow the message length to be 65,535.=20 =20 =20 After the section 6.1 text RFC4271 is changed to the following:=20 =20 If at least one of the following is true:=20 - If the Length field of the message header is less than 19 or greater than 4096=20 for OPEN message, - If BGP Extended Messages capability is not set, the length = field of any other BGP message other than an OPEN message is less than 19 or greater than 4095,=20 =20 - If the BGP Extended Message capability is set for a BGP peer, = if the length field is less than 19 or greater than 65,535. (See the error handling below for the setting of this function.) =20 - If the length field of an UPDATE message is less than the = minimum field of the UPDATE message, or=20 =20 - If the length field of a KEEPALIVE message is not equal to = 19, or =20 - If the length field of a NOTIFICATION message is less than = the minimum length of the NOTIFICATION message.=20 =20 Then the Error Subcode MUST Be set to Bad Message Length. The Data = field MUST contain the erroneous length field.=20 [ 6.9) Extended Message Capability=20 =20 To advertise the BGP Extended Message Capability to a peer, a BGP speaker uses BGP Capabilities Advertisement [RFC5492 ]. By advertising the BGP Extended Message Capability to a peer, a BGP speaker conveys that it is able to send, receive, and properly handle BGP Extended Messages. =20 A peer which does not advertise this capability MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to it. =20 The BGP Extended Message Capability is a new BGP Capability [RFC5492 ] defined with Capability code 6 and Capability length 0. =20 6.9.1) Operation:=20 =20 A BGP speaker that is capable of sending and receiving BGP = Extended Messages SHOULD advertise the BGP Extended Message Capability to the peer using BGP Capabilities Advertisement [RFC5492 ]. A BGP speaker MAY send Extended Messages to its peer only if it has sent and received the Extended Message Capability from that peer. =20 The Extended Message Capability applies to all messages except for the OPEN message. This exception is made to reduce complexity of providing backward compatibility =20 An implementation that advertises support for BGP Extended Messages MUST be capable of receiving a message with a length up to and including 65535 octets. =20 Applications generating information which might be encapsulated within BGP messages MUST limit the size of their payload to take the maximum message size into account. =20 If a BGP update with a payload longer than 4096 octets is received by a BGP listener who has neither advertised nor agreed to accept BGP Extended Messages, the listener MUST treat this as a malformed update message, and MUST raise an UPDATE Message Error (see section 6.3).=20 =20 =20 A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. =20 It is RECOMMENDED that BGP protocol developers and implementers are conservative in their application and use of Extended Messages. =20 6.9.2 Error Handling for the Extended messages =20 A BGP speaker that has the ability to use Extended Messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, SHOULD NOT accept an Extended Message. A speaker MAY implement a more liberal policy and accept Extended Messages, even from a peer to which it has not advertised the capability, in the interest of preserving the BGP session if at all possible. =20 A BGP speaker that does not advertise the BGP Extended Messages capability might also genuinely not support Extended Messages. Such a speaker MUST follow the error handling procedures of section 6.1=20 regarding message length. =20 =20 The inconsistency between the local and remote BGP speakers MUST be flagged to the network operator through standard operational interfaces. The information should include the NLRI and as much relevant information as reasonably possible. =20 [End of text change from draft ] =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 2) As a major comment, I am asking for the specification to specify = how it handles that failure, which is not the result of a possible bug, but created by design by the solution. It will happen. =20 Your proposition to =93raise an alarm=94 is required but not sufficient = as we still need to specify what we do with this =93big=94 route. One option = could be =93treat as withdraw=94, another option suggested by Robert is to = propagate the NLRI with subset of attributes plus an indication of the failure (=93a = short attribute BGP_PIPE_TOO_THIN=94). There may be others options. =20 [Sue]: Robert=92s option is a fine idea, but the WG did not accept this = option in the past so I cannot force this option into the specification. I = hope that Robert will propose this option again. =20 =20 To trigger the discussion on the resolution, I would propose the = following text =93One BGP Route too large to be propagated to a BGP receiver not supporting BGP Extended Message MUST be handled, over this BGP session, using the Treat-as-withdraw approach as defined in [RFC7606]. The BGP speaker MAY, beforehand, remove some BGP attributes which are eligible = to the Attribute discard approach [RFC7606].=94 =20 [Sue]: This text deals with section 6.3 in RFC4271, and to my = understanding draft-ietf-idr-bgp-extended-messges-28.txt only deals with section 6.1 = of RFC4271. In addition, there is no concept of propagation RFC7606 or RFC4271. Each BGP peer receives BGP messages and updates, it then propagates or sends routes and attributes to its peers. Could I = restate your suggestion as:=20 =20 6.9.2 Error handling=20 (added at the end of the current text =20 =20 A BGP speaker which peers with some peers with extended message = capability and other peers without extended message capability, MUST handle a BGP = Route (attribute, NLRI pair) that is too large to be sent to a BGP peer = without the extended message capability using the =93treat-as-withdraw=94 = approach defined in [RFC7606]. The BGP speaker, MAY remove some BGP attributes = which are eligible to use the Attribute discard approach [RFC7606]. =20 =20 =20 3) Once error handling is specified, the draft will be able to = discuss=20 a. the operational considerations for this issue (e.g. The one = from RFC7606 could be referenced as-is, or used as inspiration) b. the security considerations (as a remote attacker would be able = to craft a large BGP route that will be withdrawn (assuming =93treat-as-withdraw=94) somewhere in some AS, possibly creating routing inconsistencies within the AS) c. the proposed mitigations (e.g., an operator should enable = support for Extended messages on all IBGP sessions first, before enabling it on = an EBGP session; If not possible, an operator could define a policy to = filter BGP attributes from EBGP sessions, typically based on their type and size;=85.) =20 more inline [Bruno2] =20 =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Thursday, February 14, 2019 6:20 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf.org; 'Jakob Heitz (jheitz)'; 'John Scudder'; 'Alvaro = Retana' Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Bruno:=20 =20 Thank you for careful considerations on the use case. I think we have translation issues between our =93English=94 language again so I have = tried to be precise in the detailed comments. I=92ve summarized my comments as = well to help us take the next step.=20 =20 Sue=20 =20 Summary ---- Good catch on the 1000 large BGP communities blowing up the message = size! This is a case where a code path could get caught with program error. = The error handling (section 6.1 in RFC4271 per section 5 in the extended specification) IMHO handles the case where the attribute is longer than = the message. Please let me know if I=92ve missed something. =20 =20 [Bruno2] I don=92t think that section 6.1 of RFC4271 covers this. The = problem is not a Message Header error handling as a proper BGP implementation = would not sent the message. (not to mention with inconsistent size). [Sue2]: OK, but section 6.1 is the only places that this draft changes.=20 =20 As I understand it, you are asking this specification to be expanded to = add notes on policies on what implementation should do to correctly combine RFC4271 length sizes with extended length sizes. The implementers and operations people commented earlier that this should not be in the = protocol specification other than as a brief footnote. =20 =20 [Bruno2]An error handling must exist even in the absence of SP policies. = The argument related to previous discussions does not hold IMHO as I=92ve = raised a new point (this happens with existing BGP attributes, not in a = hypothetical new attribute) [Sue2]: Thank you for sending your text. I can your comments are on = the UPDATE handling processes based on RFC7606. We were discussing 2 = different places in RFC4271.=20 =20 I agree there is a need for such standardization as BCPs for particular = use cases (large communities, BESS (EVPN or centralized controller), SPRING, BGP-LS information (see Daylight comments yesterday), SD-WANs (rtgwg), = and SPRING. I think the chairs of the WGs utilizing should consider if = there is need for standardization for a minimal set of policy for message = sizes for specific use cases. I will be glad to send request to these WG or = to host something in IDR if there is policy that can be used across all use cases.=20 =20 [Bruno2] I don=92t think that Error handling is to be considered as = optional or for future consideration. [Sue2]: Based on your proposed text, I can see the value of considering this text at this time. =20 =20 To provide a slight expansion to point people in this direction, how = about this change to paragraph in section 4:=20 =20 Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed = if it=20 sent in Extended message is a large community attribute with 1000 communities.=20 (12,000 bytes). =20 / [PS =96 in American English =93Can not=94 is normally concatenated = =93cannot=94.]=20 =20 [Bruno2] Thanks for the proposition, but this does not address my = concern. [Sue]: Thank you for your text =96 I understand why now.=20 =20 From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Sent: Thursday, February 14, 2019 3:29 AM To: Susan Hares Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Sue, =20 Thanks for the reply. Please see inline [Bruno] =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Wednesday, February 13, 2019 8:03 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Bruno:=20 =20 I=92d like to answer some of the questions you sent Randy based on = comments (public and private) the chairs and I as the shepherd received on this = draft in our last WG LCs.. =20 =20 Several of the comments you questioned were put in to answer other questions. This gets into a catch-22=85 problem =96 where you put = changes in for one person/take out the changes out for another. In academic = circles this is called the reviewer #2 problem (reviewer 1 insists changes go = in, reviewer 2 insists changes go out) during publication. Therefore, I=92m = I am going to answer most of your questions where this is the case. =20 =20 I believe that Randy has new version with the changes I=92ve indicated. = I=92m hoping he=92ll just post that version. AFAILK, we do have 2 compliant implementations.=20 =20 Sue=20 =20 =20 =20 =20 This draft=92s technology provides efficient processing for some = application by allow a huge BGP message size. Whether =93chunking=94 BGP to 4096 = byte messages or packing large amounts of data into 65,000 byte message is = more effective for a particular application is something only an implementer = of a particular BGP implementation can decide. This draft simply gives = freedom for applications to not be restrict to an artificially small message = size. The market place will choose whether this technology is used or not.=20 =20 As Jakob pointed out, changing a highly tuned BGP implementation which =93chunks=94 BGP data into 4096 byte messages may involve substantial = rework of the implementation. =20 =20 =20 (snip)=20 From: Idr On Behalf Of bruno.decraene@orange..com Sent: 29 January 2019 13:33 To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Hi WG, =20 >Please find below some comments. >As of today, I don=92t believe this specification is ready to be = progressed to IESG/RFC, especially for a document >updating RFC 4271 (core BGP = spec). =20 > The WG chairs intend to forward this draft to the IESG with the = current level of implementation. =20 =20 >https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended- >implementations says : 5a=20 Does not send Extended Message capability=20 Yes=20 Yes=20 Yes=20 =20 >I may be misunderstanding the implementation report, but my reading of = the above is that none of the reported >implementations sends the capability hence no implementation supports draft-ietf-idr-bgp-extended-messages..=20 >Here this document is updating RFC 4271, so it is not a minor extension = for a niche use case. So I don=92t see the >arguments for not requiring the = IDR=92s usual two interoperable implementations. =20 >In our mail thread, we discovered that the implementation report should have indicate >full support. I=92m waiting for Olivier to update based on the last = point, but my understanding is that=20 All implementations have full support. =20 =20 [Bruno] ok, solved >---- >=A7 1 >=93 As BGP is extended to support newer AFI/SAFIs and > newer capabilities (e.g., [ I-D.ietf-sidr-bgpsec-protocol]), there is > a need to extend the maximum message size beyond 4096 octets. =93 >=20 > https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on- 1 =20 =20 >[ I-D.ietf-sidr-bgpsec-protocol is now RFC = 8205 (thanks for updating the reference). It has removed the normative/any >reference to draft-ietf-idr-bgp-extended-messages. So presumably BGP = Sec does not need draft-ietf-idr-bgp->extended-messages. Can we have an = update on this? Can the introduction of draft-ietf-idr-bgp-extended-messages = >be updated to introduce on the real reasons/needs? =20 SIDR gave up waiting on IDR=92s work and took a reduced size of = encryption. The security people were very sad about the reduction. How is this = working in practice? WG sidrops can answer this question. =20 =20 The real problem is there is finite message space. =20 [Bruno] So too bad the draft does not solve the real problem ;-) (as = message space is still limited) =20 [Sue]: The message is still finite (smile), but I hope 65,635 (smile) = is probably enough for 10 years. =20 =20 There are two ways to send lots of BGP routes and/or attributes =96 to = =93chunk=94 these into small message sizes or place these into a large message. = Some applications may always want to =93chunk=94 into message sizes smaller = than 4096. Some application make work more efficiently utilizing large = message size. As the potential number of NLRI and BGP attributes grows, new applications may consider large message sizes to a more reasonable way = to exchange amounts of BGP data. =20 =20 The decision on how to send BGP messages over the wire is a peer-by-peer decision in a network. Each BGP peer is in charge of reformatting the = BGP message it sends to the remote BGP peer. The BGP capabilities in this draft represent an agreement between two BGP peers. These are facts of basic BGP implementations [Bruno] Let=92s take the example of a BGP Route Reflector having a mixed = of clients, some supporting Extend Message (EM) and some not. >From an EM client, it receives a BGP update containing one (single) NLRI with an Total Path Attribute Length bigger than 4090 byte (e.g. having = 1000 large communitiess) Can you explain me how it behaves to send this NLRI to an IBGP peer not supporting EM? [Sue]: Gladly=85=20 A BGP route reflector (RR-A) is peering with each of its BGP clients. = It agrees with each of its clients (BGP-C1, BGPC2, BGPC3) whether the BGP Extended messages is accepted or not (based on capability announcement). = Let us assume that BGP-C1 does not support extended messages, and = BGP-C2 and BGP-C3 do support extended messages.=20 =20 If the policy in RR accepts a total path length of 1000 large = communities with a single NLRI, it may send the BGP attribute via extended = communities to BGP-C2 and BGP-C2. The policy in the RR must specify whether:=20 a) the =93too long=94 attribute path length must be dropped, or=20 b) the BGP attribute path can be truncated.=20 =20 This is a policy issue within the BGP peer and the network operation = staff. Each operator may choose to write this policy differently.=20 [Bruno2] So we agree that a new behavior is REQUIRED. The draft does not mention this. The ability to change the behavior by policy does not = remove the need for specifying the error handling. =20 Rather than specify the numerous cases in the protocol specification, = the previous discussions (private and public) asked us to trim this = information out of the protocol specification.=20 [Bruno2] Can=92t be have a general rule which is good enough to handle = the issue? Previous discussions seemed based on the fact the error condition would happen for future attribute. This is not the case. =20 If you believe this is worthy of a use case draft for the sake of BESS, LSVR, SPRING, Grow and others, I will happily WG chair sponsor a draft = that can be reviewed by all these WGs.=20 [Bruno2] I believe that this is worthy in this specification.=20 =20 =20 =96 so I do not believe adding these facts to Randy=92s draft is useful. = In fact, in the previous rounds of review this point was made.=20 =20 Your question (and perhaps Jakob=92s) is whether we have reached a = time/place where the =93chunking=94 approach will fail on a peer-by-peer basis? = This draft does not make this statement. =20 =20 The point of this draft is to enable more efficient processing by = increasing the message size for BGP peers that send a lot of data (e.g. BGP-LS) . = The choice to =93chunk=94 or stream in large BGP message is an = implementation choice for a particular BGP application. =20 =20 ---- =A74 =A73 says =93A peer which does not advertise this capability MUST NOT = send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.=94 [I believe randy accepted this change with the following text in version = 4 [upcoming below]]/.=20 =20 -------------- =20 Fine. Text in =A74 should probably be aligned with the above .e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. =20 NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and = received the Extended Message Capability to and from that peer. =20 =20 ---- >=93 Applications generating information which might be encapsulated > within BGP messages MUST limit the size of their payload to take the > maximum message size into account.=94 >=20 >I don=92t see what new behavior is been defined here. If there is none, = I would suggest to remove this sentence =20 Bruno =96 people asked to put this text in as an operational warning. = At this point, I=92m going to say unless there is harm it should remain. =20 [Bruno] OK. =20 ---- > A BGP announcement will, in the normal case, propagate throughout = the > BGP speaking Internet; and there will undoubtedly be BGP speakers > which do not have the Extended Message capability. Therefore, > putting an attribute which can not be decomposed to 4096 octets or > less in an Extended Message is a likely path to routing failure. >=20 >The issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than >4096, irrespective of the size of = each attribute. >Please elaborate on what you mean by=20 >=20 >=93an attribute which cannot be decomposed to 4096 octets=94 =20 An attribute which cannot be decomposed to 4096 is an attribute with = length 6000 inside of a BGP message which requires the entire attribute to be included. No such attribute exists today. If a small BGP peers = create a =93killer application=94 that uses a 6000 byte attribute, the rest of = the Internet does not have to use it. However, the person defining that attribute must carefully specify it must go with Extended BGP messages.=20 =20 =20 [Bruno] I don=92t think that I agree with this. E.g. I don=92t see where = RFCs 1997 or 8092 [(large)community] limits the size of their attribute. = Hence I don=92t see why you could not have, today (with Extended Message = support) , attributes larger than 4096 octets. Most probably same status for the = BGPSec attribute since they wanted for more space. [Sue]: You make a good point about the possibility of large communities = not limiting the size. It is worthy of a change to both the large = communities and a footnote in Randy=92s specification. How about the addition of a = single sentence to point people in the right direction.=20 =20 Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed = if it=20 sent in Extended message is a large community attribute with 1000 communities.=20 (12,000 bytes). =20 / =20 =20 =20 This text was added during an earlier discussion where the error cases = of a large BGP attribute was given. The originator of the common could not provide the exact description, but we agreed to put this =93warning = label=94 into the draft. This is one of the cases where adding/removing text = gets to be problematic.=20 =20 >--- >=93 It is RECOMMENDED that BGP protocol developers and implementers = are > conservative in their application and use of Extended Messages.=94 >=20 >What does this mean exactly? That they don=92t use this extension?=20 >That they don=92t use this extension unless XX_TO BE SPECIFIED_XX? =20 This warning was text that other participants asked to be added.=20 =20 It is a common sense warning. Extended messages are enabled on a peer = by peer basis as all BGP capabilities are. If you run into a Peer that = does not support the larger sizes, the BGP messages will need to be = reformatted to the smaller size. Running immediately to the Extended messages as = the default could cause problems.=20 =20 [Bruno] I think that the sentence could be elaborated. Indicating the problem, how the specification partially address it, and how the specification does not address it. In =93Running immediately to Extended Message=94 I don=92t think they = that the issue is with =93immediately=94. Whenever you start the transition, your = likely to run into problems. =20 =20 [Sue]: IMHO specification specifies how to encode the bytes on the wire = and the appropriate error handling of the messages. If I have missed = something in this case, please let me know.=20 [Bruno2] IMHO specifications need to handle error conditions that they create by design. =20 The specification does not specify the necessary policies implementation should have in order to decide what to do in the case of mixed network. The clear indication was this type was not appropriate for the protocol specification. =20 =20 Earlier discussion indicated that these is policy and mechanism = specific. It is worthy of =93use case or application notes=94 written for specific applications (BESS, SPRING, GROW), but not in the specification. Again, = if it is significant enough concern for operators and implementers =96 it = would be worthy to have combined use case document besides this point. = I=92m happy to sponsor cross-area work on this use case.=20 =20 --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages.. =20 >Why is this limited to future specifications? A priori, using existing = BGP mechanism (AFI/SAFI, attributes, * >communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = ?>case? This should be described in this specification. Note that this is not a = case of error handling, as every BGP=20 > speaker is behaving as specified. =20 I fail to see your logic. At this point, all BGP data (AFI/SAFI and attributes) must fit within a 4096 message. Therefore, a BGP peer A = which connects on link 1 to BGP peer B with 4096 message and on link to a BGP = peer C with extended messages only has to worry about reformatting the data. = =20 In the future, the first group that defines attribute or an NLRI that = does not fit within a 4096 BGP message and cannot be split, will need to = define how that works in the specification. There is no need to refine the = current set of specifications. =20 [Bruno] 1) cf above, I believe that there are existing BGP Attributes which may = not fit into a bytes 4096 BGP message 2)Even in the absence of such attribute, you have the issue of 2 smaller attributes whose cumulative size does not fit into a 4096 bytes message. =20 The problem is introduced by this specification, hence I believe this specification needs to specify how to handle this case. =20 [Sue]: IHMO the message transmission and reception error handling = issues are complete in the combination of RFC4271 and the extended message = section 5.=20 =20 What is not in this specification is the policy issues about what = happens if you combine 2 smaller attributes. For example, if you have a large community attribute of 400 communities (4800 bytes), you will likely run into problems when combining with some longer AS path lengths. [4800=E0 = 5096 bytes is a short jump]. People on the list and in-person argued this was policy and implementation specific details. [Bruno2] It=92s not implementation specific. This is an issue created by = the specification. Let=92s discuss it in public. =20 =20 I agree with you that it is extremely useful to the operator community = to have this type of policy details discussed to see if there is some = desire to have common policies and error communities. It is the type of thing = that GROW and IDR should be deeply involved for large communities. BESS, = LSVR, SPRING and others should consider what policy should be adapted for = their applications.=20 =20 >---- >Depending on the above specification, a section describing the = operational consequences in a network (such as the >Internet, BGP Enabled = ServiceS/VPN networks) is probably needed. Possible consequences could be BGP NLRI = >being removed in the middle of such network, or (extended) community (such as Route Targets) been removed. >Both having significant consequences on = the availability provided by the network. =20 At this point, there are no attributes or NLRI groupings that do not fit within 4096. If you define one (as SIDR did), then you will need to = have it reviewed by IDR, BESS, SPRING, and operational groups (GROW, etc).=20 [Bruno] no, cf above. [Sue]: Thank you for reminding me of the potential of large communities = to blow up BGP. I have a new worry to add to my BGP concerns list!=20 [Bruno2] IMHO, the problem is more with Extended Message than with large community. And we can work to consider and address this problem. --Bruno =20 Thanks, --Bruno =20 =20 --- >=A74 >OLD: The Extended Message Capability only applies to all messages = except for the >OPEN message.=20 >Probably >NEW: The Extended Message Capability applies to all message types = except for the >OPEN message (type 1).=20 >---- >=A78 >=93This extension to BGP does not change BGP's underlying security = issues =BB >Before evaluating this, I think this document should first specified = how a BGP=20 >messages bigger than 4096 octets is handled when it needs to be sent to = a=20 >received not supporting this extension. =20 Nits: >OLD : to reduce compexity >NEW : to reduce complexity =20 Thanks, --Bruno =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org Subject: [Idr] WG Last Call on Extened Message Support =20 =20 This begins a 2 week WG LC on Extended Message Support for BGP (draft-ietf-idr-bgp-extended-messages-27). You can access the draft at: = =20 = https://datatracker.ietf..org/doc/draft-ietf-idr-bgp-extended-messages/ =20 The authors should indicate whether they know of any IPR. Implementers = are encouraged to update the implementation data at:=20 =20 =20 https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ati ons =20 The draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages. BGP message space is running short = for all of the potential attributes or additions proposed by BGP-LS = features. =20 =20 The WG chairs intend to forward this draft to the IESG with the current level of implementation. =20 =20 As you comment on the draft, please consider if: a) the technology is mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for publication. =20 =20 Sue Hares (WG Chair, Shepherd)=20 =20 =20 _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. ------=_NextPart_000_0215_01D4C9CF.9D5E4040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno:

 

Thank you for your specific suggestion.=A0 =A0It helps us work = through the specifics of the changes to the BGP specification. =A0I do = not see the =A0text in draft-ietf-idr-bgp-extended-messages-28.txt = changing section 6.3 of RFC4271.=A0=A0 I’ve included my = understanding of how draft-ietf-idr-bgp-extended-messages-28.txt changes = RFC4271 in the detailed comments below.=A0 = =A0=A0=A0=A0

 

Your suggestion to improve section 6.3 of RFC4271 to handle the case = where a BGP speaker peers with two different messages sizes (4096, = 65,535) has operational merit. =A0=A0Would you mind this modification to = you text:

 

“A BGP speaker which peers with some peers with extended = message capability and other peers without extended message capability, = MUST do both of the following things:

-          = The BGP speaker MUST support [RFC7606], and

-          = The BGP speaker MUST handle a BGP Route (attribute, NLRI pair) that = is too large to be sent to a BGP peer without the extended message = capability using the “treat-as-withdraw” approach defined in = [RFC7606].

 

The BGP speaker, MAY remove some BGP attributes which are eligible to = use the Attribute discard approach [RFC7606]. “ = =A0

 

This would be added to section 5 of = draft-idr-bgp-extended-messages-25.txt.=A0=A0 See my suggested RFC4271 = text changes for a logical placement within RFC4271.=A0 =

 

If this change to your text is agreeable, then section 8 would need = to change to:

 

/New text for the end of section 8/

=A0

This = draft requires support for RFC7606 update error handling and as such = inherits the security considerations of RFC7606. This draft also = recommends BGP peers avoid such issues by using Authenticated Encryption = with additional Data (AEAD) ciphers [RFC5116] and thus to discard = messages that do not verify.=A0 It also recommends that IBGP peers all = support extended message capability and [RFC7606].=A0 =

 

During the transition to deploy extended messages = and RFC7606 on an IBGP cloud, operators should monitor any routes = dropped as “treat as withdraw”.=A0

 

One example of a RFC7606 attack profile using the = extended message is if the remote attacker is able that to craft a large = BGP route to send along a BGP path in which at least one peer does not = support extended messages. This peer which does not support extended = message capability may encounter a drain on internal resources = (processing, message sizes) if it continually reformats the large = messages. =A0If the “treat as withdraw” feature of RFC7606 = is utilized, some routes may be consistently withdrawn at this point = causing inconsistent routing. =A0

 

BGP routes are filtered by policies set by the = operators. =A0Implementations may provide policies to filter routes that = would cause the “treat as withdraw” from being pass by an = extended message speaker.=A0

/

 

Please let me know I understand your suggested = changes.

 

Sue Hares

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of = bruno.decraene@orange.com
Sent: Friday, February 15, 2019 = 5:25 AM
To: Susan Hares
Cc: idr@ietf.org; Robert = Raszuk
Subject: Re: [Idr] WG Last Call on Extened Message = Support

 

Susan,

 

We now agree that the problem can happen with existing BGP = attributes. Good. So the argument to postpone the error handling = discussion for future specification defining large attributes does not = hold anymore.

 

Coming back to the draft,

 

Old/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which can not be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

 

1)      = As a minor comment, the error is not limited to an (one single) = attribute (type) which size is bigger than 4096 octets. The error = happens when the Total Path Attribute Length (for all attributes) is = bigger than 4096 octets.

 

[Sue]: My understanding of the Extended message draft is that it is = not dealing with section 6.3 of RFC4271. =A0Here’s my = understanding of the

 

RFC4271 states:

 

“All Errors detected while processing the Message header must = be indicated by sending a NOTIFICATION message with the Message Header = error.=A0 The Error subcode elaborates on the specific nature of the = error. “

 

One of the errors is a message header length:=A0 “If the length = field of the message header is less than 19 or greater than = 4096.”=A0 If any of these super large attributes causes the = message length to be greater than 4096, then with RFC4271, the error = code sent would be “Bad Message = length.”

 

If the message length is switch from 4096 to 65535 octets, the = RFC4271 error handling would allow the message length to be 65,535. =

 

 

After the section 6.1 text RFC4271 is changed to the following: =

 

=A0=A0=A0 If at least one of the following is true: =

-          = If the Length field of the message header is less than 19 or greater = than 4096

for OPEN message,

-          = If BGP Extended Messages capability is not set, the length field of = any other BGP message other than an OPEN message is less than 19 or = greater than 4095,

 

-          = If the BGP Extended Message capability is set for a BGP peer, if the = length field is less than 19 or greater than 65,535.=A0 (See the error = handling below for the setting of this = function.)

 

-          = If the length field of an UPDATE message is less than the minimum = field of the UPDATE message, or

 

-          = If the length field of a KEEPALIVE message is not equal to 19, or =

 

-          = If the length field of a NOTIFICATION message is less than the = minimum length of the NOTIFICATION message.

 

Then the Error Subcode MUST Be set to Bad Message Length.=A0 The Data = field MUST contain the erroneous length field.

[

=A0=A0 =A0=A06.9) Extended Message Capability =

 

=A0=A0 = To advertise the BGP Extended Message Capability to a peer, a = BGP

=A0=A0 = speaker uses BGP Capabilities Advertisement [RFC5492].=A0 = By

=A0=A0 = advertising the BGP Extended Message Capability to a peer, a = BGP

=A0=A0 = speaker conveys that it is able to send, receive, and properly = handle

=A0=A0 = BGP Extended Messages.

 

=A0=A0 = A peer which does not advertise this capability MUST NOT send = BGP

=A0=A0 = Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.

 

=A0=A0 = The BGP Extended Message Capability is a new BGP Capability [RFC5492]

=A0=A0 defined with Capability code 6 and Capability = length 0.

=A0=A0

=A0=A0=A0=A06.9.1) Operation:

 

=A0=A0 =A0=A0=A0A BGP speaker that is capable of sending and =
receiving BGP Extended

=A0=A0 = Messages SHOULD advertise the BGP Extended Message Capability to = the

=A0=A0 = peer using BGP Capabilities Advertisement [RFC5492].=A0 A BGP = speaker

=A0=A0 = MAY send Extended Messages to its peer only if it has sent = and

=A0=A0 = received the Extended Message Capability from that = peer.

 

=A0=A0 = The Extended Message Capability applies to all messages except = for

=A0=A0 = the OPEN message.=A0 This exception is made to reduce complexity = of

=A0=A0 = providing backward compatibility

 

=A0=A0=A0 =A0An implementation that advertises support for BGP =
Extended Messages

=A0=A0 = MUST be capable of receiving a message with a length up to = and

=A0=A0 = including 65535 octets.

 

=A0=A0 = Applications generating information which might be = encapsulated

=A0=A0 = within BGP messages MUST limit the size of their payload to take = the

=A0=A0 = maximum message size into account.

 

=A0=A0 = If a BGP update with a payload longer than 4096 octets is received = by

=A0=A0 = a BGP listener who has neither advertised nor agreed to accept = BGP

=A0=A0 = Extended Messages, the listener MUST treat this as a malformed = update

=A0=A0 = message, and MUST raise an UPDATE Message Error (see section 6.3). =

=A0

 

=A0=A0 = A BGP announcement will, in the normal case, propagate throughout = the

=A0=A0 = BGP speaking Internet; and there will undoubtedly be BGP = speakers

=A0=A0 = which do not have the Extended Message capability.=A0 = Therefore,

=A0=A0 = putting an attribute which cannot be decomposed to 4096 octets = or

=A0=A0 = less in an Extended Message is a likely path to routing = failure.

 

=A0=A0 = It is RECOMMENDED that BGP protocol developers and implementers = are

=A0=A0 = conservative in their application and use of Extended = Messages.

 

=A0=A0 6.9.2 Error Handling for the Extended = messages

 

=A0=A0=A0 =A0A BGP speaker that has the ability to use Extended =
Messages but has

=A0=A0 = not advertised the BGP Extended Messages capability, presumably = due

=A0=A0 = to configuration, SHOULD NOT accept an Extended Message.=A0 A = speaker

=A0=A0 = MAY implement a more liberal policy and accept Extended = Messages,

=A0=A0 = even from a peer to which it has not advertised the capability, = in

=A0=A0 = the interest of preserving the BGP session if at all = possible.

 

=A0=A0 = A BGP speaker that does not advertise the BGP Extended = Messages

=A0=A0 = capability might also genuinely not support Extended Messages.=A0 = Such

=A0=A0 = a speaker MUST follow the error handling procedures of section 6.1 =

=A0=A0=A0regarding message length.=A0 =

 

=A0=A0 = The inconsistency between the local and remote BGP speakers MUST = be

=A0=A0 = flagged to the network operator through standard = operational

=A0=A0 = interfaces.=A0 The information should include the NLRI and as = much

=A0=A0 = relevant information as reasonably possible.

 

[End of text change from draft ]

 

 

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

 

2)      = As a major comment, I am asking for the specification to specify how = it handles that failure, which is not the result of a possible bug, but = created by design by the solution. It will = happen.

=A0

Your proposition to “raise an alarm” is required but not = sufficient as we still need to specify what we do with this = “big” route. One option could be “treat as = withdraw”, another option suggested by Robert is to propagate the = NLRI with subset of attributes plus an indication of the failure = (“a short attribute BGP_PIPE_TOO_THIN”). There may be others options.

 

[Sue]: Robert’s option is a fine idea, but the WG did not = accept this option in the past so I cannot force this option into the = specification.=A0 I hope that Robert will propose this option again.=A0 =

 

To trigger the discussion on the resolution, I would propose the = following text “One BGP Route too large to be propagated to a BGP = receiver not supporting BGP Extended Message MUST be handled, over this = BGP session, using the Treat-as-withdraw approach as defined in = [RFC7606]. The BGP speaker MAY, beforehand, remove some BGP attributes = which are eligible to the Attribute discard approach = [RFC7606].”

 

[Sue]:=A0 This text deals with section 6.3 in RFC4271, and to my = understanding draft-ietf-idr-bgp-extended-messges-28.txt only deals with = section 6.1 of RFC4271.=A0 =A0=A0In addition, there is no concept of = propagation RFC7606 or RFC4271.=A0 Each BGP peer receives BGP messages = and updates, it then propagates or sends routes and attributes to its = peers.=A0 =A0=A0Could I restate your suggestion as: =

 

6.9.2 Error handling

(added at the end of the current text =A0

 

A BGP speaker which peers with some peers with extended message = capability and other peers without extended message capability, MUST = handle a BGP Route (attribute, NLRI pair) that is too large to be sent = to a BGP peer without the extended message capability using the = “treat-as-withdraw” approach defined in [RFC7606]. =A0The = BGP speaker, MAY remove some BGP attributes which are eligible to use = the Attribute discard approach [RFC7606].=A0

=A0

=A0

3)      = Once error handling is specified, the draft will be able to discuss =

a.       = the operational considerations for this issue (e.g. The one from = RFC7606 could be referenced as-is, or used as = inspiration)

b.      = the security considerations (as a remote attacker would be able to = craft a large BGP route that will be withdrawn (assuming = “treat-as-withdraw”) somewhere in some AS, possibly creating = routing inconsistencies within the AS)

c.       = the proposed mitigations (e.g., an operator should enable support for = Extended messages on all IBGP sessions first, before enabling it on an = EBGP session; If not possible, an operator could define a policy to = filter BGP attributes from EBGP sessions, typically based on their type = and size;….)

 

more inline [Bruno2]

 

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Thursday, February = 14, 2019 6:20 PM
To: DECRAENE Bruno TGI/OLN
Cc: = idr@ietf.org; 'Jakob Heitz (jheitz)'; 'John Scudder'; 'Alvaro = Retana'
Subject: RE: [Idr] WG Last Call on Extened Message = Support

 

Bruno:

 

Thank you for careful considerations on the use case.   I = think we have translation issues between our “English” = language again so I have tried to be precise in the detailed comments. =  I’ve summarized my comments as well to help us take the next = step.

 

Sue

 

Summary

----

Good catch on the 1000 large BGP communities blowing up the message = size!  This is a case where a code path could get caught with = program error.  The error handling (section 6.1 in RFC4271 per = section 5 in the extended specification) IMHO handles the case where the = attribute is longer than the message.   Please let me know if = I’ve missed something.   

 

[Bruno2] I don’t think that section 6.1 of RFC4271 covers this. = The problem is not a Message Header error handling as a proper BGP = implementation would not sent the message. (not to mention with = inconsistent size).

[Sue2]: OK, but section 6.1 is the only places that this draft = changes.

 

As I understand it,  you are asking this specification to be = expanded to add notes on policies on what implementation should do to = correctly combine RFC4271 length sizes with extended length = sizes.   The implementers and operations people commented = earlier that this should not be in the protocol specification other than = as a brief footnote. 

 

[Bruno2]An error handling must exist even in the absence of SP = policies. The argument related to previous discussions does not hold = IMHO as I’ve raised a new point (this happens with existing BGP = attributes, not in a hypothetical new attribute)

[Sue2]:=A0 Thank you for sending your text.=A0 I can your comments = are on the UPDATE handling processes based on RFC7606.=A0 We were = discussing 2 different places in RFC4271.

 

I agree there is a need for such standardization as BCPs for = particular use cases (large communities, BESS (EVPN or centralized = controller), SPRING, BGP-LS information (see Daylight comments = yesterday), SD-WANs (rtgwg), and SPRING.   I think the chairs = of the WGs utilizing should consider if there is need for = standardization for a minimal set of policy for message sizes for = specific use cases.   I will be glad to send request to these = WG or to host something in IDR if there is policy that can be used = across all use cases.

 

[Bruno2] I don’t think that Error handling is to be considered = as optional or for future consideration.

[Sue2]:=A0 Based on your proposed text, I can see the value of = considering this text at this time. =A0

 

To provide a slight expansion to point people in this direction, how = about this change to paragraph in section 4:

 

Old/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which can not be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

/

New/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which cannot be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

   One example of a valid attribute which = cannot be precisely decomposed if it

   sent in Extended message is a large = community attribute with 1000 communities.

   (12,000 bytes).  =

/

[PS = – in American English “Can not” is normally = concatenated “cannot”.]

   

[Bruno2] Thanks for the proposition, but this does not address my = concern.

[Sue]: Thank you for your text – I understand why now. =

 

From:= = bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] =
Sent: Thursday, February 14, 2019 3:29 AM
To: Susan = Hares
Cc: idr@ietf.org; 'Jakob Heitz = (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message = Support

 

Sue,

 

Thanks for the reply. Please see inline = [Bruno]

 

From:= Susan = Hares [mailto:shares@ndzh.com]
Sent: Wednesday, February 13, = 2019 8:03 PM
To: DECRAENE Bruno TGI/OLN
Cc: = idr@ietf.org; 'Jakob Heitz (jheitz)'
Subject: RE: [Idr] WG = Last Call on Extened Message Support

 

Bruno:

 

I’d like to answer some of the questions you sent Randy based = on comments (public and private) the chairs and I as the shepherd = received on this draft in our last WG LCs.. =   

 

Several of the comments you questioned were put in to answer other = questions.   This gets into a catch-22… problem – = where you put changes in for one person/take out the changes out for = another.  In academic circles this is called the reviewer #2 = problem (reviewer 1 insists changes go in, reviewer 2 insists changes go = out) during publication.  Therefore, I’m I am going to answer = most of your questions where this is the case.  =

 

I believe that Randy has new version with the changes I’ve = indicated.  I’m hoping he’ll just post that = version.  AFAILK, we do have 2 compliant implementations. =

 

Sue

 

 

 

<shepherd hat on>

This draft’s technology provides efficient processing for some = application by allow a huge BGP message size.  Whether = “chunking” BGP to 4096 byte messages or packing large = amounts of data into 65,000 byte message is more effective for a = particular application is something only an implementer of a particular = BGP implementation  can decide.   This draft simply gives = freedom for applications to not be restrict to an artificially small = message size.  The market place will choose whether this technology = is used or not. 

 

As Jakob pointed out, changing a highly tuned BGP implementation = which “chunks” BGP data into 4096 byte messages may involve = substantial rework of the implementation. 

 

 

(snip)

From: Idr = <idr-bounces@ietf.org> On Behalf Of = bruno.decraene@orange..com
Sent: 29 January 2019 = 13:33
To: Susan Hares <shares@ndzh.com>
Cc: = idr@ietf.org
Subject: Re: [Idr] WG Last Call on Extened = Message Support

 

Hi = WG,

 

>Please find = below some comments.

>As of today, = I don’t believe this specification is ready to be progressed to = IESG/RFC, especially for a document >updating RFC 4271 (core BGP = spec).

 

&= gt; The WG chairs intend to forward this draft to the IESG with the = current level of implementation. 

 

>https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp= -extended->implementations says : 5a =

Does not send Extended Message capability =

Yes

Yes

Yes =

 

>I may be = misunderstanding the implementation report, but my reading of the above = is that none of the reported >implementations sends the capability = hence no implementation supports draft-ietf-idr-bgp-extended-messages.. =

>Here this = document is updating RFC 4271, so it is not a minor extension for a = niche use case. So I don’t see the >arguments for not requiring the = IDR’s usual two interoperable = implementations.

 

>In our mail thread, we discovered that the implementation report = should have indicate

>full support.   I’m waiting for Olivier to update = based on the last point, but my understanding is that =

All implementations have full support.  

 

[Bruno] ok, solved

>----

>=A7 = 1

>“ As BGP is = extended to support newer AFI/SAFIs and

>   newer = capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there = is

>   a need = to extend the maximum message size beyond 4096 octets.  = “

> 

> = https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-mes= sages-27#section-1

 

 

>[I-D.ietf-sidr-bgpsec-protocol is now RFC = 8205 (thanks for updating the reference). It has removed the = normative/any >reference to = draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not = need draft-ietf-idr-bgp->extended-messages. Can we have an update on this?  Can the introduction of draft-ietf-idr-bgp-extended-messages >be = updated to introduce on the real = reasons/needs?

 

SIDR gave up waiting on IDR’s work and took a reduced size of = encryption.   The security people were very sad about the = reduction.  How is this working in practice? WG sidrops can answer = this question. 

 

The real problem is there is finite message space.  =

[Bruno] So too bad the draft does not solve the real problem ;-) (as = message space is still limited)

 

[Sue]: The message is still finite (smile),  but I hope 65,635 = (smile) is probably enough for 10 years.  =  

 

There are two ways to send lots of BGP routes and/or attributes = – to “chunk” these into small message sizes or place = these into a large message.    Some applications may = always want to “chunk” into message sizes smaller than = 4096.   Some application make work more efficiently utilizing = large message size.  As the potential number of NLRI and BGP = attributes grows, new applications may consider large message sizes to a = more reasonable way to exchange amounts of BGP data.   =  

 

The decision on how to send BGP messages over the wire is a = peer-by-peer decision in a network.   Each BGP peer is in = charge of reformatting the BGP message it sends to the remote BGP = peer.   The BGP capabilities in this draft represent an = agreement between two BGP peers.  These are facts of basic BGP = implementations

[Bruno] Let’s take the example of a BGP Route Reflector having = a mixed of clients, some supporting Extend Message (EM) and some = not.

From an EM client, it receives a BGP update containing one (single) = NLRI with an Total Path Attribute Length bigger than  4090 byte = (e.g. having 1000 large communitiess)

Can you explain me how it behaves to send this NLRI to an IBGP peer = not supporting EM?

[Sue]:  Gladly…

A BGP route reflector (RR-A) is peering with each of its BGP = clients.   It agrees with each of its clients (BGP-C1, BGPC2, = BGPC3) whether the BGP Extended messages is accepted or not (based on = capability announcement).

Let us assume that BGP-C1 does not support extended messages, and =  BGP-C2 and BGP-C3 do support extended messages. =

 

If the policy in RR accepts a total path length of 1000 large = communities with  a single NLRI, it may send the BGP attribute via = extended communities to BGP-C2 and = BGP-C2.

The policy in the RR must specify whether: =

a)      = the “too long” attribute path length must be dropped, or =

b)      = the BGP attribute path can be truncated. =

 

This is a policy issue within the BGP peer and the network operation = staff.  Each operator may choose to write this policy differently. =

[Bruno2] So we agree that a new behavior is REQUIRED. The draft does = not mention this. The ability to change the behavior by policy does not = remove the need for specifying the error = handling.

 

Rather than specify the numerous cases in the protocol specification, =  the previous discussions (private and public) asked us to trim = this information out of the protocol specification. =

[Bruno2] Can’t be have a general rule which is good enough to = handle the issue? Previous discussions seemed based on the fact the = error condition would happen for future attribute. This is not the = case.

 

If you believe this is worthy of a use case draft for the sake of = BESS, LSVR, SPRING, Grow and others, I will happily WG chair sponsor a = draft that can be reviewed by all these WGs. =

[Bruno2] I believe that this is worthy in this specification. =

 

 

– so I do not believe adding these facts to Randy’s draft = is useful.  In fact, in the previous rounds of review this point = was made.

 

Your question (and perhaps Jakob’s) is whether we have reached = a time/place where the “chunking” approach will fail on a = peer-by-peer basis?   This draft does not make this = statement. 

 

The point of this draft is to enable more efficient processing by = increasing the message size for BGP peers that send a lot of data (e.g. = BGP-LS) .   The choice to “chunk” or stream in = large BGP message is an implementation choice for a particular BGP = application. 

<= o:p> 

----

=A74

=A73 says =
“A peer which does not advertise this capability MUST NOT send =
BGP

  =  Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.”<= /o:p>

[I believe randy accepted this change with the following text in = version 4 [upcoming below]]/.

 

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

<= o:p> 

F= ine. Text in =A74 should probably be aligned with the above = .e.g.

O=
LD: A =
BGP speaker

   MAY = send Extended Messages to its peer only if it has received = the

   = Extended Message Capability from that peer.

<= o:p> 

N= EW:

A BGP = speaker

   MAY = send Extended Messages to its peer only if it has sent and received = the

   = Extended Message Capability to and from that = peer.

 

 

----

>&=
#8220;   Applications generating information which might be =
encapsulated

>   within = BGP messages MUST limit the size of their payload to take = the

>   = maximum message size into account.”

> 

>I = don’t see what new behavior is been defined here. If there is = none, I would suggest to remove this sentence

 

Bruno – people asked to put this text in as an operational = warning.  At this point, I’m going to say unless there is = harm it should remain. 

[Bruno] OK.

<= o:p> 

-= ---

>   A BGP = announcement will, in the normal case, propagate throughout = the

>   BGP = speaking Internet; and there will undoubtedly be BGP = speakers

>   which = do not have the Extended Message capability.  = Therefore,

>   = putting an attribute which can not be decomposed to 4096 octets = or

>   less = in an Extended Message is a likely path to routing = failure.

><= o:p> 

>T= he issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than >4= 096, irrespective of the size of each attribute.

>P= lease elaborate on what you mean by

> 

>&= #8220;an attribute which cannot be decomposed to 4096 octets”

 

An attribute which cannot be decomposed to 4096 is an attribute with = length 6000 inside of a BGP message which requires the entire attribute = to be included.   No such attribute exists today.  =  If a small BGP peers create a “killer application” = that uses a 6000 byte attribute, the rest of the Internet does not have = to use it.   However, the person defining that attribute must = carefully specify it must go with Extended BGP messages. =

 

 

[Bruno] I don’t think that I agree with this. E.g. I = don’t see where RFCs 1997 or 8092 [(large)community] limits the = size of their attribute. Hence I don’t see why you could not have, = today (with Extended Message support) , attributes larger than 4096 = octets. Most probably same status for the BGPSec attribute since they = wanted for more space.

[Sue]: You make a good point about the possibility of large = communities not limiting the size.  It is worthy of a change to = both the large communities and a footnote in Randy’s = specification.  How about the addition of a single sentence to = point people in the right direction.

 

Old/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which can not be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

/

New/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which cannot be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

   One example of a valid attribute which = cannot be precisely decomposed if it

   sent in Extended message is a large = community attribute with 1000 communities.

   (12,000 bytes).  =

/

  =

 

 

This text was added during an earlier discussion where the error = cases of a large BGP attribute was given.  The originator of the = common could not provide the exact description, but we agreed to put = this  “warning label” into the draft.   This = is one of the cases where adding/removing text gets to be problematic. =

 <= o:p>

>-= --

>“   = It is RECOMMENDED that BGP protocol developers and implementers = are

>   = conservative in their application and use of Extended = Messages.”

> 

>What does = this mean exactly? That they don’t use this extension?

>That they = don’t use this extension unless XX_TO BE SPECIFIED_XX?

 

This warning was text that other participants asked to be added. =

 

It is a common sense warning.  Extended messages are enabled on = a peer by peer basis as all BGP capabilities are.  If you run into = a Peer that does not support the larger sizes, the BGP messages will = need to be reformatted to the smaller size.   Running = immediately to the Extended messages as the default could cause = problems.

 

[Bruno] I think that the sentence could be elaborated. Indicating the = problem, how the specification partially address it, and how the = specification does not address it.

In “Running immediately to Extended Message” I = don’t think they that the issue is with “immediately”. = Whenever you start the transition, your likely to run into = problems.

 

 

[Sue]: IMHO specification specifies how to encode the bytes on the = wire and the appropriate error handling of the messages.   If = I have missed something in this case, please let me know. =

[Bruno2] IMHO specifications need to handle error conditions that = they create by design.

 

The specification does not specify the necessary policies = implementation should have in order to decide what to do in the case of = mixed network.   The clear indication was this type was not = appropriate for the protocol specification. =  

 

Earlier discussion indicated that these is policy and mechanism = specific.  It is worthy of “use case or application = notes” written for specific applications (BESS, SPRING, GROW), but = not in the specification.  Again, if it is significant enough = concern for operators and implementers – it would be worthy to = have combined use case document besides this point. =    I’m happy to sponsor cross-area work on this use = case.

 

-= --

  Future = protocol specifications will need to describe how to = handle

   peers = which can only accommodate 4096 octet messages..

<= o:p> 

>Why is this = limited to future specifications? A priori, using existing BGP mechanism = (AFI/SAFI, attributes, * >communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = ?>case? This should be described = in this specification. Note that this is not a case of error handling, = as every BGP

> speaker is = behaving as specified.

 

I fail to see your logic.  At this point, all BGP data (AFI/SAFI = and attributes) must fit within a 4096 message.   Therefore, a = BGP peer A which connects on link 1 to BGP peer B with 4096 message and = on link to a BGP peer C with extended messages only has to worry about = reformatting the data. 

 

In the future, the first group that defines attribute or an NLRI that = does not fit within a 4096 BGP message and cannot be split, will need to = define how that works in the specification.  There is no need to = refine the current set of specifications.   =

[Bruno]

1) cf above, I believe that there are existing BGP Attributes which = may not fit into a bytes 4096 BGP = message

2)Even in the absence of such attribute, you have the issue of 2 = smaller attributes whose cumulative size does not fit into a 4096 bytes = message.

 

The problem is introduced by this specification, hence I believe this = specification needs to specify how to handle this = case.

 

[Sue]:  IHMO the message transmission and reception error = handling issues are complete in the combination of RFC4271 and the = extended message section 5.

 

What is not in this specification is the policy issues about what = happens if you combine 2 smaller attributes.  For example, if you = have a large community attribute of 400 communities (4800 bytes), you = will likely run into problems when combining with some longer AS path = lengths.  [4800=E0= 5096 bytes is a short jump]. People on the list and in-person argued = this was policy and implementation specific = details.

[Bruno2] It’s not implementation specific. This is an issue = created by the specification. Let’s discuss it in = public. 

 

I agree with you that it is extremely useful to the operator = community to have this type of policy details discussed to see if there = is some desire to have common policies and error communities. =   It is the type of thing that GROW and IDR should be deeply = involved for large communities.   BESS, LSVR, SPRING and = others should consider what policy should be adapted for their = applications.

 

>-= ---

>D= epending on the above specification, a section describing the = operational consequences in a network (such as the >I= nternet, BGP Enabled ServiceS/VPN networks) is probably needed. Possible = consequences could be BGP NLRI >b= eing removed in the middle of such network, or (extended) community = (such as Route Targets) been removed. >B= oth having significant consequences on the availability provided by the = network.

 

At this point, there are no attributes or NLRI groupings that do not = fit within 4096.   If you define one (as SIDR did), then you = will need to have it reviewed by IDR, BESS, SPRING, and operational = groups (GROW, etc). 

[Bruno] no, cf above.

[Sue]:  Thank you for reminding me of the potential of large = communities to blow up BGP.  I have a new worry to add to my BGP = concerns list!

[Bruno2] IMHO, the problem is more with Extended Message than with = large community. And we can work to consider and address this = problem.

--Bruno

 

Thanks,

--Bruno

 

<= o:p> 

-= --

>=A7= 4

>OLD: The Extended = Message Capability only applies to all messages except for the >OPEN message. =

>Probably

>NEW: The Extended = Message Capability applies to all message types except for the >OPEN message (type 1). =

>----

>=A78

>“This =
extension to BGP does not change BGP's underlying security =
issues =BB
>Before evaluating =
this, I think this document should first specified how a BGP 
>messages bigger =
than 4096 octets is handled when it needs to be sent to a 
>received not supporting this extension.

 

N= its:

>OLD : to = reduce compexity

>NEW : to = reduce complexity

 

T= hanks,

-= -Bruno

<= o:p> 

From:= Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Tuesday, January 29, = 2019 12:33 PM
To: idr@ietf.org
Subject: [Idr] = WG Last Call on Extened Message = Support

 

<= o:p> 

T= his begins a 2 week WG LC on Extended Message Support for BGP = (draft-ietf-idr-bgp-extended-messages-27).  You can access the = draft at:

<= o:p> 

https://datat= racker.ietf..org/doc/draft-ietf-idr-bgp-extended-messages/<= o:p>

<= o:p> 

T= he authors should indicate whether they know of any IPR.   = Implementers are encouraged to update the  implementation data at: =

<= o:p> 

https://trac.= ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations= <= o:p>

<= o:p> 

T= he draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages.  BGP message space is = running short for all of the potential attributes or additions proposed = by BGP-LS features. 

<= o:p> 

T= he WG chairs intend to forward this draft to the IESG with the current = level of implementation. 

<= o:p> 

A= s you comment on the draft, please consider if: a) the technology is = mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for = publication. 

<= o:p> 

S= ue Hares (WG Chair, Shepherd)

<= o:p> 

 = 

_________________________=
_________________________________________________________________________=
_______________________
 <=
/pre>
Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 <=
/pre>
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received =
this email in error, please notify the sender and delete this message =
and its attachments.
As emails may be =
altered, Orange is not liable for messages that have been modified, =
changed or falsified.
Thank =
you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received this =
email in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, =
Orange is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received this =
email in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, =
Orange is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles =
d'alteration,
Orange decline =
toute responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This =
message and its attachments may contain confidential or privileged =
information that may be protected by =
law;
they should not be =
distributed, used or copied without =
authorisation.
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments.
As emails may be altered, Orange is not liable for messages =
that have been modified, changed or =
falsified.
Thank =
you.
------=_NextPart_000_0215_01D4C9CF.9D5E4040-- From nobody Thu Feb 21 07:36:57 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A602712958B for ; Thu, 21 Feb 2019 07:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWzstvsxzY3h for ; Thu, 21 Feb 2019 07:36:47 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466D5129284 for ; Thu, 21 Feb 2019 07:36:46 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.248.72; From: "Susan Hares" To: "'Jakob Heitz \(jheitz\)'" , "'Robert Raszuk'" Cc: "'Bruno Decraene'" , "'idr@ietf. org'" References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk> <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> <17281_1550132953_5C6526D9_17281_161_1_53C29892C857584299CBF5D05346208A489D3D92@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <00c901d4c489$8f311830$ad934890$@ndzh.com> In-Reply-To: Date: Thu, 21 Feb 2019 10:36:38 -0500 Message-ID: <023401d4c9fb$3c8db080$b5a91180$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0235_01D4C9D1.53BED470" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rAefZHwsB7dxHTgI7AvBBAac2MMMBU1Q3bALWlDmyAkHqv2KkI0hCQA== Content-Language: en-us X-Antivirus: AVG (VPS 190221-2, 02/21/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 15:36:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0235_01D4C9D1.53BED470 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Jakob and Robert:=20 =20 Thanks to Bruno=E2=80=99s proposed code =E2=80=93 I think I understand = Bruno=E2=80=99s concerns. Would you read my response and the proposed = text changes. Let me know if my proposed changes to section 5 and 9 of = Randy=E2=80=99s draft address your concerns.=20 =20 If so, I will start a specific all on those additions to the draft.=20 =20 Thanks for your patience with me, =20 Susan Hares =20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz = (jheitz) Sent: Friday, February 15, 2019 8:02 PM To: Robert Raszuk; Susan Hares Cc: Bruno Decraene; idr@ietf. org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 This is a show stopper for me too. =20 One way to solve it would be to restrict the extended messages to new = address families only. Any new address family would then need to specify that it must support = extended messages, such that all implementations of the new address family must support the = extended messages. =20 Regards, Jakob. =20 [Bruno] Let=E2=80=99s take the example of a BGP Route Reflector having a = mixed of clients, some supporting Extend Message (EM) and some not. >From an EM client, it receives a BGP update containing one (single) NLRI = with an Total Path Attribute Length bigger than 4090 byte (e.g. having = 1000 large communitiess) Can you explain me how it behaves to send this NLRI to an IBGP peer not = supporting EM? =20 =20 From: Idr On Behalf Of Robert Raszuk Sent: Friday, February 15, 2019 1:34 AM To: Susan Hares Cc: Bruno Decraene ; idr@ietf. org = Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Dear Sue & authors of this proposal, =20 > Therefore, putting an attribute which cannot be decomposed to=20 > 4096 octets or less in an Extended Message is a likely path to=20 > routing failure. =20 That's brilliant statement but not enough to proceed with this spec.=20 =20 See the fundamental change that today such issue is in vast majority of = cases locally significant. That means that if I send NLRI to BGP it will = have a decent chance to be received by all intended parties.=20 =20 With new spec we are saying that it may silently fail somewhere in the = middle and we do not do anything about it. That's to me showstopper.=20 =20 At min if given NLRI can not be sent with XXL attributes to some peers = (say on the RR which Bruno mentioned) we must specify protocol extension = in this very spec on how to deal with it.=20 =20 Such extension may be as simple as to define a short attribute = BGP_PIPE_TOO_THIN which will be inserted in the place where XXL = attribute just did not fit smaller message size peers to tell them then = "Hey something is broken with this NLRI" - pls check. Then it will be up = to local policy to install such NLRI or drop it.=20 =20 Thx, R. =20 =20 On Thu, Feb 14, 2019 at 6:21 PM Susan Hares wrote: Bruno:=20 =20 Thank you for careful considerations on the use case. I think we have = translation issues between our =E2=80=9CEnglish=E2=80=9D language again = so I have tried to be precise in the detailed comments. I=E2=80=99ve = summarized my comments as well to help us take the next step.=20 =20 Sue=20 =20 Summary ---- Good catch on the 1000 large BGP communities blowing up the message = size! This is a case where a code path could get caught with program = error.. The error handling (section 6.1 in RFC4271 per section 5 in the = extended specification) IMHO handles the case where the attribute is = longer than the message. Please let me know if I=E2=80=99ve missed = something. =20 =20 As I understand it, you are asking this specification to be expanded to = add notes on policies on what implementation should do to correctly = combine RFC4271 length sizes with extended length sizes. The = implementers and operations people commented earlier that this should = not be in the protocol specification other than as a brief footnote. =20 =20 I agree there is a need for such standardization as BCPs for particular = use cases (large communities, BESS (EVPN or centralized controller), = SPRING, BGP-LS information (see Daylight comments yesterday), SD-WANs = (rtgwg), and SPRING. I think the chairs of the WGs utilizing should = consider if there is need for standardization for a minimal set of = policy for message sizes for specific use cases. I will be glad to = send request to these WG or to host something in IDR if there is policy = that can be used across all use cases.=20 =20 To provide a slight expansion to point people in this direction, how = about this change to paragraph in section 4:=20 =20 Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed = if it=20 sent in Extended message is a large community attribute with 1000 = communities.=20 (12,000 bytes). =20 / [PS =E2=80=93 in American English =E2=80=9CCan not=E2=80=9D is normally = concatenated =E2=80=9Ccannot=E2=80=9D.]=20 =20 =20 =20 =20 From: bruno..decraene@orange.com = [mailto:bruno.decraene@orange.com]=20 Sent: Thursday, February 14, 2019 3:29 AM To: Susan Hares Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Sue, =20 Thanks for the reply. Please see inline [Bruno] =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Wednesday, February 13, 2019 8:03 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support =20 Bruno:=20 =20 I=E2=80=99d like to answer some of the questions you sent Randy based on = comments (public and private) the chairs and I as the shepherd received = on this draft in our last WG LCs. =20 =20 Several of the comments you questioned were put in to answer other = questions. This gets into a catch-22=E2=80=A6 problem =E2=80=93 where = you put changes in for one person/take out the changes out for another. = In academic circles this is called the reviewer #2 problem (reviewer 1 = insists changes go in, reviewer 2 insists changes go out) during = publication. Therefore, I=E2=80=99m I am going to answer most of your = questions where this is the case. =20 =20 I believe that Randy has new version with the changes I=E2=80=99ve = indicated. I=E2=80=99m hoping he=E2=80=99ll just post that version. = AFAILK, we do have 2 compliant implementations.=20 =20 Sue=20 =20 =20 =20 =20 This draft=E2=80=99s technology provides efficient processing for some = application by allow a huge BGP message size. Whether = =E2=80=9Cchunking=E2=80=9D BGP to 4096 byte messages or packing large = amounts of data into 65,000 byte message is more effective for a = particular application is something only an implementer of a particular = BGP implementation can decide.. This draft simply gives freedom for = applications to not be restrict to an artificially small message size. = The market place will choose whether this technology is used or not.=20 =20 As Jakob pointed out, changing a highly tuned BGP implementation which = =E2=80=9Cchunks=E2=80=9D BGP data into 4096 byte messages may involve = substantial rework of the implementation. =20 =20 =20 (snip)=20 From: Idr On Behalf Of bruno.decraene@orange.com Sent: 29 January 2019 13:33 To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support =20 Hi WG, =20 >Please find below some comments. >As of today, I don=E2=80=99t believe this specification is ready to be = progressed to IESG/RFC, especially for a document >updating RFC 4271 = (core BGP spec). =20 > The WG chairs intend to forward this draft to the IESG with the = current level of implementation. =20 =20 >https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended- = >implementations says : 5a=20 Does not send Extended Message capability=20 Yes=20 Yes=20 Yes=20 =20 >I may be misunderstanding the implementation report, but my reading of = the above is that none of the reported >implementations sends the = capability hence no implementation supports = draft-ietf-idr-bgp-extended-messages..=20 >Here this document is updating RFC 4271, so it is not a minor extension = for a niche use case. So I don=E2=80=99t see the >arguments for not = requiring the IDR=E2=80=99s usual two interoperable implementations. =20 >In our mail thread, we discovered that the implementation report should = have indicate >full support. I=E2=80=99m waiting for Olivier to update based on the = last point, but my understanding is that=20 All implementations have full support. =20 =20 [Bruno] ok, solved >---- >=C2=A7 1 >=E2=80=9C As BGP is extended to support newer AFI/SAFIs and > newer capabilities (e.g., [ = I-D.ietf-sidr-bgpsec-protocol]), there is > a need to extend the maximum message size beyond 4096 octets. = =E2=80=9C >=20 > = https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on-1 =20 =20 >[ = I-D.ietf-sidr-bgpsec-protocol is now RFC = 8205 (thanks for updating the reference). It has removed the = normative/any >reference to draft-ietf-idr-bgp-extended-messages. So = presumably BGP Sec does not need draft-ietf-idr-bgp->extended-messages. = Can we have an update on this? Can the introduction of = draft-ietf-idr-bgp-extended-messages >be updated to introduce on the = real reasons/needs? =20 SIDR gave up waiting on IDR=E2=80=99s work and took a reduced size of = encryption. The security people were very sad about the reduction. = How is this working in practice? WG sidrops can answer this question. =20 =20 The real problem is there is finite message space. =20 [Bruno] So too bad the draft does not solve the real problem ;-) (as = message space is still limited) =20 [Sue]: The message is still finite (smile), but I hope 65,635 (smile) = is probably enough for 10 years. =20 =20 There are two ways to send lots of BGP routes and/or attributes = =E2=80=93 to =E2=80=9Cchunk=E2=80=9D these into small message sizes or = place these into a large message. Some applications may always want = to =E2=80=9Cchunk=E2=80=9D into message sizes smaller than 4096. Some = application make work more efficiently utilizing large message size. As = the potential number of NLRI and BGP attributes grows, new applications = may consider large message sizes to a more reasonable way to exchange = amounts of BGP data. =20 =20 The decision on how to send BGP messages over the wire is a peer-by-peer = decision in a network. Each BGP peer is in charge of reformatting the = BGP message it sends to the remote BGP peer. The BGP capabilities in = this draft represent an agreement between two BGP peers. These are = facts of basic BGP implementations [Bruno] Let=E2=80=99s take the example of a BGP Route Reflector having a = mixed of clients, some supporting Extend Message (EM) and some not. >From an EM client, it receives a BGP update containing one (single) NLRI = with an Total Path Attribute Length bigger than 4090 byte (e.g. having = 1000 large communitiess) Can you explain me how it behaves to send this NLRI to an IBGP peer not = supporting EM? [Sue]: Gladly=E2=80=A6=20 A BGP route reflector (RR-A) is peering with each of its BGP clients. = It agrees with each of its clients (BGP-C1, BGPC2, BGPC3) whether the = BGP Extended messages is accepted or not (based on capability = announcement).=20 Let us assume that BGP-C1 does not support extended messages, and = BGP-C2 and BGP-C3 do support extended messages.=20 =20 If the policy in RR accepts a total path length of 1000 large = communities with a single NLRI, it may send the BGP attribute via = extended communities to BGP-C2 and BGP-C2. The policy in the RR must specify whether:=20 a) the =E2=80=9Ctoo long=E2=80=9D attribute path length must be = dropped, or=20 b) the BGP attribute path can be truncated.=20 =20 This is a policy issue within the BGP peer and the network operation = staff. Each operator may choose to write this policy differently.=20 =20 Rather than specify the numerous cases in the protocol specification, = the previous discussions (private and public) asked us to trim this = information out of the protocol specification.=20 =20 If you believe this is worthy of a use case draft for the sake of BESS, = LSVR, SPRING, Grow and others, I will happily WG chair sponsor a draft = that can be reviewed by all these WGs.=20 =20 =20 =E2=80=93 so I do not believe adding these facts to Randy=E2=80=99s = draft is useful. In fact, in the previous rounds of review this point = was made.=20 =20 Your question (and perhaps Jakob=E2=80=99s) is whether we have reached a = time/place where the =E2=80=9Cchunking=E2=80=9D approach will fail on a = peer-by-peer basis? This draft does not make this statement. =20 =20 The point of this draft is to enable more efficient processing by = increasing the message size for BGP peers that send a lot of data (e.g. = BGP-LS) . The choice to =E2=80=9Cchunk=E2=80=9D or stream in large BGP = message is an implementation choice for a particular BGP application. =20 =20 ---- =C2=A74 =C2=A73 says =E2=80=9CA peer which does not advertise this capability = MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to = it.=E2=80=9D [I believe randy accepted this change with the following text in version = 4 [upcoming below]]/.=20 =20 -------------- =20 Fine. Text in =C2=A74 should probably be aligned with the above ..e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. =20 NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and = received the Extended Message Capability to and from that peer. =20 =20 ---- >=E2=80=9C Applications generating information which might be = encapsulated > within BGP messages MUST limit the size of their payload to take the > maximum message size into account.=E2=80=9D >=20 >I don=E2=80=99t see what new behavior is been defined here. If there is = none, I would suggest to remove this sentence =20 Bruno =E2=80=93 people asked to put this text in as an operational = warning. At this point, I=E2=80=99m going to say unless there is harm = it should remain. =20 [Bruno] OK. =20 ---- > A BGP announcement will, in the normal case, propagate throughout = the > BGP speaking Internet; and there will undoubtedly be BGP speakers > which do not have the Extended Message capability. Therefore, > putting an attribute which can not be decomposed to 4096 octets or > less in an Extended Message is a likely path to routing failure. >=20 >The issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than >4096, irrespective of the size = of each attribute. >Please elaborate on what you mean by=20 >=20 >=E2=80=9Can attribute which cannot be decomposed to 4096 = octets=E2=80=9D =20 An attribute which cannot be decomposed to 4096 is an attribute with = length 6000 inside of a BGP message which requires the entire attribute = to be included. No such attribute exists today. If a small BGP peers = create a =E2=80=9Ckiller application=E2=80=9D that uses a 6000 byte = attribute, the rest of the Internet does not have to use it. However, = the person defining that attribute must carefully specify it must go = with Extended BGP messages.=20 =20 =20 [Bruno] I don=E2=80=99t think that I agree with this. E.g. I = don=E2=80=99t see where RFCs 1997 or 8092 [(large)community] limits the = size of their attribute. Hence I don=E2=80=99t see why you could not = have, today (with Extended Message support) , attributes larger than = 4096 octets. Most probably same status for the BGPSec attribute since = they wanted for more space. [Sue]: You make a good point about the possibility of large communities = not limiting the size. It is worthy of a change to both the large = communities and a footnote in Randy=E2=80=99s specification. How about = the addition of a single sentence to point people in the right = direction.=20 =20 Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed = if it=20 sent in Extended message is a large community attribute with 1000 = communities.=20 (12,000 bytes). =20 / =20 =20 This text was added during an earlier discussion where the error cases = of a large BGP attribute was given. The originator of the common could = not provide the exact description, but we agreed to put this = =E2=80=9Cwarning label=E2=80=9D into the draft. This is one of the = cases where adding/removing text gets to be problematic.=20 =20 >--- >=E2=80=9C It is RECOMMENDED that BGP protocol developers and = implementers are > conservative in their application and use of Extended = Messages.=E2=80=9D >=20 >What does this mean exactly? That they don=E2=80=99t use this = extension?=20 >That they don=E2=80=99t use this extension unless XX_TO BE = SPECIFIED_XX? =20 This warning was text that other participants asked to be added.=20 =20 It is a common sense warning. Extended messages are enabled on a peer = by peer basis as all BGP capabilities are. If you run into a Peer that = does not support the larger sizes, the BGP messages will need to be = reformatted to the smaller size. Running immediately to the Extended = messages as the default could cause problems..=20 =20 [Bruno] I think that the sentence could be elaborated. Indicating the = problem, how the specification partially address it, and how the = specification does not address it. In =E2=80=9CRunning immediately to Extended Message=E2=80=9D I = don=E2=80=99t think they that the issue is with = =E2=80=9Cimmediately=E2=80=9D. Whenever you start the transition, your = likely to run into problems. =20 =20 [Sue]: IMHO specification specifies how to encode the bytes on the wire = and the appropriate error handling of the messages. If I have missed = something in this case, please let me know.=20 =20 The specification does not specify the necessary policies implementation = should have in order to decide what to do in the case of mixed network. = The clear indication was this type was not appropriate for the protocol = specification. =20 =20 Earlier discussion indicated that these is policy and mechanism = specific. It is worthy of =E2=80=9Cuse case or application = notes=E2=80=9D written for specific applications (BESS, SPRING, GROW), = but not in the specification. Again, if it is significant enough = concern for operators and implementers =E2=80=93 it would be worthy to = have combined use case document besides this point. I=E2=80=99m happy = to sponsor cross-area work on this use case.=20 =20 --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages. =20 >Why is this limited to future specifications? A priori, using existing = BGP mechanism (AFI/SAFI, attributes, * >communities) one could exceed = the size of 4096 octets. How does the BGP speaker supposed to behave in = this ?>case? This should be described in this specification. Note that = this is not a case of error handling, as every BGP=20 > speaker is behaving as specified. =20 I fail to see your logic. At this point, all BGP data (AFI/SAFI and = attributes) must fit within a 4096 message. Therefore, a BGP peer A = which connects on link 1 to BGP peer B with 4096 message and on link to = a BGP peer C with extended messages only has to worry about reformatting = the data. =20 =20 In the future, the first group that defines attribute or an NLRI that = does not fit within a 4096 BGP message and cannot be split, will need to = define how that works in the specification. There is no need to refine = the current set of specifications. =20 [Bruno] 1) cf above, I believe that there are existing BGP Attributes which may = not fit into a bytes 4096 BGP message 2)Even in the absence of such attribute, you have the issue of 2 smaller = attributes whose cumulative size does not fit into a 4096 bytes message. =20 The problem is introduced by this specification, hence I believe this = specification needs to specify how to handle this case. =20 [Sue]: IHMO the message transmission and reception error handling = issues are complete in the combination of RFC4271 and the extended = message section 5.=20 =20 What is not in this specification is the policy issues about what = happens if you combine 2 smaller attributes. For example, if you have a = large community attribute of 400 communities (4800 bytes), you will = likely run into problems when combining with some longer AS path = lengths. [4800=C3=A0 5096 bytes is a short jump]. People on the list = and in-person argued this was policy and implementation specific = details. =20 =20 I agree with you that it is extremely useful to the operator community = to have this type of policy details discussed to see if there is some = desire to have common policies and error communities. It is the type = of thing that GROW and IDR should be deeply involved for large = communities. BESS, LSVR, SPRING and others should consider what policy = should be adapted for their applications.=20 =20 >---- >Depending on the above specification, a section describing the = operational consequences in a network (such as the >Internet, BGP = Enabled ServiceS/VPN networks) is probably needed. Possible consequences = could be BGP NLRI >being removed in the middle of such network, or = (extended) community (such as Route Targets) been removed. >Both having = significant consequences on the availability provided by the network. =20 At this point, there are no attributes or NLRI groupings that do not fit = within 4096. If you define one (as SIDR did), then you will need to = have it reviewed by IDR, BESS, SPRING, and operational groups (GROW, = etc).=20 [Bruno] no, cf above. [Sue]: Thank you for reminding me of the potential of large communities = to blow up BGP. I have a new worry to add to my BGP concerns list!=20 =20 Thanks, --Bruno =20 =20 --- >=C2=A74 >OLD: The Extended Message Capability only applies to all messages = except for the >OPEN message.=20 >Probably >NEW: The Extended Message Capability applies to all message types = except for the >OPEN message (type 1).=20 >---- >=C2=A78 >=E2=80=9CThis extension to BGP does not change BGP's underlying = security issues =C2=BB >Before evaluating this, I think this document should first specified = how a BGP=20 >messages bigger than 4096 octets is handled when it needs to be sent to = a=20 >received not supporting this extension. =20 Nits: >OLD : to reduce compexity >NEW : to reduce complexity =20 Thanks, --Bruno =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org =20 Subject: [Idr] WG Last Call on Extened Message Support =20 =20 This begins a 2 week WG LC on Extended Message Support for BGP = (draft-ietf-idr-bgp-extended-messages-27). You can access the draft at: = =20 = = https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ =20 The authors should indicate whether they know of any IPR. Implementers = are encouraged to update the implementation data at:=20 =20 = = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implement= ations =20 The draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages. BGP message space is running = short for all of the potential attributes or additions proposed by = BGP-LS features. =20 =20 The WG chairs intend to forward this draft to the IESG with the current = level of implementation. =20 =20 As you comment on the draft, please consider if: a) the technology is = mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for = publication. =20 =20 Sue Hares (WG Chair, Shepherd)=20 =20 =20 _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_0235_01D4C9D1.53BED470 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Jakob and Robert:

 

Thanks to = Bruno=E2=80=99s proposed code =E2=80=93 I think I understand = Bruno=E2=80=99s concerns.=C2=A0 Would you read my response and the = proposed text changes.=C2=A0 =C2=A0Let me know if my proposed changes to = section 5 and 9 of Randy=E2=80=99s draft address your concerns. =

 

If so, I will start a = specific all on those additions to the draft.

 

Thanks for your patience = with me,

 

Susan = Hares

 

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz = (jheitz)
Sent: Friday, February 15, 2019 8:02 PM
To: = Robert Raszuk; Susan Hares
Cc: Bruno Decraene; idr@ietf. = org
Subject: Re: [Idr] WG Last Call on Extened Message = Support

 

This = is a show stopper for me too.

 

One way to solve it would be to restrict the = extended messages to new address families only.

Any new address family would then need to specify = that it must support extended messages,

such that all implementations of the new address = family must support the extended messages.

 

Regards,

Jakob.

 

[Bruno] = Let=E2=80=99s take the example of a BGP Route Reflector having a mixed = of clients, some supporting Extend Message (EM) and some = not.

From an EM client, it receives a BGP update = containing one (single) NLRI with an Total Path Attribute Length bigger = than  4090 byte (e.g. having 1000 large = communitiess)

Can you explain me = how it behaves to send this NLRI to an IBGP peer not supporting = EM?

 

 

From: Idr <idr-bounces@ietf.org> On = Behalf Of Robert Raszuk
Sent: Friday, February 15, 2019 = 1:34 AM
To: Susan Hares <shares@ndzh.com>
Cc: = Bruno Decraene <bruno.decraene@orange.com>; idr@ietf. org = <idr@ietf.org>
Subject: Re: [Idr] WG Last Call on = Extened Message Support

 

Dear Sue & authors of this = proposal,

 

> = Therefore, putting an attribute which cannot be decomposed = to 

> = 4096 octets or less in an Extended Message is a likely path = to 

> = routing failure.

 <= /o:p>

That's = brilliant statement but not enough to proceed with this = spec. 

 <= /o:p>

See the = fundamental change that today such issue is in vast majority of cases = locally significant. That means that if I send NLRI to BGP it will have = a decent chance to be received by all intended = parties. 

 <= /o:p>

With = new spec we are saying that it may silently fail somewhere in the middle = and we do not do anything about it. That's to me = showstopper. 

 <= /o:p>

At min = if given NLRI can not be sent with XXL attributes to some peers (say on = the RR which Bruno mentioned) we must specify protocol extension in = this very spec on how to deal with it. 

 <= /o:p>

Such = extension may be as simple as to define a short attribute = BGP_PIPE_TOO_THIN which will be inserted in the place where XXL = attribute just did not fit smaller message size peers to tell them then = "Hey something is broken with this NLRI" - pls check. Then it = will be up to local policy to install such NLRI or drop = it. 

 <= /o:p>

Thx,
R.

 

 

On = Thu, Feb 14, 2019 at 6:21 PM Susan Hares <shares@ndzh.com> = wrote:

Bruno:

 

Thank you for careful considerations on the use = case.   I think we have translation issues between our = =E2=80=9CEnglish=E2=80=9D language again so I have tried to be precise = in the detailed comments.  I=E2=80=99ve summarized my comments as = well to help us take the next step.

 

Sue

 

Summary

----

Good catch on the 1000 large BGP communities = blowing up the message size!  This is a case where a code path = could get caught with program error..  The error handling (section = 6.1 in RFC4271 per section 5 in the extended specification) IMHO handles = the case where the attribute is longer than the message.  =  Please let me know if I=E2=80=99ve missed something. =   

 

As I understand it,  you are asking this = specification to be expanded to add notes on policies on what = implementation should do to correctly combine RFC4271 length sizes with = extended length sizes.   The implementers and operations = people commented earlier that this should not be in the protocol = specification other than as a brief footnote.  =

 

I agree there is a need for such standardization = as BCPs for particular use cases (large communities, BESS (EVPN or = centralized controller), SPRING, BGP-LS information (see Daylight = comments yesterday), SD-WANs (rtgwg), and SPRING.   I think = the chairs of the WGs utilizing should consider if there is need for = standardization for a minimal set of policy for message sizes for = specific use cases.   I will be glad to send request to these = WG or to host something in IDR if there is policy that can be used = across all use cases.

 

To provide a slight expansion to point people in = this direction, how about this change to paragraph in section 4: =

 

Old/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which can not be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

/

New/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which cannot be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

   One example of a valid attribute which = cannot be precisely decomposed if it

   sent in Extended message is a large = community attribute with 1000 communities.

   (12,000 bytes).  =

/

[PS = =E2=80=93 in American English =E2=80=9CCan not=E2=80=9D is normally = concatenated =E2=80=9Ccannot=E2=80=9D.]

   

 

 

 

From:= = bruno..decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: = Thursday, February 14, 2019 3:29 AM
To: Susan = Hares
Cc: idr@ietf.org; 'Jakob Heitz = (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message = Support

 <= /o:p>

Sue,

 

Thanks for the reply. Please see inline = [Bruno]

 

From:= Susan = Hares [mailto:shares@ndzh.com]
Sent: Wednesday, = February 13, 2019 8:03 PM
To: DECRAENE Bruno = TGI/OLN
Cc: idr@ietf.org; 'Jakob Heitz = (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message = Support

 

Bruno:

 

I=E2=80=99d like to answer some of = the questions you sent Randy based on comments (public and private) the = chairs and I as the shepherd received on this draft in our last WG LCs. =   

 

Several of the comments you = questioned were put in to answer other questions.   This gets = into a catch-22=E2=80=A6 problem =E2=80=93 where you put changes in for = one person/take out the changes out for another.  In academic = circles this is called the reviewer #2 problem (reviewer 1 insists = changes go in, reviewer 2 insists changes go out) during = publication.  Therefore, I=E2=80=99m I am going to answer most of = your questions where this is the case. 

 

I believe that Randy has new = version with the changes I=E2=80=99ve indicated.  I=E2=80=99m = hoping he=E2=80=99ll just post that version.  AFAILK, we do have 2 = compliant implementations.

 

Sue

 

 

 

<shepherd hat on> =

This draft=E2=80=99s technology = provides efficient processing for some application by allow a huge BGP = message size.  Whether =E2=80=9Cchunking=E2=80=9D BGP to 4096 byte = messages or packing large amounts of data into 65,000 byte message is = more effective for a particular application is something only an = implementer of a particular BGP implementation  can decide.. =   This draft simply gives freedom for applications to not be = restrict to an artificially small message size.  The market place = will choose whether this technology is used or = not. 

 

As Jakob pointed out, changing a = highly tuned BGP implementation which =E2=80=9Cchunks=E2=80=9D BGP data = into 4096 byte messages may involve substantial rework of the = implementation. 

 

 

(snip) =

From: Idr <idr-bounces@ietf.org> On Behalf Of bruno.decraene@orange.com
Sent: 29 = January 2019 13:33
To: Susan Hares <shares@ndzh.com>
Cc: idr@ietf.org
Subject: Re: [Idr] WG Last = Call on Extened Message Support

 

Hi = WG,

 =

>Please find = below some comments.

>As of today, = I don=E2=80=99t believe this specification is ready to be progressed to = IESG/RFC, especially for a document >updating RFC 4271 (core BGP = spec).

 

&= gt; The WG chairs intend to forward this draft to the IESG with the = current level of implementation. 

 

>https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-= extended->implementations says : 5a =

Does not = send Extended Message capability

Yes =

Yes =

Yes =

 

>I may be = misunderstanding the implementation report, but my reading of the above = is that none of the reported >implementations sends the capability = hence no implementation supports draft-ietf-idr-bgp-extended-messages.. =

>Here this = document is updating RFC 4271, so it is not a minor extension for a = niche use case. So I don=E2=80=99t see the >arguments for not requiring the = IDR=E2=80=99s usual two interoperable = implementations.

 

>In our mail thread, we = discovered that the implementation report should have = indicate

>full support.   = I=E2=80=99m waiting for Olivier to update based on the last point, but = my understanding is that

All implementations have full = support.  

 

[Bruno] ok, = solved

>----

>=C2=A7 = 1

>=E2=80=9C As BGP is = extended to support newer AFI/SAFIs and

>   newer = capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there = is

>   a need = to extend the maximum message size beyond 4096 octets.  = =E2=80=9C

> 

> https://tools.ietf.org/html/draft-ietf-idr-bgp-extended= -messages-27#section-1

 

 

>[I-D.ietf-sidr-bgpsec-protocol is now RFC = 8205 (thanks for updating the reference). It has removed the = normative/any >reference to = draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not = need draft-ietf-idr-bgp->extended-messages. Can we have an update on this?  Can the introduction of draft-ietf-idr-bgp-extended-messages >be = updated to introduce on the real = reasons/needs?

 

SIDR gave up waiting on = IDR=E2=80=99s work and took a reduced size of encryption.   = The security people were very sad about the reduction.  How is this = working in practice? WG sidrops can answer this question.  =

 

The real problem is there is finite = message space. 

[Bruno] So too bad the draft does not solve the = real problem ;-) (as message space is still = limited)

 

[Sue]: The message is still finite (smile), =  but I hope 65,635 (smile) is probably enough for 10 years.  =  

 

There are two ways to send lots of = BGP routes and/or attributes =E2=80=93 to =E2=80=9Cchunk=E2=80=9D these = into small message sizes or place these into a large = message.    Some applications may always want to = =E2=80=9Cchunk=E2=80=9D into message sizes smaller than 4096.  =  Some application make work more efficiently utilizing large = message size.  As the potential number of NLRI and BGP attributes = grows, new applications may consider large message sizes to a more = reasonable way to exchange amounts of BGP data.   =  

 

The decision on how to send BGP = messages over the wire is a peer-by-peer decision in a network.  =  Each BGP peer is in charge of reformatting the BGP message it = sends to the remote BGP peer.   The BGP capabilities in this = draft represent an agreement between two BGP peers.  These are = facts of basic BGP implementations

[Bruno] Let=E2=80=99s take the example of a BGP = Route Reflector having a mixed of clients, some supporting Extend = Message (EM) and some not.

From an EM client, it receives a BGP update = containing one (single) NLRI with an Total Path Attribute Length bigger = than  4090 byte (e.g. having 1000 large = communitiess)

Can you explain me how it behaves to send this = NLRI to an IBGP peer not supporting EM?

[Sue]:  Gladly=E2=80=A6 =

A BGP route reflector (RR-A) is peering with = each of its BGP clients.   It agrees with each of its clients = (BGP-C1, BGPC2, BGPC3) whether the BGP Extended messages is accepted or = not (based on capability announcement).

Let us assume that BGP-C1 does not support = extended messages, and  BGP-C2 and BGP-C3 do support extended = messages.

 

If the policy in RR accepts a total path length = of 1000 large communities with  a single NLRI, it may send the BGP = attribute via extended communities to BGP-C2 and = BGP-C2.

The policy in the RR must specify whether: =

a)      = the =E2=80=9Ctoo long=E2=80=9D = attribute path length must be dropped, or =

b)      = the BGP attribute path can be = truncated.

 

This is a policy issue within the BGP peer and = the network operation staff.  Each operator may choose to write = this policy differently.

 

Rather than specify the numerous cases in the = protocol specification,  the previous discussions (private and = public) asked us to trim this information out of the protocol = specification.

 

If you believe this is worthy of a use case = draft for the sake of BESS, LSVR, SPRING, Grow and others, I will = happily WG chair sponsor a draft that can be reviewed by all these WGs. =

 

 

=E2=80=93 so I do not believe adding these facts = to Randy=E2=80=99s draft is useful.  In fact, in the previous = rounds of review this point was made.

 

Your question (and perhaps Jakob=E2=80=99s) is = whether we have reached a time/place where the = =E2=80=9Cchunking=E2=80=9D approach will fail on a peer-by-peer basis? =   This draft does not make this statement.  =

 

The point of this draft is to enable more = efficient processing by increasing the message size for BGP peers that = send a lot of data (e.g. BGP-LS) .   The choice to = =E2=80=9Cchunk=E2=80=9D or stream in large BGP message is an = implementation choice for a particular BGP application.  =

&= nbsp;

----

=C2=A74

=C2=A73 says =
=E2=80=9CA peer which does not advertise this capability MUST NOT =
send BGP

   Extended Messages, and BGP Extended Messages MUST NOT = be sent to it.=E2=80=9D

[I believe randy accepted this change with the = following text in version 4 [upcoming below]]/.

 

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

&= nbsp;

F= ine. Text in =C2=A74 should probably be aligned with the above = ..e.g.

OLD: A BGP =
speaker

   MAY = send Extended Messages to its peer only if it has received = the

   = Extended Message Capability from that peer.

&= nbsp;

N= EW:

A BGP = speaker

   MAY = send Extended Messages to its peer only if it has sent and received = the

   = Extended Message Capability to and from that = peer.

 

 

----

>=E2=80=9C&n=
bsp;  Applications generating information which might be =
encapsulated

>   within = BGP messages MUST limit the size of their payload to take = the

>   = maximum message size into account.=E2=80=9D

> 

>I = don=E2=80=99t see what new behavior is been defined here. If there is = none, I would suggest to remove this sentence

 

Bruno =E2=80=93 people asked to put this text in = as an operational warning.  At this point, I=E2=80=99m going to say = unless there is harm it should remain. 

[Bruno] OK.

&= nbsp;

-= ---

>   A BGP = announcement will, in the normal case, propagate throughout = the

>   BGP = speaking Internet; and there will undoubtedly be BGP = speakers

>   which = do not have the Extended Message capability.  = Therefore,

>   = putting an attribute which can not be decomposed to 4096 octets = or

>   less = in an Extended Message is a likely path to routing = failure.

>&= nbsp;

>T= he issue is not specific to attributes bigger than 4096 octets, but to = BGP message whose length is bigger than >4= 096, irrespective of the size of each attribute.

>P= lease elaborate on what you mean by

> 

>=E2= =80=9Can attribute which cannot be decomposed to 4096 = octets=E2=80=9D

 

An attribute which cannot be decomposed to 4096 = is an attribute with length 6000 inside of a BGP message which requires = the entire attribute to be included.   No such attribute = exists today.   If a small BGP peers create a =E2=80=9Ckiller = application=E2=80=9D that uses a 6000 byte attribute, the rest of the = Internet does not have to use it.   However, the person = defining that attribute must carefully specify it must go with Extended = BGP messages.

 

 

[Bruno] I don=E2=80=99t think that I agree with = this. E.g. I don=E2=80=99t see where RFCs 1997 or 8092 = [(large)community] limits the size of their attribute. Hence I = don=E2=80=99t see why you could not have, today (with Extended Message = support) , attributes larger than 4096 octets. Most probably same status = for the BGPSec attribute since they wanted for more = space.

[Sue]: You make a good point about the = possibility of large communities not limiting the size.  It is = worthy of a change to both the large communities and a footnote in = Randy=E2=80=99s specification.  How about the addition of a single = sentence to point people in the right direction. =

 

Old/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which can not be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

/

New/

   A BGP announcement will, in the normal = case, propagate throughout the

   BGP speaking Internet; and there will = undoubtedly be BGP speakers

   which do not have the Extended Message = capability.  Therefore,

   putting an attribute which cannot be = decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

   One example of a valid attribute which = cannot be precisely decomposed if it

   sent in Extended message is a large = community attribute with 1000 communities.

   (12,000 bytes).  =

/

  =

 

This text was added during an = earlier discussion where the error cases of a large BGP attribute was = given.  The originator of the common could not provide the exact = description, but we agreed to put this  =E2=80=9Cwarning = label=E2=80=9D into the draft.   This is one of the cases = where adding/removing text gets to be problematic. =

 

>-= --

>=E2=80=9C   It is RECOMMENDED that BGP protocol = developers and implementers are

>   = conservative in their application and use of Extended = Messages.=E2=80=9D

> 

>What does = this mean exactly? That they don=E2=80=99t use this extension? =

>That they = don=E2=80=99t use this extension unless XX_TO BE = SPECIFIED_XX?

 

This warning was text that other = participants asked to be added.

 

It is a common sense warning.  = Extended messages are enabled on a peer by peer basis as all BGP = capabilities are.  If you run into a Peer that does not support the = larger sizes, the BGP messages will need to be reformatted to the = smaller size.   Running immediately to the Extended messages = as the default could cause problems..

 

[Bruno] I think that the sentence could be = elaborated. Indicating the problem, how the specification partially = address it, and how the specification does not address = it.

In =E2=80=9CRunning immediately to Extended = Message=E2=80=9D I don=E2=80=99t think they that the issue is with = =E2=80=9Cimmediately=E2=80=9D. Whenever you start the transition, your = likely to run into problems.

 

 

[Sue]: IMHO specification specifies how to = encode the bytes on the wire and the appropriate error handling of the = messages.   If I have missed something in this case, please = let me know.

 

The specification does not specify the necessary = policies implementation should have in order to decide what to do in the = case of mixed network.   The clear indication was this type = was not appropriate for the protocol specification. =  

 

Earlier discussion indicated that these is = policy and mechanism specific.  It is worthy of =E2=80=9Cuse case = or application notes=E2=80=9D written for specific applications (BESS, = SPRING, GROW), but not in the specification.  Again, if it is = significant enough concern for operators and implementers =E2=80=93 it = would be worthy to have combined use case document besides this point. =    I=E2=80=99m happy to sponsor cross-area work on this = use case.

 

-= --

  = Future protocol specifications will need to describe how to = handle

   peers which can only accommodate 4096 octet = messages.

&= nbsp;

>Why is this = limited to future specifications? A priori, using existing BGP mechanism = (AFI/SAFI, attributes, * >communities) one could exceed the = size of 4096 octets. How does the BGP speaker supposed to behave in this = ?>case? This should be described = in this specification. Note that this is not a case of error handling, = as every BGP

> speaker is = behaving as specified.

 

I fail to see your logic.  At = this point, all BGP data (AFI/SAFI and attributes) must fit within a = 4096 message.   Therefore, a BGP peer A which connects on link = 1 to BGP peer B with 4096 message and on link to a BGP peer C with = extended messages only has to worry about reformatting the data.  =

 

In the future, the first group that = defines attribute or an NLRI that does not fit within a 4096 BGP message = and cannot be split, will need to define how that works in the = specification.  There is no need to refine the current set of = specifications.  

[Bruno]

1) cf above, I believe that there are existing = BGP Attributes which may not fit into a bytes 4096 BGP = message

2)Even in the absence of such attribute, you = have the issue of 2 smaller attributes whose cumulative size does not = fit into a 4096 bytes message.

 

The problem is introduced by this specification, = hence I believe this specification needs to specify how to handle this = case.

 

[Sue]:  IHMO the message transmission and = reception error handling issues are complete in the combination of = RFC4271 and the extended message section 5.

 

What is not in this specification is the policy = issues about what happens if you combine 2 smaller attributes.  For = example, if you have a large community attribute of 400 communities = (4800 bytes), you will likely run into problems when combining with some = longer AS path lengths.  [4800=C3=A0 5096 bytes is a short jump]. People on the list = and in-person argued this was policy and implementation specific = details. 

 

I agree with you that it is extremely useful to = the operator community to have this type of policy details discussed to = see if there is some desire to have common policies and error = communities.   It is the type of thing that GROW and IDR = should be deeply involved for large communities.   BESS, LSVR, = SPRING and others should consider what policy should be adapted for = their applications.

 

>-= ---

>D= epending on the above specification, a section describing the = operational consequences in a network (such as the >I= nternet, BGP Enabled ServiceS/VPN networks) is probably needed. Possible = consequences could be BGP NLRI >b= eing removed in the middle of such network, or (extended) community = (such as Route Targets) been removed. >B= oth having significant consequences on the availability provided by the = network.

 

At this point, there are no = attributes or NLRI groupings that do not fit within 4096.   If = you define one (as SIDR did), then you will need to have it reviewed by = IDR, BESS, SPRING, and operational groups (GROW, = etc). 

[Bruno] no, cf = above.

[Sue]:  Thank you for reminding me of the = potential of large communities to blow up BGP.  I have a new worry = to add to my BGP concerns list!

 

Thanks,

--Bruno

 

&= nbsp;

-= --

>=C2= =A74

>OLD: The Extended = Message Capability only applies to all messages except for the >OPEN message. =

>Probably

>NEW: The Extended = Message Capability applies to all message types except for the >OPEN message (type 1). =

>----

>=C2=A78

>=E2=80=9CThis extension to BGP does =
not change BGP's underlying security =
issues =C2=BB
>Before evaluating this, I think this =
document should first specified how a BGP 
>messages bigger than 4096 octets is =
handled when it needs to be sent to a 
>received not supporting this extension.

 

N= its:

>OLD : to = reduce compexity

>NEW : to = reduce complexity

 

T= hanks,

-= -Bruno

&= nbsp;

From:= Idr [mailto:idr-bounces@ietf.org] On Behalf Of = Susan Hares
Sent: Tuesday, January 29, 2019 12:33 = PM
To: idr@ietf.org
Subject: [Idr] WG Last Call = on Extened Message Support

 

&= nbsp;

T= his begins a 2 week WG LC on Extended Message Support for BGP = (draft-ietf-idr-bgp-extended-messages-27).  You can access the = draft at:

&= nbsp;

https://datat= racker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/=

&= nbsp;

T= he authors should indicate whether they know of any IPR.   = Implementers are encouraged to update the  implementation data at: =

&= nbsp;

https://trac.= ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations=

&= nbsp;

T= he draft provides a means for expanding the BGP message to 65535 octets = for all messages except OPEN messages.  BGP message space is = running short for all of the potential attributes or additions proposed = by BGP-LS features. 

&= nbsp;

T= he WG chairs intend to forward this draft to the IESG with the current = level of implementation. 

&= nbsp;

A= s you comment on the draft, please consider if: a) the technology is = mature, b) the additional space in a BGP message would be helpful for = those deploying BGP-LS or SR, and c) if the specification is ready for = publication. 

&= nbsp;

S= ue Hares (WG Chair, Shepherd)

&= nbsp;

 

__________________________________________=
_________________________________________________________________________=
______
 
Ce message et ses pieces jointes peuvent =
contenir des informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, exploites ou =
copies sans autorisation. Si vous avez recu ce message par erreur, =
veuillez le signaler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its attachments may =
contain confidential or privileged information that may be protected by =
law;
they should not be distributed, =
used or copied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange is not =
liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le =
detruire ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have received this =
email in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, =
Orange is not liable for messages that have been modified, changed or =
falsified.
Thank =
you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles =
d'alteration,
Orange decline =
toute responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This =
message and its attachments may contain confidential or privileged =
information that may be protected by =
law;
they should not be =
distributed, used or copied without =
authorisation.
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments.
As emails may be altered, Orange is not liable for messages =
that have been modified, changed or =
falsified.
Thank =
you.

_______________________________________________
Idr = mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

------=_NextPart_000_0235_01D4C9D1.53BED470-- From nobody Fri Feb 22 00:39:23 2019 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4FF124C04; Fri, 22 Feb 2019 00:39:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <155082475531.5355.7762357803004800382@ietfa.amsl.com> Date: Fri, 22 Feb 2019 00:39:15 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ketant-idr-bgp-ls-flex-algo-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 08:39:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Flexible Algorithm Definition Advertisement with BGP Link-State Authors : Ketan Talaulikar Peter Psenak Shawn Zandi Gaurav Dawra Filename : draft-ketant-idr-bgp-ls-flex-algo-01.txt Pages : 10 Date : 2019-02-22 Abstract: Flexible Algorithm is a solution that allows routing protocols (viz. OSPF and IS-IS) to compute paths over a network based on user-defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distribute manner using a Flex Algorithm definition. This definition provisioned on one or more routers and propagated (viz. OSPF and IS- IS flooding) through the network. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. This draft defines extensions to BGP- LS address-family to advertise the Flexible Algorithm Definition as a part of the topology information from the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-flex-algo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ketant-idr-bgp-ls-flex-algo-01 https://datatracker.ietf.org/doc/html/draft-ketant-idr-bgp-ls-flex-algo-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ketant-idr-bgp-ls-flex-algo-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 22 00:54:16 2019 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 021EC126C15; Fri, 22 Feb 2019 00:54:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <155082565495.5492.7817684297639135919@ietfa.amsl.com> Date: Fri, 22 Feb 2019 00:54:14 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ketant-idr-bgp-ls-app-specific-attr-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 08:54:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Application Specific Attributes Advertisement with BGP Link-State Authors : Ketan Talaulikar Peter Psenak Jeff Tantsura Filename : draft-ketant-idr-bgp-ls-app-specific-attr-01.txt Pages : 13 Date : 2019-02-22 Abstract: Various link attributes have been defined in link-state routing protocols like OSPF and IS-IS in the context of the MPLS Traffic Engineering (TE) and GMPLS. BGP Link-State (BGP-LS) extensions have been defined to distribute these attributes along with other topology information from these link-state routing protocols. Many of these link attributes can be used for applications other than MPLS TE or GMPLS. Extensions to link-state routing protocols have been defined for such link attributes which enable distribution of their application specific values. This document defines extensions to BGP-LS address- family to enable advertisement of these application specific attributes as a part of the topology information from the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-app-specific-attr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ketant-idr-bgp-ls-app-specific-attr-01 https://datatracker.ietf.org/doc/html/draft-ketant-idr-bgp-ls-app-specific-attr-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ketant-idr-bgp-ls-app-specific-attr-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 22 01:09:24 2019 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DE9124D68; Fri, 22 Feb 2019 01:09:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <155082655580.5355.10854751851577418685@ietfa.amsl.com> Date: Fri, 22 Feb 2019 01:09:15 -0800 Archived-At: Subject: [Idr] I-D Action: draft-li-idr-bgp-ls-sbfd-extensions-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 09:09:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : BGP Link-State Extensions for Seamless BFD Authors : Zhenbin Li Sam Aldrin Jeff Tantsura Greg Mirsky Shunwan Zhuang Ketan Talaulikar Filename : draft-li-idr-bgp-ls-sbfd-extensions-03.txt Pages : 9 Date : 2019-02-22 Abstract: Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The link-state routing protocols (IS-IS and OSPF) have been extended to advertise the Seamless BFD (S-BFD) Discriminators. This draft defines extensions to the BGP Link-state address-family to carry the S-BFD Discriminators information via BGP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-li-idr-bgp-ls-sbfd-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-li-idr-bgp-ls-sbfd-extensions-03 https://datatracker.ietf.org/doc/html/draft-li-idr-bgp-ls-sbfd-extensions-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-li-idr-bgp-ls-sbfd-extensions-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 22 08:46:32 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92AF130F43 for ; Fri, 22 Feb 2019 08:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr68DRA3GEqt for ; Fri, 22 Feb 2019 08:46:14 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D61F130F3B for ; Fri, 22 Feb 2019 08:46:13 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 445cfq24Nwz7tYZ; Fri, 22 Feb 2019 17:46:11 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 445cfq0tBZzCqkc; Fri, 22 Feb 2019 17:46:11 +0100 (CET) Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM5D.corporate.adroot.infra.ftgroup ([fe80::8899:bbc3:9726:cd5e%22]) with mapi id 14.03.0435.000; Fri, 22 Feb 2019 17:46:11 +0100 From: To: Susan Hares CC: "idr@ietf.org" , 'Robert Raszuk' Thread-Topic: [Idr] WG Last Call on Extened Message Support Thread-Index: AQJ3UJ5j1bTPsyO86K1JuAQ7q/LpfQIdyv9rAefZHwsB7dxHTgI7AvBBAac2MMMBU1Q3bAF8mWGhpD/wQyCAAc+fIA== Date: Fri, 22 Feb 2019 16:46:10 +0000 Message-ID: <5261_1550853971_5C702753_5261_459_1_53C29892C857584299CBF5D05346208A489E3592@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <007b01d4b7c6$5b002210$11006630$@ndzh.com> <16873_1548768802_5C505622_16873_491_9_53C29892C857584299CBF5D05346208A489AE8F1@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <024a01d4b7d8$f7925b90$e6b712b0$@olddog.co.uk> <4052_1548770128_5C505B50_4052_60_1_53C29892C857584299CBF5D05346208A489AEA6C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <01a201d4c3ce$b6e6df10$24b49d30$@ndzh.com> <17281_1550132953_5C6526D9_17281_161_1_53C29892C857584299CBF5D05346208A489D3D92@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <00c901d4c489$8f311830$ad934890$@ndzh.com> <31634_1550226311_5C669387_31634_352_1_53C29892C857584299CBF5D05346208A489D6640@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <021401d4c9f9$8629c0f0$927d42d0$@ndzh.com> In-Reply-To: <021401d4c9f9$8629c0f0$927d42d0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A489E3592OPEXCAUBM43corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG Last Call on Extened Message Support X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 16:46:30 -0000 --_000_53C29892C857584299CBF5D05346208A489E3592OPEXCAUBM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sue, Thank you for your reply. Overall, looks good to me. More inline [Bruno3] From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, February 21, 2019 4:24 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf.org; 'Robert Raszuk' Subject: RE: [Idr] WG Last Call on Extened Message Support Bruno: Thank you for your specific suggestion. It helps us work through the spec= ifics of the changes to the BGP specification. I do not see the text in d= raft-ietf-idr-bgp-extended-messages-28.txt changing section 6.3 of RFC4271.= I've included my understanding of how draft-ietf-idr-bgp-extended-messag= es-28.txt changes RFC4271 in the detailed comments below. Your suggestion to improve section 6.3 of RFC4271 to handle the case where = a BGP speaker peers with two different messages sizes (4096, 65,535) has op= erational merit. Would you mind this modification to you text: "A BGP speaker which peers with some peers with extended message capability= and other peers without extended message capability, MUST do both of the f= ollowing things: - The BGP speaker MUST support [RFC7606], and - The BGP speaker MUST handle a BGP Route (attribute, NLRI pair) t= hat is too large to be sent to a BGP peer without the extended message capa= bility using the "treat-as-withdraw" approach defined in [RFC7606]. The BGP speaker, MAY remove some BGP attributes which are eligible to use t= he Attribute discard approach [RFC7606]. " [Bruno3] Looks good to me. Thanks. One detail: IMHO, the text could be understood in two different ways: - a) Withdraw the NLRI on the sessions without the extended messag= e capability - b) Withdraw the NLRI on all sessions IMHO we want "a" (although I can live with "b"). In all cases I'd prefer th= at the specification clear this ambiguity. E.g. :s/ using the "treat-as-wit= hdraw" approach defined in [RFC7606]/ using, for this BGP peer, the "treat-= as-withdraw" approach defined in [RFC7606]. This would be added to section 5 of draft-idr-bgp-extended-messages-25.txt.= See my suggested RFC4271 text changes for a logical placement within RFC= 4271. [Bruno3] Looks good. If this change to your text is agreeable, then section 8 would need to chan= ge to: /New text for the end of section 8/ This draft requires support for RFC7606 update error handling and as such i= nherits the security considerations of RFC7606. This draft also recommends = BGP peers avoid such issues by using Authenticated Encryption with addition= al Data (AEAD) ciphers [RFC5116] and thus to discard messages that do not v= erify. It also recommends that IBGP peers all support extended message cap= ability and [RFC7606]. During the transition to deploy extended messages and RFC7606 on an IBGP cl= oud, operators should monitor any routes dropped as "treat as withdraw". One example of a RFC7606 attack profile using the extended message is if th= e remote attacker is able that to craft a large BGP route to send along a B= GP path in which at least one peer does not support extended messages. This= peer which does not support extended message capability may encounter a dr= ain on internal resources (processing, message sizes) if it continually ref= ormats the large messages. If the "treat as withdraw" feature of RFC7606 i= s utilized, some routes may be consistently withdrawn at this point causing= inconsistent routing. BGP routes are filtered by policies set by the operators. Implementations = may provide policies to filter routes that would cause the "treat as withdr= aw" from being pass by an extended message speaker. [Bruno3] + "Network operators may enable such policies on EBGP sessions" (as enabling this on IBGP session does not provide improvement compared to = the default "treat as withdraw".) And I would rather move that sentence at the end of the first paragraph. As= this solution is only useful when the recommended approach is not used (de= ploy first on all IBGP sessions, then you can use large message within the = AS and/or enable extended message capability over EBGP sessions" / Please let me know I understand your suggested changes. [Bruno3] Looks good. Thanks Sue Hares From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.= com Sent: Friday, February 15, 2019 5:25 AM To: Susan Hares Cc: idr@ietf.org; Robert Raszuk Subject: Re: [Idr] WG Last Call on Extened Message Support Susan, We now agree that the problem can happen with existing BGP attributes. Good= . So the argument to postpone the error handling discussion for future spec= ification defining large attributes does not hold anymore. Coming back to the draft, Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. 1) As a minor comment, the error is not limited to an (one single) att= ribute (type) which size is bigger than 4096 octets. The error happens when= the Total Path Attribute Length (for all attributes) is bigger than 4096 o= ctets. [Sue]: My understanding of the Extended message draft is that it is not dea= ling with section 6.3 of RFC4271. [Bruno3] I agree. Section 6.3 of RFC4271 handles error when receiving a BGP= update message. While BGP Extended Message create error when sending a BGP= update message. My comment was not related to section 6.3 or RFC 4271, but to the text of d= raft-ietf-idr-bgp-extended-messages which I have cited above. I don't see w= hat could be unclear in my comment. Here's my understanding of the RFC4271 states: "All Errors detected while processing the Message header must be indicated = by sending a NOTIFICATION message with the Message Header error. The Error= subcode elaborates on the specific nature of the error. " One of the errors is a message header length: "If the length field of the = message header is less than 19 or greater than 4096." If any of these supe= r large attributes causes the message length to be greater than 4096, then = with RFC4271, the error code sent would be "Bad Message length." If the message length is switch from 4096 to 65535 octets, the RFC4271 erro= r handling would allow the message length to be 65,535. After the section 6.1 text RFC4271 is changed to the following: [Bruno3] Idem, section 6.1 of RFC4271 handles error when _receiving_ a BGP = update message. While draft-ietf-idr-bgp-extended-messages generate an erro= r condition when sending a BGP update. If at least one of the following is true: - If the Length field of the message header is less than 19 or gre= ater than 4096 for OPEN message, - If BGP Extended Messages capability is not set, the length field= of any other BGP message other than an OPEN message is less than 19 or gre= ater than 4095, - If the BGP Extended Message capability is set for a BGP peer, if= the length field is less than 19 or greater than 65,535. (See the error h= andling below for the setting of this function.) - If the length field of an UPDATE message is less than the minimu= m field of the UPDATE message, or - If the length field of a KEEPALIVE message is not equal to 19, or - If the length field of a NOTIFICATION message is less than the m= inimum length of the NOTIFICATION message. Then the Error Subcode MUST Be set to Bad Message Length. The Data field M= UST contain the erroneous length field. [ 6.9) Extended Message Capability To advertise the BGP Extended Message Capability to a peer, a BGP speaker uses BGP Capabilities Advertisement [RFC5492]. By advertising the BGP Extended Message Capability to a peer, a BGP speaker conveys that it is able to send, receive, and properly handle BGP Extended Messages. A peer which does not advertise this capability MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to it. The BGP Extended Message Capability is a new BGP Capability [RFC5492] defined with Capability code 6 and Capability length 0. 6.9.1) Operation: A BGP speaker that is capable of sending and receiving BGP Extended Messages SHOULD advertise the BGP Extended Message Capability to the peer using BGP Capabilities Advertisement [RFC5492]. A BGP speaker MAY send Extended Messages to its peer only if it has sent and received the Extended Message Capability from that peer. The Extended Message Capability applies to all messages except for the OPEN message. This exception is made to reduce complexity of providing backward compatibility An implementation that advertises support for BGP Extended Messages MUST be capable of receiving a message with a length up to and including 65535 octets. Applications generating information which might be encapsulated within BGP messages MUST limit the size of their payload to take the maximum message size into account. If a BGP update with a payload longer than 4096 octets is received by a BGP listener who has neither advertised nor agreed to accept BGP Extended Messages, the listener MUST treat this as a malformed update message, and MUST raise an UPDATE Message Error (see section 6.3). A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. [Bruno3] the error is not limited to an (one single) attribute (type) which= size is bigger than 4096 octets. The error happens when the Total Path Att= ribute Length (for all attributes) is bigger than 4096 octets It is RECOMMENDED that BGP protocol developers and implementers are conservative in their application and use of Extended Messages. 6.9.2 Error Handling for the Extended messages A BGP speaker that has the ability to use Extended Messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, SHOULD NOT accept an Extended Message. A speaker MAY implement a more liberal policy and accept Extended Messages, even from a peer to which it has not advertised the capability, in the interest of preserving the BGP session if at all possible. [Bruno3] The texts highlighted in blue are contradicting. I would suggest r= emoving the blue text from =A74 which the behavior is related to error hand= ling conditions described in section 5. (note that your coded text have cha= nged the section numbers. I'm referring to the section numbers in the draft) A BGP speaker that does not advertise the BGP Extended Messages capability might also genuinely not support Extended Messages. Such a speaker MUST follow the error handling procedures of section 6.1 regarding message length. [Bruno3] Agreed, but that text is not very logical: you can't define a new = behavior for an old speaker. At minimum, I would propose the following chan= ge: OLD: Such a speaker MUST follow the error handling procedures of section 6.1 regarding message length. NEW: Such a speaker will follow the error handling procedures of [RFC4271] section= 6.1 regarding message length. The inconsistency between the local and remote BGP speakers MUST be flagged to the network operator through standard operational interfaces. The information should include the NLRI and as much relevant information as reasonably possible. [End of text change from draft ] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2) As a major comment, I am asking for the specification to specify ho= w it handles that failure, which is not the result of a possible bug, but c= reated by design by the solution. It will happen. Your proposition to "raise an alarm" is required but not sufficient as we s= till need to specify what we do with this "big" route. One option could be = "treat as withdraw", another option suggested by Robert is to propagate the= NLRI with subset of attributes plus an indication of the failure ("a short= attribute BGP_PIPE_TOO_THIN"). There may be others options. [Sue]: Robert's option is a fine idea, but the WG did not accept this optio= n in the past so I cannot force this option into the specification. I hope= that Robert will propose this option again. [Bruno3] Agreed. I'm perfectly with "treat-as-withdraw" To trigger the discussion on the resolution, I would propose the following = text "One BGP Route too large to be propagated to a BGP receiver not suppor= ting BGP Extended Message MUST be handled, over this BGP session, using the= Treat-as-withdraw approach as defined in [RFC7606]. The BGP speaker MAY, b= eforehand, remove some BGP attributes which are eligible to the Attribute d= iscard approach [RFC7606]." [Sue]: This text deals with section 6.3 in RFC4271, and to my understandin= g draft-ietf-idr-bgp-extended-messges-28.txt only deals with section 6.1 of= RFC4271. [Bruno3] I disagree that the text deals with sections 6.3 or 6.1 of RFC 427= 1. Those sections refers to error handling or _received_ BGP update, while = draft-ietf-idr-bgp-extended-messages create error when _sending_ a BGP upda= te. In addition, there is no concept of propagation RFC7606 or RFC4271. Ea= ch BGP peer receives BGP messages and updates, it then propagates or sends = routes and attributes to its peers. Could I restate your suggestion as: 6.9.2 Error handling (added at the end of the current text A BGP speaker which peers with some peers with extended message capability = and other peers without extended message capability, MUST handle a BGP Rout= e (attribute, NLRI pair) that is too large to be sent to a BGP peer without= the extended message capability using the "treat-as-withdraw" approach def= ined in [RFC7606]. The BGP speaker, MAY remove some BGP attributes which a= re eligible to use the Attribute discard approach [RFC7606]. [Bruno3] point discussed at the top of you email. 3) Once error handling is specified, the draft will be able to discuss a. the operational considerations for this issue (e.g. The one from R= FC7606 could be referenced as-is, or used as inspiration) b. the security considerations (as a remote attacker would be able to = craft a large BGP route that will be withdrawn (assuming "treat-as-withdraw= ") somewhere in some AS, possibly creating routing inconsistencies within t= he AS) c. the proposed mitigations (e.g., an operator should enable support = for Extended messages on all IBGP sessions first, before enabling it on an = EBGP session; If not possible, an operator could define a policy to filter = BGP attributes from EBGP sessions, typically based on their type and size;.= ...) more inline [Bruno2] From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, February 14, 2019 6:20 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf.org; 'Jakob Heitz (jheitz)'; 'John Scudder'; 'Alvaro Retana' Subject: RE: [Idr] WG Last Call on Extened Message Support Bruno: Thank you for careful considerations on the use case. I think we have tra= nslation issues between our "English" language again so I have tried to be = precise in the detailed comments. I've summarized my comments as well to h= elp us take the next step. Sue Summary ---- Good catch on the 1000 large BGP communities blowing up the message size! = This is a case where a code path could get caught with program error. The = error handling (section 6.1 in RFC4271 per section 5 in the extended specif= ication) IMHO handles the case where the attribute is longer than the messa= ge. Please let me know if I've missed something. [Bruno2] I don't think that section 6.1 of RFC4271 covers this. The problem= is not a Message Header error handling as a proper BGP implementation woul= d not sent the message. (not to mention with inconsistent size). [Sue2]: OK, but section 6.1 is the only places that this draft changes. [Bruno3] points discussed above As I understand it, you are asking this specification to be expanded to ad= d notes on policies on what implementation should do to correctly combine R= FC4271 length sizes with extended length sizes. The implementers and oper= ations people commented earlier that this should not be in the protocol spe= cification other than as a brief footnote. [Bruno2]An error handling must exist even in the absence of SP policies. Th= e argument related to previous discussions does not hold IMHO as I've raise= d a new point (this happens with existing BGP attributes, not in a hypothet= ical new attribute) [Sue2]: Thank you for sending your text. I can your comments are on the U= PDATE handling processes based on RFC7606. We were discussing 2 different = places in RFC4271. I agree there is a need for such standardization as BCPs for particular use= cases (large communities, BESS (EVPN or centralized controller), SPRING, B= GP-LS information (see Daylight comments yesterday), SD-WANs (rtgwg), and S= PRING. I think the chairs of the WGs utilizing should consider if there i= s need for standardization for a minimal set of policy for message sizes fo= r specific use cases. I will be glad to send request to these WG or to ho= st something in IDR if there is policy that can be used across all use case= s. [Bruno2] I don't think that Error handling is to be considered as optional = or for future consideration. [Sue2]: Based on your proposed text, I can see the value of considering th= is text at this time. [Bruno3] Thanks for considering the error handling for new error conditions= introduced by draft-ietf-idr-bgp-extended-messages- --Bruno To provide a slight expansion to point people in this direction, how about = this change to paragraph in section 4: Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed if= it sent in Extended message is a large community attribute with 1000 commun= ities. (12,000 bytes). / [PS - in American English "Can not" is normally concatenated "cannot".] [Bruno2] Thanks for the proposition, but this does not address my concern. [Sue]: Thank you for your text - I understand why now. From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Thursday, February 14, 2019 3:29 AM To: Susan Hares Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support Sue, Thanks for the reply. Please see inline [Bruno] From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, February 13, 2019 8:03 PM To: DECRAENE Bruno TGI/OLN Cc: idr@ietf.org; 'Jakob Heitz (jheitz)' Subject: RE: [Idr] WG Last Call on Extened Message Support Bruno: I'd like to answer some of the questions you sent Randy based on comments (= public and private) the chairs and I as the shepherd received on this draft= in our last WG LCs.. Several of the comments you questioned were put in to answer other question= s. This gets into a catch-22... problem - where you put changes in for on= e person/take out the changes out for another. In academic circles this is= called the reviewer #2 problem (reviewer 1 insists changes go in, reviewer= 2 insists changes go out) during publication. Therefore, I'm I am going t= o answer most of your questions where this is the case. I believe that Randy has new version with the changes I've indicated. I'm = hoping he'll just post that version. AFAILK, we do have 2 compliant implem= entations. Sue This draft's technology provides efficient processing for some application = by allow a huge BGP message size. Whether "chunking" BGP to 4096 byte mess= ages or packing large amounts of data into 65,000 byte message is more effe= ctive for a particular application is something only an implementer of a pa= rticular BGP implementation can decide. This draft simply gives freedom = for applications to not be restrict to an artificially small message size. = The market place will choose whether this technology is used or not. As Jakob pointed out, changing a highly tuned BGP implementation which "chu= nks" BGP data into 4096 byte messages may involve substantial rework of the= implementation. (snip) From: Idr On Behalf Of bruno.decraene@orange..com Sent: 29 January 2019 13:33 To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on Extened Message Support Hi WG, >Please find below some comments. >As of today, I don't believe this specification is ready to be progressed = to IESG/RFC, especially for a document >updating RFC 4271 (core BGP spec). > The WG chairs intend to forward this draft to the IESG with the current l= evel of implementation. >https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended->implement= ations says : 5a Does not send Extended Message capability Yes Yes Yes >I may be misunderstanding the implementation report, but my reading of the= above is that none of the reported >implementations sends the capability h= ence no implementation supports draft-ietf-idr-bgp-extended-messages.. >Here this document is updating RFC 4271, so it is not a minor extension fo= r a niche use case. So I don't see the >arguments for not requiring the IDR= 's usual two interoperable implementations. >In our mail thread, we discovered that the implementation report should ha= ve indicate >full support. I'm waiting for Olivier to update based on the last point,= but my understanding is that All implementations have full support. [Bruno] ok, solved >---- >=A7 1 >" As BGP is extended to support newer AFI/SAFIs and > newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there is > a need to extend the maximum message size beyond 4096 octets. " > > https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#secti= on-1 >[I-D.ietf-sidr-bgpsec-protocol is now RFC 820= 5 (thanks for updating the reference). It has removed the normative/any >re= ference to draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does= not need draft-ietf-idr-bgp->extended-messages. Can we have an update on t= his? Can the introduction of draft-ietf-idr-bgp-extended-messages >be upda= ted to introduce on the real reasons/needs? SIDR gave up waiting on IDR's work and took a reduced size of encryption. = The security people were very sad about the reduction. How is this workin= g in practice? WG sidrops can answer this question. The real problem is there is finite message space. [Bruno] So too bad the draft does not solve the real problem ;-) (as messag= e space is still limited) [Sue]: The message is still finite (smile), but I hope 65,635 (smile) is p= robably enough for 10 years. There are two ways to send lots of BGP routes and/or attributes - to "chunk= " these into small message sizes or place these into a large message. So= me applications may always want to "chunk" into message sizes smaller than = 4096. Some application make work more efficiently utilizing large message= size. As the potential number of NLRI and BGP attributes grows, new appli= cations may consider large message sizes to a more reasonable way to exchan= ge amounts of BGP data. The decision on how to send BGP messages over the wire is a peer-by-peer de= cision in a network. Each BGP peer is in charge of reformatting the BGP m= essage it sends to the remote BGP peer. The BGP capabilities in this draf= t represent an agreement between two BGP peers. These are facts of basic B= GP implementations [Bruno] Let's take the example of a BGP Route Reflector having a mixed of c= lients, some supporting Extend Message (EM) and some not. >From an EM client, it receives a BGP update containing one (single) NLRI wi= th an Total Path Attribute Length bigger than 4090 byte (e.g. having 1000 = large communitiess) Can you explain me how it behaves to send this NLRI to an IBGP peer not sup= porting EM? [Sue]: Gladly... A BGP route reflector (RR-A) is peering with each of its BGP clients. It = agrees with each of its clients (BGP-C1, BGPC2, BGPC3) whether the BGP Exte= nded messages is accepted or not (based on capability announcement). Let us assume that BGP-C1 does not support extended messages, and BGP-C2 a= nd BGP-C3 do support extended messages. If the policy in RR accepts a total path length of 1000 large communities w= ith a single NLRI, it may send the BGP attribute via extended communities = to BGP-C2 and BGP-C2. The policy in the RR must specify whether: a) the "too long" attribute path length must be dropped, or b) the BGP attribute path can be truncated. This is a policy issue within the BGP peer and the network operation staff.= Each operator may choose to write this policy differently. [Bruno2] So we agree that a new behavior is REQUIRED. The draft does not me= ntion this. The ability to change the behavior by policy does not remove th= e need for specifying the error handling. Rather than specify the numerous cases in the protocol specification, the = previous discussions (private and public) asked us to trim this information= out of the protocol specification. [Bruno2] Can't be have a general rule which is good enough to handle the is= sue? Previous discussions seemed based on the fact the error condition woul= d happen for future attribute. This is not the case. If you believe this is worthy of a use case draft for the sake of BESS, LSV= R, SPRING, Grow and others, I will happily WG chair sponsor a draft that ca= n be reviewed by all these WGs. [Bruno2] I believe that this is worthy in this specification. - so I do not believe adding these facts to Randy's draft is useful. In fa= ct, in the previous rounds of review this point was made. Your question (and perhaps Jakob's) is whether we have reached a time/place= where the "chunking" approach will fail on a peer-by-peer basis? This dr= aft does not make this statement. The point of this draft is to enable more efficient processing by increasin= g the message size for BGP peers that send a lot of data (e.g. BGP-LS) . = The choice to "chunk" or stream in large BGP message is an implementation c= hoice for a particular BGP application. ---- =A74 =A73 says "A peer which does not advertise this capability MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to it." [I believe randy accepted this change with the following text in version 4 = [upcoming below]]/. -------------- Fine. Text in =A74 should probably be aligned with the above .e.g. OLD: A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. NEW: A BGP speaker MAY send Extended Messages to its peer only if it has sent and received = the Extended Message Capability to and from that peer. ---- >" Applications generating information which might be encapsulated > within BGP messages MUST limit the size of their payload to take the > maximum message size into account." > >I don't see what new behavior is been defined here. If there is none, I wo= uld suggest to remove this sentence Bruno - people asked to put this text in as an operational warning. At thi= s point, I'm going to say unless there is harm it should remain. [Bruno] OK. ---- > A BGP announcement will, in the normal case, propagate throughout the > BGP speaking Internet; and there will undoubtedly be BGP speakers > which do not have the Extended Message capability. Therefore, > putting an attribute which can not be decomposed to 4096 octets or > less in an Extended Message is a likely path to routing failure. > >The issue is not specific to attributes bigger than 4096 octets, but to BG= P message whose length is bigger than >4096, irrespective of the size of ea= ch attribute. >Please elaborate on what you mean by > >"an attribute which cannot be decomposed to 4096 octets" An attribute which cannot be decomposed to 4096 is an attribute with length= 6000 inside of a BGP message which requires the entire attribute to be inc= luded. No such attribute exists today. If a small BGP peers create a "k= iller application" that uses a 6000 byte attribute, the rest of the Interne= t does not have to use it. However, the person defining that attribute mu= st carefully specify it must go with Extended BGP messages. [Bruno] I don't think that I agree with this. E.g. I don't see where RFCs 1= 997 or 8092 [(large)community] limits the size of their attribute. Hence I = don't see why you could not have, today (with Extended Message support) , a= ttributes larger than 4096 octets. Most probably same status for the BGPSec= attribute since they wanted for more space. [Sue]: You make a good point about the possibility of large communities not= limiting the size. It is worthy of a change to both the large communities= and a footnote in Randy's specification. How about the addition of a sing= le sentence to point people in the right direction. Old/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which can not be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. / New/ A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore, putting an attribute which cannot be decomposed to 4096 octets or less in an Extended Message is a likely path to routing failure. One example of a valid attribute which cannot be precisely decomposed if= it sent in Extended message is a large community attribute with 1000 commun= ities. (12,000 bytes). / This text was added during an earlier discussion where the error cases of a= large BGP attribute was given. The originator of the common could not pro= vide the exact description, but we agreed to put this "warning label" into= the draft. This is one of the cases where adding/removing text gets to b= e problematic. >--- >" It is RECOMMENDED that BGP protocol developers and implementers are > conservative in their application and use of Extended Messages." > >What does this mean exactly? That they don't use this extension? >That they don't use this extension unless XX_TO BE SPECIFIED_XX? This warning was text that other participants asked to be added. It is a common sense warning. Extended messages are enabled on a peer by p= eer basis as all BGP capabilities are. If you run into a Peer that does no= t support the larger sizes, the BGP messages will need to be reformatted to= the smaller size. Running immediately to the Extended messages as the de= fault could cause problems. [Bruno] I think that the sentence could be elaborated. Indicating the probl= em, how the specification partially address it, and how the specification d= oes not address it. In "Running immediately to Extended Message" I don't think they that the is= sue is with "immediately". Whenever you start the transition, your likely t= o run into problems. [Sue]: IMHO specification specifies how to encode the bytes on the wire and= the appropriate error handling of the messages. If I have missed somethi= ng in this case, please let me know. [Bruno2] IMHO specifications need to handle error conditions that they crea= te by design. The specification does not specify the necessary policies implementation sh= ould have in order to decide what to do in the case of mixed network. The= clear indication was this type was not appropriate for the protocol specif= ication. Earlier discussion indicated that these is policy and mechanism specific. = It is worthy of "use case or application notes" written for specific applic= ations (BESS, SPRING, GROW), but not in the specification. Again, if it is= significant enough concern for operators and implementers - it would be wo= rthy to have combined use case document besides this point. I'm happy to= sponsor cross-area work on this use case. --- Future protocol specifications will need to describe how to handle peers which can only accommodate 4096 octet messages.. >Why is this limited to future specifications? A priori, using existing BGP= mechanism (AFI/SAFI, attributes, * >communities) one could exceed the size= of 4096 octets. How does the BGP speaker supposed to behave in this ?>case= ? This should be described in this specification. Note that this is not a c= ase of error handling, as every BGP > speaker is behaving as specified. I fail to see your logic. At this point, all BGP data (AFI/SAFI and attrib= utes) must fit within a 4096 message. Therefore, a BGP peer A which conne= cts on link 1 to BGP peer B with 4096 message and on link to a BGP peer C w= ith extended messages only has to worry about reformatting the data. In the future, the first group that defines attribute or an NLRI that does = not fit within a 4096 BGP message and cannot be split, will need to define = how that works in the specification. There is no need to refine the curren= t set of specifications. [Bruno] 1) cf above, I believe that there are existing BGP Attributes which may not= fit into a bytes 4096 BGP message 2)Even in the absence of such attribute, you have the issue of 2 smaller at= tributes whose cumulative size does not fit into a 4096 bytes message. The problem is introduced by this specification, hence I believe this speci= fication needs to specify how to handle this case. [Sue]: IHMO the message transmission and reception error handling issues a= re complete in the combination of RFC4271 and the extended message section = 5. What is not in this specification is the policy issues about what happens i= f you combine 2 smaller attributes. For example, if you have a large commu= nity attribute of 400 communities (4800 bytes), you will likely run into pr= oblems when combining with some longer AS path lengths. [4800--> 5096 byte= s is a short jump]. People on the list and in-person argued this was policy= and implementation specific details. [Bruno2] It's not implementation specific. This is an issue created by the = specification. Let's discuss it in public. I agree with you that it is extremely useful to the operator community to h= ave this type of policy details discussed to see if there is some desire to= have common policies and error communities. It is the type of thing that= GROW and IDR should be deeply involved for large communities. BESS, LSVR= , SPRING and others should consider what policy should be adapted for their= applications. >---- >Depending on the above specification, a section describing the operational= consequences in a network (such as the >Internet, BGP Enabled ServiceS/VPN= networks) is probably needed. Possible consequences could be BGP NLRI >bei= ng removed in the middle of such network, or (extended) community (such as = Route Targets) been removed. >Both having significant consequences on the a= vailability provided by the network. At this point, there are no attributes or NLRI groupings that do not fit wi= thin 4096. If you define one (as SIDR did), then you will need to have it= reviewed by IDR, BESS, SPRING, and operational groups (GROW, etc). [Bruno] no, cf above. [Sue]: Thank you for reminding me of the potential of large communities to= blow up BGP. I have a new worry to add to my BGP concerns list! [Bruno2] IMHO, the problem is more with Extended Message than with large co= mmunity. And we can work to consider and address this problem. --Bruno Thanks, --Bruno --- >=A74 >OLD: The Extended Message Capability only applies to all messages except f= or the >OPEN message. >Probably >NEW: The Extended Message Capability applies to all message types except f= or the >OPEN message (type 1). >---- >=A78 >"This extension to BGP does not change BGP's underlying security issues = =BB >Before evaluating this, I think this document should first specified how a= BGP >messages bigger than 4096 octets is handled when it needs to be sent to a >received not supporting this extension. Nits: >OLD : to reduce compexity >NEW : to reduce complexity Thanks, --Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 29, 2019 12:33 PM To: idr@ietf.org Subject: [Idr] WG Last Call on Extened Message Support This begins a 2 week WG LC on Extended Message Support for BGP (draft-ietf-= idr-bgp-extended-messages-27). You can access the draft at: https://datatracker.ietf..org/doc/draft-ietf-idr-bgp-extended-messages/ The authors should indicate whether they know of any IPR. Implementers ar= e encouraged to update the implementation data at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementat= ions The draft provides a means for expanding the BGP message to 65535 octets fo= r all messages except OPEN messages. BGP message space is running short fo= r all of the potential attributes or additions proposed by BGP-LS features. The WG chairs intend to forward this draft to the IESG with the current lev= el of implementation. As you comment on the draft, please consider if: a) the technology is matur= e, b) the additional space in a BGP message would be helpful for those depl= oying BGP-LS or SR, and c) if the specification is ready for publication. Sue Hares (WG Chair, Shepherd) ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A489E3592OPEXCAUBM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sue,

 <= /o:p>

Thank you fo= r your reply.

Overall, loo= ks good to me.

More inline = [Bruno3]

 <= /o:p>

= From: Susan Hares [mailto:shares@ndzh.com]
Sent: Thursday, February 21, 2019 4:24 PM
To: DECRAENE Bruno TGI/OLN
Cc: idr@ietf.org; 'Robert Raszuk'
Subject: RE: [Idr] WG Last Call on Extened Message Support

 

Bruno:

 

Thank you for your specific sugg= estion.   It helps us work through the specifics of the changes to the BGP specification.  I do not see the  text in draft-ietf-= idr-bgp-extended-messages-28.txt changing section 6.3 of RFC4271. &nbs= p; I’ve included my understanding of how draft-ietf-idr-bgp-extended-= messages-28.txt changes RFC4271 in the detailed comments below.      

 

Your suggestion to improve secti= on 6.3 of RFC4271 to handle the case where a BGP speaker peers with two different messages sizes (4096, 65,535) has operational merit. &n= bsp; Would you mind this modification to you text:

 <= /p>

“A BGP speaker whic= h peers with some peers with extended message capability and other peers without extended message capability, MUST do both of the following t= hings:

-   =        The BGP speaker MUST support [RFC7606], and

-   =        The BGP speaker MUST handle a BGP Route (attribute, N= LRI pair) that is too large to be sent to a BGP peer without the extended message capability using the “treat-as-withdraw” = approach defined in [RFC7606].

 =

The BGP speaker, MAY remove some= BGP attributes which are eligible to use the Attribute discard approach [RFC7606]. “  

[Bruno= 3] Looks good to me. Thanks.

One detail: IMHO, the text could be understood in two different ways:

-   =        -   =        IMHO we want “a” (although I can live with “b”). In all= cases I’d prefer that the specification clear this ambiguity. E.g. := s/ using the “treat= -as-withdraw” approach defined in [RFC7606]/ using, for this BGP peer, the “treat-as-withdraw” approach defined in [RFC7606].

 

This would be added to section 5= of draft-idr-bgp-extended-messages-25.txt.   See my suggested RFC4271 text changes for a logical placement within RFC4271. 

[Bruno= 3] Looks good.

 

If this change to your text is a= greeable, then section 8 would need to change to:

 

/New text for the end of section= 8/

 

This draft requires support for RFC7606 update erro= r handling and as such inherits the security considerations of RFC7606. This draft also recommends BGP peers avoid such issues by usin= g Authenticated Encryption with additional Data (AEAD) ciphers [RFC5116] an= d thus to discard messages that do not verify.  It also recommends tha= t IBGP peers all support extended message capability and [RFC7606]. 

 

During the transition to deploy extended messages a= nd RFC7606 on an IBGP cloud, operators should monitor any routes dropped as “treat as withdraw”. 

 

One example of a RFC7606 attack profile using the e= xtended message is if the remote attacker is able that to craft a large BGP route to send along a BGP path in which at least= one peer does not support extended messages. This peer which does not supp= ort extended message capability may encounter a drain on internal resources= (processing, message sizes) if it continually reformats the large messages.  If the “treat as = withdraw” feature of RFC7606 is utilized, some routes may be consiste= ntly withdrawn at this point causing inconsistent routing.

 

BGP routes are filtered by policies set by the oper= ators.  Implementations may provide policies to filter routes that would cause the “treat as withdraw” from being pas= s by an extended message speaker. 

[Bruno= 3] + “Network operators may enable such policies on EBGP sessions&#= 8221;

(as enabling this on IBGP session does not provide improvement compared to the= default “treat as withdraw”.)

And I would rather move that sentence at the end of the first paragraph. As th= is solution is only useful when the recommended approach is not used (deplo= y first on all IBGP sessions, then you can use large message within the AS = and/or enable extended message capability over EBGP sessions”

&= nbsp;

/

 

Please let me know I understand your suggested chan= ges.

[Bruno= 3] Looks good. Thanks<= o:p>

 

Sue Hares

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of bruno.decraene@orang= e.com
Sent: Friday, February 15, 2019 5:25 AM
To: Susan Hares
Cc: idr@ietf.org; Robert Raszuk
Subject: Re: [Idr] WG Last Call on Extened Message Support

 

Susan,

 

We now agree that the problem ca= n happen with existing BGP attributes. Good. So the argument to postpone the error handling discussion for future specification definin= g large attributes does not hold anymore.

 

Coming back to the draft,

 

Old/

   A BGP announcement will, in the normal c= ase, propagate throughout the

   BGP speaking Internet; and there will un= doubtedly be BGP speakers

   which do not have the Extended Message c= apability.  Therefore,

   putting an attribute which can not be de= composed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

 

1)   = ;   As a minor comment, the error is not limited to an (o= ne single) attribute (type) which size is bigger than 4096 octets. The error happens when the Total Path Attribute Length (for all at= tributes) is bigger than 4096 octets.

 

[Sue]: My understanding of the E= xtended message draft is that it is not dealing with section 6.3 of RFC4271.

[Bruno= 3] I agree. Section 6.3 of RFC4271 handles error when receiving a BGP update = message. While BGP Extended Message create error when sending a BGP update = message.

My comment was not related to section 6.3 or RFC 4271, but to the text of dra= ft-ietf-idr-bgp-extended-messages which I have cited above. = I don’t see what could be unclear in my comment.

&= nbsp;

 Here’s my understand= ing of the

 

RFC4271 states:

 

“All Errors detected while= processing the Message header must be indicated by sending a NOTIFICATION message with the Message Header error.  The Error subcode elaborates = on the specific nature of the error. “

 

One of the errors is a message h= eader length:  “If the length field of the message header is less than 19 or greater than 4096.”  If any of these super larg= e attributes causes the message length to be greater than 4096, then with R= FC4271, the error code sent would be “Bad Message length.”=

 

If the message length is switch = from 4096 to 65535 octets, the RFC4271 error handling would allow the message length to be 65,535.

 

 

After the section 6.1 text RF= C4271 is changed to the following:

[Bruno3] Idem, section 6.1 of RFC4271 handles error when _receiving_ a BGP update message. While draft-ietf-idr-bg= p-extended-messages generate an error condition when sending a BGP update.

 <= /p>

    If at least o= ne of the following is true:

-   =        If the Length field of the message header is less tha= n 19 or greater than 4096

for OPEN message,

 

-   =        If BGP Extended Messages capability is not set, the l= ength field of any other BGP message other than an OPEN message is less than 19 or greater than 4095,

 

-   =        If the BGP Extended Message capability is set for a B= GP peer, if the length field is less than 19 or greater than 65,535.  (See the error handling below for the setting of this f= unction.)

 <= /p>

-   =        If the length field of an UPDATE message is less than= the minimum field of the UPDATE message, or

 <= /p>

-   =        If the length field of a KEEPALIVE message is not equ= al to 19, or

 <= /p>

-   =        If the length field of a NOTIFICATION message is less= than the minimum length of the NOTIFICATION message.

 <= /p>

Then the Error Subcode M= UST Be set to Bad Message Length.  The Data field MUST contain the erroneous length field.

[

     6.9) Ex= tended Message Capability

 

   To advertise the BGP Extended Message Ca= pability to a peer, a BGP

   speaker uses BGP Capabilities Advertisem= ent [RFC5492].  By

   advertising the BGP Extended Message Cap= ability to a peer, a BGP

   speaker conveys that it is able to send,= receive, and properly handle

   BGP Extended Messages.=

 

   A peer which does not advertise this cap= ability MUST NOT send BGP

   Extended Messages, and BGP Extended Mess= ages MUST NOT be sent to it.

 

   The BGP Extended Message Capability is a= new BGP Capability [RFC5492]

   defined with Capability code 6 and Capab= ility length 0.

  

    6.9.1) O= peration:

 

      A BGP speaker that is capable of sending and receiving B=
GP Extended

   Messages SHOULD advertise the BGP Extend= ed Message Capability to the

   peer using BGP Capabilities Advertisemen= t [RFC5492].  A BGP speaker

   MAY send Extended Messages to its peer o= nly if it has sent and

   received the Extended Message Capability= from that peer.

 

   The Extended Message Capability applies = to all messages except for

   the OPEN message.  This exception i= s made to reduce complexity of

   providing backward compatibility

 

     An implementation that advertises support for BGP Extended Mes=
sages

   MUST be capable of receiving a message w= ith a length up to and

   including 65535 octets.

 

   Applications generating information whic= h might be encapsulated

   within BGP messages MUST limit the size = of their payload to take the

   maximum message size into account.<= /o:p>

 

   If a BGP update with a p= ayload longer than 4096 octets is received by

   a BGP= listener who has neither advertised nor agreed to accept BGP

   Exten= ded Messages, the listener MUST treat this as a malformed update=

   messa= ge, and MUST raise an UPDATE Message Error (see section 6.3).

 

 

   A BGP announcement will, in the normal c= ase, propagate throughout the

   BGP speaking Internet; and there will un= doubtedly be BGP speakers

   which do not have the Extended Message c= apability.  Therefore,

   putting an attribute which c= annot be decomposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

 

[Bruno= 3] the error is not limited to an (one single) attribute (type) which si= ze is bigger than 4096 octets. The error happens when the Total Path Attribute Length (for all attributes) is bigger than 4096 octet= s

 <= /o:p>

   It is RECOMMENDED that BGP protocol deve= lopers and implementers are

   conservative in their application and us= e of Extended Messages.

 

   6.9.2 Error Handlin= g for the Extended messages

 

     A BGP speaker that has the ability to use Extended Messages bu=
t has

   not advertised the BGP Extended Messages= capability, presumably due

   to configuration, SHOULD NOT accept an Extended Message.  A speaker

   MAY i= mplement a more liberal policy and accept Extended Messages,

   even from a peer to which it has not adv= ertised the capability, in

   the interest of preserving the BGP sessi= on if at all possible.

[Bruno= 3] The texts highlighted in blue are contradicting. I would suggest removing = the blue text from =A74 which the behavior is related to error handling con= ditions described in section 5. (note that your coded text have changed the= section numbers. I’m referring to the section numbers in the draft)

 

   A BGP speaker that does not advertise th= e BGP Extended Messages

   capability might also genuinely not supp= ort Extended Messages.  Such

   a speaker MUST follow the error handling= procedures of section 6.1

   regarding message length.

[Bruno= 3] Agreed, but that text is not very logical: you can’t define a new be= havior for an old speaker. At minimum, I would propose the following change= :

OLD: Such=

   a speaker MUST follow the error handling= procedures of section 6.1

   regarding message length.

&= nbsp;

NEW: Such

   a speaker will follow the error handling= procedures of [RFC4271] section 6.1

   regarding message length.

&= nbsp;

 

 

   The inconsistency between the local and = remote BGP speakers MUST be

   flagged to the network operator through = standard operational

   interfaces.  The information should= include the NLRI and as much

   relevant information as reasonably possi= ble.

 

[End of text change from draft ]=

 

 

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

 

2)   = ;   As a major comment, I am asking for the specification= to specify how it handles that failure, which is not the result of a possible bug, but created by design by the solution. It will h= appen.

 

Your proposition to ̶= 0;raise an alarm” is required but not sufficient as we still need to specify what we do with this “big” route. One option could = be “treat as withdraw”, another option suggested by Robert is t= o propagate the NLRI with subset of attributes plus an indication of the fa= ilure (“a short attribute BGP_PIPE_TOO_THIN”). There may be others options.=

 <= /p>

[Sue]: Robert’s opt= ion is a fine idea, but the WG did not accept this option in the past so I cannot force this option into the specification.  I hope that Ro= bert will propose this option again. 

[Bruno3] Agreed. I’m perfectly with “treat-as-withdraw”

 <= /p>

To trigger the discussion= on the resolution, I would propose the following text “One BGP Route too large to be propagated to a BGP receiver not supporting BGP = Extended Message MUST be handled, over this BGP session, using the Treat-as= -withdraw approach as defined in [RFC7606]. The BGP speaker MAY, beforehand= , remove some BGP attributes which are eligible to the Attribute discard approach [RFC7606].”

 <= /p>

[Sue]:  This text de= als with section 6.3 in RFC4271, and to my understanding draft-ietf-idr-bgp= -extended-messges-28.txt only deals with section 6.1 of RFC4271.

[Bruno3] I disagree that the text deals with sections 6.3 or 6.1 of RFC 4271. Those= sections refers to error handling or _received_ BGP update, while draft-ietf= -idr-bgp= -extended-messages create error when _sending_ a BGP update.

    In add= ition, there is no concept of propagation RFC7606 or RFC4271.  Each BG= P peer receives BGP messages and updates, it then propagates or sends routes and = attributes to its peers.    Could I restate your suggestion = as:

 <= /p>

6.9.2 Error handling

(added at the end of the = current text  

 <= /p>

A BGP speaker which peers= with some peers with extended message capability and other peers without extended message capability, MUST handle a BGP Route (attrib= ute, NLRI pair) that is too large to be sent to a BGP peer without the exte= nded message capability using the “treat-as-withdraw” approach = defined in [RFC7606].  The BGP speaker, MAY remove some BGP attributes which are eligible to use the Attribute discard= approach [RFC7606]. 

[Bruno3] point discussed at the top of you email.

 <= /p>

 <= /p>

3)   = ;   Once error handling is specified, the draft will be a= ble to discuss

a.   = ;    the operational considerations for this issue (e.g. T= he one from RFC7606 could be referenced as-is, or used as inspiration)

b.   = ;   the security considerations (as a remote attacker wou= ld be able to craft a large BGP route that will be withdrawn (assuming “treat-as-withdraw”) somewhere in some AS, possibly = creating routing inconsistencies within the AS)

c.   = ;    the proposed mitigations (e.g., an operator should en= able support for Extended messages on all IBGP sessions first, before enabling it on an EBGP session; If not possible, an operator= could define a policy to filter BGP attributes from EBGP sessions, typical= ly based on their type and size;….)

 

more inline [Bruno2]<= /span>

 

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Thursday, February 14, 2019 6:20 PM
To: DECRAENE Bruno TGI/OLN
Cc: idr@ietf.org; 'Jakob Heitz (jheitz)'; 'John Scudder'; 'Alvaro Re= tana'
Subject: RE: [Idr] WG Last Call on Extened Message Support

 

Bruno:

 

Thank you for careful considerat= ions on the use case.   I think we have translation issues between our “English” language again so I have tried to be precise in = the detailed comments.  I’ve summarized my comments as well to h= elp us take the next step.

 

Sue

 

Summary

----

Good catch on the 1000 large BGP= communities blowing up the message size!  This is a case where a code path could get caught with program error.  The error handling = (section 6.1 in RFC4271 per section 5 in the extended specification) IMHO h= andles the case where the attribute is longer than the message.   = ;Please let me know if I’ve missed something.   =

 

[Bruno2] I don’t think tha= t section 6.1 of RFC4271 covers this. The problem is not a Message Header error handling as a proper BGP implementation would not sent the me= ssage. (not to mention with inconsistent size).

[Sue2]: OK, but section 6.1 is t= he only places that this draft changes.

[Bruno= 3] points discussed above

 

As I understand it,  you ar= e asking this specification to be expanded to add notes on policies on what implementation should do to correctly combine RFC4271 length sizes= with extended length sizes.   The implementers and operations pe= ople commented earlier that this should not be in the protocol specificatio= n other than as a brief footnote. 

 

[Bruno2]An error handling must e= xist even in the absence of SP policies. The argument related to previous discussions does not hold IMHO as I’ve raised a new poin= t (this happens with existing BGP attributes, not in a hypothetical new att= ribute)

[Sue2]:  Thank you for send= ing your text.  I can your comments are on the UPDATE handling process= es based on RFC7606.  We were discussing 2 different places in RFC4271. =

 

I agree there is a need for such= standardization as BCPs for particular use cases (large communities, BESS (EVPN or centralized controller), SPRING, BGP-LS information (see Day= light comments yesterday), SD-WANs (rtgwg), and SPRING.   I think= the chairs of the WGs utilizing should consider if there is need for stand= ardization for a minimal set of policy for message sizes for specific use cases.   I will be glad to send r= equest to these WG or to host something in IDR if there is policy that can = be used across all use cases.

 

[Bruno2] I don’t think tha= t Error handling is to be considered as optional or for future consideratio= n.

[Sue2]:  Based on your prop= osed text, I can see the value of considering this text at this time.  

[Bruno= 3] Thanks for considering the error handling for new error conditions introdu= ced by draft-ietf-idr<= /span>-bgp-extended-messages-<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif";mso-bidi-font-family:"Times New Roman";= color:#1F497D;mso-ansi-language:EN-US">

--Bruno=

 

To provide a slight expansion to= point people in this direction, how about this change to paragraph in section 4:

 

Old/

   A BGP announcement will, in the normal c= ase, propagate throughout the

   BGP speaking Internet; and there will un= doubtedly be BGP speakers

   which do not have the Extended Message c= apability.  Therefore,

   putting an attribute which can not be de= composed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

/

New/

   A BGP announcement will, in the normal c= ase, propagate throughout the

   BGP speaking Internet; and there will un= doubtedly be BGP speakers

   which do not have the Extended Message c= apability.  Therefore,

   putting an attribute which cannot be dec= omposed to 4096 octets or

   less in an Extended Message is a likely = path to routing failure.

   One example of a valid attribute which c= annot be precisely decomposed if it

   sent in Extended message is a large= community attribute with 1000 communities.

   (12,000 bytes). 

/

[PS – in American English “Can not”= is normally concatenated “cannot”.]

   

[Bruno2] Thanks for the proposit= ion, but this does not address my concern.

[Sue]: Thank you for your text &= #8211; I understand why now.

 

From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Thursday, February 14, 2019 3:29 AM
To: Susan Hares
Cc: idr@ietf.org; 'Jakob Heitz (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message Support

 

Sue,

 

Thanks for the reply. Please see= inline [Bruno]

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, February 13, 2019 8:03 PM
To: DECRAENE Bruno TGI/OLN
Cc: idr@ietf.org; 'Jakob Heitz (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message Support

 

Bruno:

 

I’d like to answer some o= f the questions you sent Randy based on comments (public and private) the chairs and I as the shepherd received on this draft in our last WG LCs= ..   

 

Several of the comments you que= stioned were put in to answer other questions.   This gets into a catch-22… problem – where you put changes in for one person/= take out the changes out for another.  In academic circles this is cal= led the reviewer #2 problem (reviewer 1 insists changes go in, reviewer 2 i= nsists changes go out) during publication.  Therefore, I’m I am going to answer most of your questions where this is the ca= se. 

 

I believe that Randy has new ve= rsion with the changes I’ve indicated.  I’m hoping he̵= 7;ll just post that version.  AFAILK, we do have 2 compliant implementations. <= o:p>

 

Sue

 

 

 

<shepherd hat on>

This draft’s technology p= rovides efficient processing for some application by allow a huge BGP message size.  Whether “chunking” BGP to 4096 byte me= ssages or packing large amounts of data into 65,000 byte message is more ef= fective for a particular application is something only an implementer of a = particular BGP implementation  can decide.   This draft simply gives freedom for applications to not be restrict to an artif= icially small message size.  The market place will choose whether this= technology is used or not. 

 

As Jakob pointed out, changing = a highly tuned BGP implementation which “chunks” BGP data into 4096 byte messages may involve substantial rework of the implementation.&n= bsp;

 

 <= /p>

(snip)

From: Idr <idr-bounces@ietf.org> On Behalf Of bruno.decraene@orange= ..com
Sent: 29 January 2019 13:33
To: Susan Hares <shares@ndzh.com>
Cc: idr@ietf.org
Subject: Re: [Idr] WG Last Call on Extened Message Support

 

Hi WG,

 

>Please find below some comments.

>As of today, I don’t believe this specification is ready to be progress= ed to IESG/RFC, especially for a document >updating RFC 4271 (core BGP spec).=

 

> The WG chairs intend to forwar= d this draft to the IESG with the current level of implementation. 

 

>https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-exten= ded->implementations says : 5a

Does not send Extended Message capability

Yes

Yes

Yes

 

>I may be misunderstanding the implementation report, but my reading of the a= bove is that none of the reported >implementations sends the capabili= ty hence no implementation supports draft-ietf-idr-bgp-extended-messages..

>Here this document is updating RFC 4271, so it is not a minor extension for a n= iche use case. So I don’t see the >arguments for not requiring the ID= R’s usual two interoperable implementations.

 

>In our mail thread, we disc= overed that the implementation report should have indicate

>full support.   I= ’m waiting for Olivier to update based on the last point, but my unde= rstanding is that

All implementations have full s= upport.  

 

[Bruno] ok, solved<= /i>

>----

>=A7 1

>“ As BGP is extended to support newer AFI/SAFIs and

> =   newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there is

> =   a need to extend the maximum message size beyond 4096 octets.  “= ;

>&= nbsp;

> https://tools.ietf.o= rg/html/draft-ietf-idr-bgp-extended-messages-27#section-1

 

 

>[I-D.ietf-sidr-bgpsec-protocol<= /span> is now RFC 8205 (t= hanks for updating the reference). It has removed the normative/any >reference to draft-ietf-idr-bgp-ex= tended-messages. So presumably BGP Sec does not need draft-ietf-idr-bgp->extended-messages. Can we have an update on this?  <= /span>Can the introduction of draft-ietf-idr-bgp-extended-messages >be update= d to introduce on the real reasons/needs?

 

SIDR gave up waiting on IDRR= 17;s work and took a reduced size of encryption.   The security p= eople were very sad about the reduction.  How is this working in practice? = WG sidrops can answer this question. 

 

The real problem is there is fi= nite message space. 

[Bruno] So too bad the dra= ft does not solve the real problem ;-) (as message space is still limited)

 

[Sue]: The message is still fini= te (smile),  but I hope 65,635 (smile) is probably enough for 10 years.   

 

There are two ways to send lots= of BGP routes and/or attributes – to “chunk” these into = small message sizes or place these into a large message.    Some = applications may always want to “chunk” into message sizes smal= ler than 4096.   Some application make work more efficiently util= izing large message size.  As the potential number of NLRI and BGP att= ributes grows, new applications may consider large message sizes to a more reasona= ble way to exchange amounts of BGP data.    

 

The decision on how to send BGP= messages over the wire is a peer-by-peer decision in a network.   Each BGP peer is in charge of reformatting the BGP message it sends = to the remote BGP peer.   The BGP capabilities in this draft repr= esent an agreement between two BGP peers.  These are facts of basic BG= P implementations

[Bruno] Let’s take t= he example of a BGP Route Reflector having a mixed of clients, some supporting Extend Message (EM) and some not.

From an EM client, it rece= ives a BGP update containing one (single) NLRI with an Total Path Attribute Length bigger than  4090 byte (e.g. having 1000 large = communitiess)

Can you explain me how it = behaves to send this NLRI to an IBGP peer not supporting EM?

[Sue]:  Gladly…

A BGP route reflector (RR-= A) is peering with each of its BGP clients.   It agrees with each of its clients (BGP-C1, BGPC2, BGPC3) whether the BGP Extended messag= es is accepted or not (based on capability announcement).

Let us assume that BGP-C1 = does not support extended messages, and  BGP-C2 and BGP-C3 do support extended messages.

 

If the policy in RR accept= s a total path length of 1000 large communities with  a single NLRI, it may send the BGP attribute via extended communities to BGP-C2 and= BGP-C2.

The policy in the RR must = specify whether:

a)  = ;    the “too long” attribute pa= th length must be dropped, or

b)  = ;    the BGP attribute path can be truncated.

 

This is a policy issue wit= hin the BGP peer and the network operation staff.  Each operator may choose to write this policy differently.

[Bruno2] So we agree that = a new behavior is REQUIRED. The draft does not mention this. The ability to change the behavior by policy does not remove the need for = specifying the error handling.

 

Rather than specify the nu= merous cases in the protocol specification,  the previous discussions (private and public) asked us to trim this information out of the protocol= specification.

[Bruno2] Can’t be ha= ve a general rule which is good enough to handle the issue? Previous discussions seemed based on the fact the error condition would happen for = future attribute. This is not the case.

 

If you believe this is wor= thy of a use case draft for the sake of BESS, LSVR, SPRING, Grow and others, I will happily WG chair sponsor a draft that can be revie= wed by all these WGs.

[Bruno2] I believe that th= is is worthy in this specification.

 

 

– so I do not believe addi= ng these facts to Randy’s draft is useful.  In fact, in the prev= ious rounds of review this point was made.

 

Your question (and perhaps Jakob= ’s) is whether we have reached a time/place where the “chunking= ” approach will fail on a peer-by-peer basis?   This draft does no= t make this statement. 

 

The point of this draft is to en= able more efficient processing by increasing the message size for BGP peers that send a lot of data (e.g. BGP-LS) .   The choi= ce to “chunk” or stream in large BGP message is an implementati= on choice for a particular BGP application. 

 

----

=A74

=A73 =
says “A peer which does not a=
dvertise this capability MUST NOT send BGP

   Extended Messages, and BGP Extended Messages MUST N= OT be sent to it.&= #8221;

[I believe randy accepted this c= hange with the following text in version 4 [upcoming below]]/.

 

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

 

Fine. Text in =A74 should probably b= e aligned with the above .e.g.

OLD: A BGP speaker

   MAY send Extended Messages to its peer only if it ha= s received the

   Extended Message Capability from that peer.

 

NEW:

A BGP speaker

   MAY send Extended Messages to its peer only if it ha= s sent and received the

   Extended Message Capability to and from that peer.

 

 

----

>“   Applicat=
ions generating information which might be encapsulated

> &=
nbsp;
 within BGP messages MUST limit the size of their payload to take the<=
/o:p>


> &=
nbsp;
 maximum message size into account.”


> 


>I
 don’t see what new behavior is been defined here. If there is none, =
I would suggest to remove this sentence


 


Bruno – people asked to pu=
t this text in as an operational warning.  At this point, I’m go=
ing
 to say unless there is harm it should remain.  


[Bruno] OK.=



 


----


> &=
nbsp;
 A BGP announcement will, in the normal case, propagate throughout the=



> &=
nbsp;
 BGP speaking Internet; and there will undoubtedly be BGP speakers


> &=
nbsp;
 which do not have the Extended Message capability.  Therefore,


> &=
nbsp;
 putting an attribute which can not be decomposed to 4096 octets or


> &=
nbsp;
 less in an Extended Message is a likely path to routing failure.


> 


>The
 issue is not specific to attributes bigger than 4096 octets, but to BGP me=
ssage whose length is bigger than
>=
4096, =
irrespective
 of the size of each attribute.


>Please
 elaborate on what you mean by 


> 


>“an
 attribute which cannot be decomposed to 4096 octets”


 


An attribute which cannot be dec=
omposed to 4096 is an attribute with length 6000 inside of a
 BGP message which requires the entire attribute to be included.  &nbs=
p;No such attribute exists today.   If a small BGP peers create a=
 “killer application” that uses a 6000 byte attribute, the rest=
 of the Internet does not have to use it.   However, the person
 defining that attribute must carefully specify it must go with Extended BG=
P messages.



 


 


[Bruno] I don’t thin=
k that I agree with this. E.g. I don’t see where RFCs 1997 or 8092
 [(large)community] limits the size of their attribute. Hence I don’t=
 see why you could not have, today (with Extended Message support) , attrib=
utes larger than 4096 octets. Most probably same status for the BGPSec attr=
ibute since they wanted for more space.


[Sue]: You make a good poi=
nt about the possibility of large communities not limiting the
 size.  It is worthy of a change to both the large communities and a f=
ootnote in Randy’s specification.  How about the addition of a s=
ingle sentence to point people in the right direction.



 


Old/


   A BGP announcement will, in the normal c=
ase, propagate throughout the


   BGP speaking Internet; and there will un=
doubtedly be BGP speakers


   which do not have the Extended Message c=
apability.  Therefore,


   putting an attribute which can not be de=
composed to 4096 octets or


   less in an Extended Message is a likely =
path to routing failure.


/


New/


   A BGP announcement will, in the normal c=
ase, propagate throughout the


   BGP speaking Internet; and there will un=
doubtedly be BGP speakers


   which do not have the Extended Message c=
apability.  Therefore,


   putting an attribute which cannot be dec=
omposed to 4096 octets or


   less in an Extended Message is a likely =
path to routing failure.


   One example of a valid attribute which c=
annot be precisely decomposed if it



   sent in Extended message is a large=
 community attribute with 1000 communities.



   (12,000 bytes). 



/


 



 


 


This text was added during an e=
arlier discussion where the error cases of a large BGP attribute
 was given.  The originator of the common could not provide the exact =
description, but we agreed to put this  “warning label” in=
to the draft.   This is one of the cases where adding/removing te=
xt gets to be problematic.



 


>---


>“=
;  
 It is RECOMMENDED that BGP protocol developers and implementers are


> =
 
 conservative in their application and use of Extended Messages.”


>&=
nbsp;


>What
 does this mean exactly? That they don’t use this extension? 



>That
 they don’t use this extension unless XX_TO BE SPECIFIED_XX?


 


This warning was text that othe=
r participants asked to be added.



 


It is a common sense warning.&n=
bsp; Extended messages are enabled on a peer by peer basis as all
 BGP capabilities are.  If you run into a Peer that does not support t=
he larger sizes, the BGP messages will need to be reformatted to the smalle=
r size.   Running immediately to the Extended messages as the def=
ault could cause problems.



 


[Bruno] I think that the s=
entence could be elaborated. Indicating the problem, how the
 specification partially address it, and how the specification does not add=
ress it.


In “Running immediat=
ely to Extended Message” I don’t think they that the issue is w=
ith
 “immediately”. Whenever you start the transition, your likely =
to run into problems.


 


 


[Sue]: IMHO specification =
specifies how to encode the bytes on the wire and the appropriate
 error handling of the messages.   If I have missed something in =
this case, please let me know.



[Bruno2] IMHO specificatio=
ns need to handle error conditions that they create by design.


 


The specification does not=
 specify the necessary policies implementation should have in
 order to decide what to do in the case of mixed network.   The c=
lear indication was this type was not appropriate for the protocol specific=
ation.  


 


Earlier discussion indicat=
ed that these is policy and mechanism specific.  It is worthy
 of “use case or application notes” written for specific applic=
ations (BESS, SPRING, GROW), but not in the specification.  Again, if =
it is significant enough concern for operators and implementers – it =
would be worthy to have combined use case document besides
 this point.    I’m happy to sponsor cross-area work o=
n this use case. 


 


---


  Future protocol specifications will need to describe how =
to handle


   peers which can only accommodate 4096 octet message=
s..


 


>Why
 is this limited to future specifications? A priori, using existing BGP mec=
hanism (AFI/SAFI, attributes, *
>communities) one could exceed the =
size of 4096 octets. How does the BGP speaker supposed to behave in this
?>case? This should be described in=
 this specification. Note that this is not a case of error handling, as eve=
ry BGP



>
speaker is behavin=
g as specified.


 


I fail to see your logic. =
 At this point, all BGP data (AFI/SAFI and attributes) must fit within
 a 4096 message.   Therefore, a BGP peer A which connects on link=
 1 to BGP peer B with 4096 message and on link to a BGP peer C with extende=
d messages only has to worry about reformatting the data. 



 


In the future, the first group =
that defines attribute or an NLRI that does not fit within a
 4096 BGP message and cannot be split, will need to define how that works i=
n the specification.  There is no need to refine the current set of sp=
ecifications.  



[Bruno]<=
/i>


1) cf above, I believe tha=
t there are existing BGP Attributes which may not fit into a
 bytes 4096 BGP message


2)Even in the absence of s=
uch attribute, you have the issue of 2 smaller attributes whose
 cumulative size does not fit into a 4096 bytes message.<=
/i>


 


The problem is introduced =
by this specification, hence I believe this specification needs
 to specify how to handle this case.


 


[Sue]:  IHMO the message tr=
ansmission and reception error handling issues are complete in the
 combination of RFC4271 and the extended message section 5. 


 


What is not in this specificatio=
n is the policy issues about what happens if you combine 2 smaller
 attributes.  For example, if you have a large community attribute of =
400 communities (4800 bytes), you will likely run into problems when combin=
ing with some longer AS path lengths.  [4800=E0
 5096 bytes is a short jump]. People on the list and in-person argued this =
was policy and implementation specific details.


[Bruno2] It’s not im=
plementation specific. This is an issue created by the specification.
 Let’s discuss it in public. 



 


I agree with you that it is extr=
emely useful to the operator community to have this type of
 policy details discussed to see if there is some desire to have common pol=
icies and error communities.   It is the type of thing that GROW =
and IDR should be deeply involved for large communities.   BESS, =
LSVR, SPRING and others should consider what policy
 should be adapted for their applications. 


 


>----


>Depending
 on the above specification, a section describing the operational consequen=
ces in a network (such as the
>=
Intern=
et, BGP
 Enabled ServiceS/VPN networks) is probably needed. Possible consequences c=
ould be BGP NLRI
>=
being =
removed
 in the middle of such network, or (extended) community (such as Route Targ=
ets) been removed.
>=
Both h=
aving significant
 consequences on the availability provided by the network.


 


At this point, there are no att=
ributes or NLRI groupings that do not fit within 4096.   If
 you define one (as SIDR did), then you will need to have it reviewed by ID=
R, BESS, SPRING, and operational groups (GROW, etc). 


[Bruno] no, cf above.=



[Sue]:  Thank you for=
 reminding me of the potential of large communities to blow up BGP.
  I have a new worry to add to my BGP concerns list! 


[Bruno2] IMHO, the problem=
 is more with Extended Message than with large community. And
 we can work to consider and address this problem.


--Bruno<=
/i>


 


Thanks,<=
/i>


--Bruno<=
/i>


 


 


---


>=A74


>OLD:
 The Extended Message Capability only applies to all messages except for th=
e 
>OPEN message. 


>Probab=
ly


>NEW:
 The Extended Message Capability applies to all message types except for th=
e 
>OPEN message (type 1). 


>----


>=A78


>“This extension to BGP does not =
change BGP's underlying security issues =BB


>Before evaluating this, I think this d=
ocument should first specified how a BGP 


>messages bigger than 4096 octets is ha=
ndled when it needs to be sent to a 


>received not suppor=
ting this extension.


 


Nits:


>OLD&nb=
sp;:
 to reduce compexity


>NEW&nb=
sp;:
 to reduce complexity


 


Thanks,


--Bruno


 








From: Idr [mailto:i=
dr-bounces@ietf.org]
On Behalf Of Susan Hares

Sent: Tuesday, January 29, 2019 12:33 PM

To: idr@ietf.org

Subject: [Idr] WG Last Call on Extened Message Support






 


 


This begins a 2 week WG LC on Exten=
ded Message Support for BGP (draft-ietf-idr-bgp-extended-messages-27). 
 You can access the draft at: 


 


https://datatracker.iet=
f..org/doc/draft-ietf-idr-bgp-extended-messages/


 


The authors should indicate whether=
 they know of any IPR.   Implementers are encouraged to update
 the  implementation data at: 


 


https://trac.i=
etf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations=



 


The draft provides a means for expa=
nding the BGP message to 65535 octets for all messages except
 OPEN messages.  BGP message space is running short for all of the pot=
ential attributes or additions proposed by BGP-LS features. 



 


The WG chairs intend to forward thi=
s draft to the IESG with the current level of implementation. 



 


As you comment on the draft, please=
 consider if: a) the technology is mature, b) the additional
 space in a BGP message would be helpful for those deploying BGP-LS or SR, =
and c) if the specification is ready for publication. 



 


Sue Hares (WG Chair, Shepherd)



 


 




=
___________________________________________________________________________=
______________________________________________


=
 


=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc


=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler


=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,


=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.


=
 


=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;


=
they should not be distributed, used or copied without authorisation.<=
/o:p>


=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.


=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.


=
Thank you.


______________________________________________________=
___________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent donc<=
/pre>

pas etre diffuses, exploites ou copies sans autorisati=
on. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces joi=
ntes. Les messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a et=
e altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confident=
ial or privileged information that may be protected by law;


they should not be distributed, used or copied without=
 authorisation.


If you have received this email in error, please notif=
y the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for mes=
sages that have been modified, changed or falsified.


Thank you.


_______________________________________________________=
__________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des i=
nformations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisatio=
n. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les pieces join=
tes. Les messages electroniques etant susceptibles d'alteration,=



Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confidenti=
al or privileged information that may be protected by law;


they should not be distributed, used or copied without =
authorisation.


If you have received this email in error, please notify=
 the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for mess=
ages that have been modified, changed or falsified.


Thank you.


_______________________________________________________=
__________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des i=
nformations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisatio=
n. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les pieces join=
tes. Les messages electroniques etant susceptibles d'alteration,=



Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confidenti=
al or privileged information that may be protected by law;


they should not be distributed, used or copied without =
authorisation.


If you have received this email in error, please notify=
 the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for mess=
ages that have been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A489E3592OPEXCAUBM43corp_-- From nobody Fri Feb 22 09:24:18 2019 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9245130F27; Fri, 22 Feb 2019 09:24:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <155085625070.5514.9739048217238977048@ietfa.amsl.com> Date: Fri, 22 Feb 2019 09:24:10 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 17:24:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : The BGP Tunnel Encapsulation Attribute Authors : Eric C. Rosen Keyur Patel Gunter Van de Velde Filename : draft-ietf-idr-tunnel-encaps-11.txt Pages : 41 Date : 2019-02-22 Abstract: RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used in production), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. This document obsoletes RFC 5512. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-11 https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-tunnel-encaps-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 26 10:16:36 2019 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7F5124408; Tue, 26 Feb 2019 10:16:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <155120498877.852.8582818799698080818@ietfa.amsl.com> Date: Tue, 26 Feb 2019 10:16:28 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 18:16:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : BGP YANG Model for Service Provider Networks Authors : Keyur Patel Mahesh Jethanandani Susan Hares Filename : draft-ietf-idr-bgp-model-04.txt Pages : 138 Date : 2019-02-26 Abstract: This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects based on data center, carrier and content provider operational requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-model-04 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-model-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 26 10:20:03 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E17129524 for ; Tue, 26 Feb 2019 10:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRU7Jl5LEP4h for ; Tue, 26 Feb 2019 10:19:59 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64BE1288BD for ; Tue, 26 Feb 2019 10:19:59 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id e17so4547118pgd.2 for ; Tue, 26 Feb 2019 10:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=LlHYoX33kDUCm6WkOy8GPWMZHrLfAXgpoOxyeZr8LEc=; b=bhX0mAzt2rmV7Uis9LBZ+DBy8vb20LzKtdiBEI8JqaDSux/Qo3WT98lF8KD6AJIFId 4RfgLhIiMG6X1bXLGj5lFKYRYHGNbQdcMoFiislva/hjlK1gK+HiSwpPsxlr61qpzhN+ q8T/g2c0af/Iwn4Vj8TSgiiNi45hmSXRF/vzCvQFsLexA8B0mGwtd/HhmdfCZ2pS3xoR Cx0kUqufCRqn3smGDag07X0ftV9A/MLCraFxP6Ou3+d62cFBGO8Zq5cRo0LTLkpig60Q Gxyyj0iCGAK/k1WAfwr4B0mXOSZYZAROlw0SPJE/hDVfQvK9YU8JOkcZkz1XYnjjcMt1 wSgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=LlHYoX33kDUCm6WkOy8GPWMZHrLfAXgpoOxyeZr8LEc=; b=rvZWIKwWm9go3KdSH10Z3+7uUBPFYiZwNcq9BboHD2TGqxB1ec6JtzQVkY+I8Qtr4S 9VV2VM0qjTCGCKnBzIzKRKqv2QdeGlAAf9NYmtIgIaQQiNHgf2zz6bMBC1r8CXmY3ymu 27Y+8Aw/eAlTgCHpsRBXJrYAB1Eo7airQVFPDX12EP0Gb/s0m0ULSBZmYphmrmkAqC+x lYLI6vz2Vt8MmuUXutQUHp9E8oMWu0zCpGPRlDOcUOPrpD4hDKy4VfaS2A9PqzXFRZbX 3GxNp39kRNUYqCaJv5cLROzZ+F41RWymOBo99H3/uAzZVv55BNt8qTCEu5CZcQ7IGXDA +OjA== X-Gm-Message-State: AHQUAuZrHc8Ho59JtFnd8hSSE05vHXdG5CyTy2LObGgm4VGALagihJM3 PQjjThrSbgrXSn5nmOkgrxLxFWE5 X-Google-Smtp-Source: AHgI3IY+hcQaGPW/zYmPu4Dy20y+hP77EG6cmnzBxwTHZgfEThdz0t9Pbrt5lYVt+vh6W1tW88+5Uw== X-Received: by 2002:a63:d904:: with SMTP id r4mr25725344pgg.207.1551205198717; Tue, 26 Feb 2019 10:19:58 -0800 (PST) Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id g6sm18864332pgc.22.2019.02.26.10.19.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 10:19:57 -0800 (PST) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 26 Feb 2019 10:19:58 -0800 References: <155120498877.852.8582818799698080818@ietfa.amsl.com> To: idr@ietf.org In-Reply-To: <155120498877.852.8582818799698080818@ietfa.amsl.com> Message-Id: <68805692-5B0B-4406-92DD-50529E4F8F8D@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 18:20:01 -0000 This update of the draft adds support for: - augmentation of the Routing Management Model. - augmentation of the routing policy model - support for RIB Comments welcome. > On Feb 26, 2019, at 10:16 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Inter-Domain Routing WG of the IETF. >=20 > Title : BGP YANG Model for Service Provider Networks > Authors : Keyur Patel > Mahesh Jethanandani > Susan Hares > Filename : draft-ietf-idr-bgp-model-04.txt > Pages : 138 > Date : 2019-02-26 >=20 > Abstract: > This document defines a YANG data model for configuring and managing > BGP, including protocol, policy, and operational aspects based on > data center, carrier and content provider operational requirements. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-bgp-model-04 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-model-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Feb 26 19:19:53 2019 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE2B130DC8; Tue, 26 Feb 2019 19:19:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <155123759129.806.12400506697168591152@ietfa.amsl.com> Date: Tue, 26 Feb 2019 19:19:51 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 03:19:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Distribution of Traffic Engineering (TE) Policies and State using BGP-LS Authors : Stefano Previdi Ketan Talaulikar Jie Dong Mach(Guoyi) Chen Hannes Gredler Jeff Tantsura Filename : draft-ietf-idr-te-lsp-distribution-10.txt Pages : 48 Date : 2019-02-26 Abstract: This document describes a mechanism to collect the Traffic Engineering and Policy information that is locally available in a node and advertise it into BGP Link State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distribution/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-10 https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-lsp-distribution-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 27 00:07:36 2019 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 640CF130E7C; Wed, 27 Feb 2019 00:07:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <155125484838.14091.17463422086871275164@ietfa.amsl.com> Date: Wed, 27 Feb 2019 00:07:28 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 08:07:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Dissemination of Flow Specification Rules Authors : Susan Hares Christoph Loibl Robert Raszuk Danny McPherson Martin Bacher Filename : draft-ietf-idr-rfc5575bis-12.txt Pages : 34 Date : 2019-02-27 Abstract: This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It specifies IPv4 traffic Flow Specifications via a BGP NLRI which carries traffic Flow Specification filter, and an Extended community value which encodes actions a routing system can take if the packet matches the traffic flow filters. The flow filters and the actions are processed in a fixed order. Other drafts specify IPv6, MPLS addresses, L2VPN addresses, and NV03 encapsulation of IP addresses. This document obsoletes RFC5575 and RFC7674 to correct unclear specifications in the flow filters. Applications which use the bgp Flow Specification are: 1) application which automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of- service attacks; 2) applications which control traffic filtering in the context of a BGP/MPLS VPN service, and 3) applications with centralized control of traffic in a SDN or NFV context. Some deployments of these three applications can be handled by the strict ordering of the BGP NLRI traffic flow filters, and the strict actions encoded in the extended community Flow Specification actions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-12 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc5575bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 27 04:26:11 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5628C130EC3 for ; Wed, 27 Feb 2019 04:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9sjdzloL3fD for ; Wed, 27 Feb 2019 04:26:07 -0800 (PST) Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B87130EB4 for ; Wed, 27 Feb 2019 04:26:07 -0800 (PST) Received: from gaestewlan.nextlayer.at ([92.60.6.196] helo=[192.168.68.103]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1gyyEh-0007GH-23 for idr@ietf.org; Wed, 27 Feb 2019 13:22:55 +0100 From: Christoph Loibl Content-Type: multipart/alternative; boundary="Apple-Mail=_D68B35BA-1617-4E56-A549-54680619B80A" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <6D6B0397-15EE-4EC2-9BCB-A19E09E1DB2C@tix.at> Date: Wed, 27 Feb 2019 13:26:02 +0100 To: idr wg X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Idr] draft-ietf-idr-rfc5575bis - new version / implementation reports needed X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 12:26:10 -0000 --Apple-Mail=_D68B35BA-1617-4E56-A549-54680619B80A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, As I promised I uploaded a new version of draft-ietf-idr-rfc5575bis. = This solves all the known problems on my list: *) Unrestricted traffic action interference according to discussion. *) corner cases in comparison (always true/false cases) follows boolean = operation/implementations according to discussion. *) Updates in the changes to rfc5575 summary section - to reflect the = latest changes IMPLEMENTATION REPORTS *needed*: This is also a general call for implementation reports. I created a wiki = page for this manner at=20 = https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementation= s I very much appreciated if you can contribute to this page and add your = implementation! Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at --Apple-Mail=_D68B35BA-1617-4E56-A549-54680619B80A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

As I = promised I uploaded a new version of draft-ietf-idr-rfc5575bis. = This solves all the known problems on my list:

*) Unrestricted traffic action = interference according to discussion.
*) corner = cases in comparison (always true/false cases) follows boolean = operation/implementations according to discussion.
*)= Updates in the changes to rfc5575 summary section - to reflect the = latest changes

IMPLEMENTATION REPORTS *needed*:

This is also a general call for = implementation reports. I created a wiki page for this manner = at 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20imp= lementations

I very much appreciated if you can contribute to this page = and add your implementation!

Cheers Christoph
-- 
Christoph = Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 = | http://www.nextlayer.at



= --Apple-Mail=_D68B35BA-1617-4E56-A549-54680619B80A-- From nobody Wed Feb 27 09:39:27 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FEE13101F for ; Wed, 27 Feb 2019 09:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id violn0QYu9rb for ; Wed, 27 Feb 2019 09:39:22 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265D3130EDF for ; Wed, 27 Feb 2019 09:39:22 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id g20so5631367wmh.5 for ; Wed, 27 Feb 2019 09:39:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dQNZIdzknwFviwBTMue7rtRBICkA0Z/WFEwT78fJdac=; b=rU8enzt7LEM3e0Jlho7zfJZVnJnFaR7SY5rdQC53fim8oYhZEcgfhXt2Yn9MvBuHlR HoRZItgou+xuvf1g3qF+5WbfxXB4BT2XRNqhT657254pTrbGLpX0XYzLViLy6F6SRWHH /20sl1xx2d8+H3HAX1wMcikJXcLSArm2UxBHLKkCuPqYHFvqWZTPtihpJLYISerXtTU+ EhO9rk1jFhfaHP+PbaU1b/RpaVJBzU77PlWUUfwx2VKBtxXfC7zhjfcbnyt6sBYo6ZT0 HekfcSs4KR5vxaJu8QT8qpcr1+DvS2QixB06rU7ao/8i247JcIrAUoKdwz1/sNp75tvt 6AuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dQNZIdzknwFviwBTMue7rtRBICkA0Z/WFEwT78fJdac=; b=PDDcbFcHB1ai89Mzw1BFuaY2eNTKgQeNPE9/IYFJG7Xtbs4y13RBma8f4VF73BFB3x YAXKX3h5+S1bG6HPRIvcbIrp+FggTp5wc48eVboTcccaNCqLDZfrH40jfTAr407CcbU7 gw57Ex404V0LPoZreDbleKbDxuQF27KHHb2ITZbhVoTgZH6Vc/b+KZXCJTe/HVYRitsr YBo6e5+ryqe+RJFsCkairkz5tKtYz1Bv5MSh5t6l34UJyV7RS6yuZ/rqMS0DMXBkdTMT FTGnWy2/efzMkW2mWW+wo9N7gESNKSA25s6o5heyt1RIM4iTj1AL+EFWvucFAJ8n/+/L B17A== X-Gm-Message-State: AHQUAuZsHdrgRj1uYZJF1Jk8/IYeE3In9+SjoGLWjUyowy4mdkMfy1dj EpFa6UUQICL2R4E9hk+tPqPVt1MUTJxYHP765u1v/FPRaqY= X-Google-Smtp-Source: AHgI3IYJJdScNudTIN0SY2VnSg5xuC+IeyeLqQpH4+UTfFVGl2FZZzzBpXZ8j5Muwe3ebrZA9Ohvbgq/6FTmx9i9SXE= X-Received: by 2002:a7b:c92e:: with SMTP id h14mr303296wml.26.1551289160216; Wed, 27 Feb 2019 09:39:20 -0800 (PST) MIME-Version: 1.0 From: Tulasi Rami Reddy N Date: Wed, 27 Feb 2019 23:09:07 +0530 Message-ID: To: idr@ietf.org Content-Type: multipart/alternative; boundary="00000000000056b5d10582e3a798" Archived-At: Subject: [Idr] RFC4724: Clarification on Graceful Restart Mechanism for BGP X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 17:39:25 -0000 --00000000000056b5d10582e3a798 Content-Type: text/plain; charset="UTF-8" Hi All, I see below info in sec 4.2 of RFC4724. Can this be generalized, saying any capability mismatch? For example: If add-path capability is not received for some AF in the re-established session, should we retain the stale marked routes till EoR and then stale cleanup? ** *4.2. Procedures for the Receiving Speaker>* *if a specific address family is not included* *in the newly received Graceful Restart Capability, or if the Graceful* *Restart Capability is not received in the re-established session at* *all, then the Receiving Speaker MUST immediately remove all the stale* *routes from the peer that it is retaining for that address family.* ** Tulasi. --00000000000056b5d10582e3a798 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I see below info in sec 4.2 of RFC4= 724. Can this be generalized, saying any capability mismatch?

=C2=A0

For example: If add-path capability= is not received for some AF in the re-established session, should

we retain the stale marked routes till EoR and then stale cle= anup?

=C2=A0

<snip>
<=
span style=3D"font-size:9pt;font-family:"Arial",sans-serif">=C2=A0
4.2.=C2=A0 Procedures for the =
Receiving Speaker>
if a speci=
fic address family is not included
in the newly received Graceful Restart Capability, or if the Graceful
Restart Capability is not receive=
d in the re-established session at
all, then the Receiving Speaker MUST immediately remove all th= e stale
routes from the p=
eer that it is retaining for that address family.
</snip>

=C2=A0

Tulasi.

--00000000000056b5d10582e3a798-- From nobody Thu Feb 28 23:28:31 2019 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A024C128701; Thu, 28 Feb 2019 23:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZJaxKxMR89M; Thu, 28 Feb 2019 23:28:28 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958461274D0; Thu, 28 Feb 2019 23:28:28 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3A903DC3D49950199DB0; Fri, 1 Mar 2019 07:28:26 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 1 Mar 2019 07:28:25 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Fri, 1 Mar 2019 15:28:20 +0800 From: "Dongjie (Jimmy)" To: "idr@ietf.org" CC: "idr-chairs@ietf.org" Thread-Topic: Call for IETF104 IDR agenda items Thread-Index: AdTP+9uvO5Kq9lSxQCmMt3WjYm1/3g== Date: Fri, 1 Mar 2019 07:28:19 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927C347EBD0@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927C347EBD0NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] Call for IETF104 IDR agenda items X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 07:28:31 -0000 --_000_76CD132C3ADEF848BD84D028D243C927C347EBD0NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The agenda of IETF 104 has been published. IDR will meet twice, the first s= ession is on Monday Afternoon (16:10-18:10), the second session is on Thurs= day Morning (10:50-12:20). Please send any IDR agenda items you have to me and CC the chairs. Please i= nclude the name of the person who will be presenting, and the estimate time= you'll need (including Q/A). You may also indicate which session you would= prefer. If you plan to make a presentation, please keep in mind the IDR tradition, = "no Internet Draft - no time slot". You should also plan to send your slide= s to me and CC the chairs no later than 24 hours prior to the IDR meeting, = though earlier is better. If we don't have your slides by the deadline, you= may lose your slot. Please number your slides for the benefit of remote at= tendees. By default your slides will be converted to PDF and presented from= the PDF. If you need to use any fancy builds or transitions, please make s= ure to arrange this with us in advance. Thanks. And potential presenters, please take a look at the checklist for presentin= g at IDR: https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%2= 0at%20an%20IDR%20meeting Best regards, Jie --_000_76CD132C3ADEF848BD84D028D243C927C347EBD0NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

The agenda of IETF 104 has been= published. IDR will meet twice, the first session is on Monday Afternoon (= 16:10-18:10), the second session is on Thursday Morning (10:50-12:20).

 

Please send any IDR agenda item= s you have to me and CC the chairs. Please include the name of the person w= ho will be presenting, and the estimate time you'll need (including Q/A). Y= ou may also indicate which session you would prefer.

 

If you plan to make a presentat= ion, please keep in mind the IDR tradition, "no Internet Draft - no ti= me slot". You should also plan to send your slides to me and CC the ch= airs no later than 24 hours prior to the IDR meeting, though earlier is better. If we don't have your slides by the deadline, yo= u may lose your slot. Please number your slides for the benefit of remote a= ttendees. By default your slides will be converted to PDF and presented fro= m the PDF. If you need to use any fancy builds or transitions, please make sure to arrange this with us in a= dvance. Thanks.

 

And potential presenters, pleas= e take a look at the checklist for presenting at IDR:

https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presen= ting%20at%20an%20IDR%20meeting

 

Best regards,=

Jie

 

--_000_76CD132C3ADEF848BD84D028D243C927C347EBD0NKGEML515MBXchi_--